exo: Implement zcr_linux_explicit_synchronization_v1

exo: Add zcr_linux_explicit_synchronization_v1

Add support for the explicit-fencing protocol, and plumb GpuFence
integration through using the libsync primitive type and the
BindTexImage fence ID.

R=reveman@chromium.org
BUG=653908

[reveman, 2016-10-09 19:03:17]

Do you think we can include a SurfaceTest.SetAcquireFence unit test? Doesn't
have to be very advanced. Just something basic to exercise the new code.

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.cc
File components/exo/buffer.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.cc#ne...
components/exo/buffer.cc:245: fence_id =
glCreateFenceCHROMIUM(acquire_fence->AsClientFence());
Please use gles2->CreateFenceCHROMIUM here and it looks like we're leaking this
fence. Maybe make fence_id a member variable and call DestroyFenceCHROMIUM in
Texture::ReleaseTexImage and DestroyResources().

FYI, deferring it instead of destroying it right away might be better as destroy
requires some synchronization overhead to ensure it doesn't happen before usage
by (BindTexImage2DCHROMIUM) has taken place and it can be avoided if deferred
until after we produced and frame and been forced to flush anyhow.

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.cc#ne...
components/exo/buffer.cc:297: fence_id =
glCreateFenceCHROMIUM(acquire_fence->AsClientFence());
ditto

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.h
File components/exo/buffer.h (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.h#new...
components/exo/buffer.h:14: #include "ui/gfx/gpu_fence.h"
nit: you can avoid this include here in the header and just forward-declare it
in "namespace gfx" below, consistent with GpuMemoryBuffer. forward-declare is
always preferred in chromium code.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc
File components/exo/surface.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc#n...
components/exo/surface.cc:264: // A better representation would be good here.
TRACE_EVENT1(... "fence", !!fence) would be good enough I think

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc#n...
components/exo/surface.cc:269: DLOG(WARNING) << "Surface " <<
GetSurfaceId().ToString() << ": new acquire-fence";
Please remove this debug log before landing this change.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc#n...
components/exo/surface.cc:728: &texture_mailbox, std::move(acquire_fence_),
I think we need to keep the ownership of the acquire fence here in the surface
instance and just pass a raw pointer to ProduceTextureMailbox() in case we need
to produce a new texture mailbox. this can happen in rare circumstances when the
GPU process has crashed.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h
File components/exo/surface.h (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:113: // Provide an acquire-fence (as a raw file
descriptor) for the next surface
nit: update comment as this is not a raw file descriptor but instead the
abstract GpuFence class.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:114: // commit. A buffer must be attached in the same
transaction as applying a
What happens if a client doesn't respect this? We can't trust the client to do
the right thing so we need to make sure we do something reasonable if misused.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:116: void FenceAcquire(std::unique_ptr<gfx::GpuFence>
fence);
nit: s/FenceAcquire/SetAcquireFence/. We try to match the wayland interfaces in
terms of naming as much as possible in exo code.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:342: std::unique_ptr<gfx::GpuFence> acquire_fence_;
nit: can you move acquire_fence_ just below current_buffer_ on line 382 and keep
pending_acquire_fence_ here as now.
nit: a short comment in both cases similar to other pending/active state would
be nice for consistency.

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:103: const base::FilePath::CharType
kSocketName[] = FILE_PATH_LITERAL("exosphere-0");
We'll have to do this in a separate CL. Maybe try wayland-0 first and move to
wayland-1, etc. if already in use?

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:2973: // per-surface explict-fencing interface:
nit: for consistency "INTERFACENAME interface:"

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:2989: fence = aura::Env::GetInstance()
How about we move this to exo::Display by adding a Display::CreateLinuxFence in
a way that's consistent with CreateLinuxDMABufBuffer? A basic
DisplatTest.CreateLinuxFence unittest added to display_unittest.cc would be nice
too.

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:3015: void fencing_get_surface(wl_client*
client, wl_resource* resource, uint32_t id,
Can we make this consistent with the alpha_compositing interface and have it
fail if a fencing interface already exists for this surface?

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:3084: wl_global_create(wl_display_.get(),
We currently don't make the assumption that all this exo code is only going to
be used on linux even though that might be the only platform we build it on
today. Can you move this up into the USE_OZONE ifdef and protect all the code
added in the same way? Consistent with wl_drm and linux dmabuf interface.

https://codereview.chromium.org/2404513002/diff/1/third_party/wayland-protoco...
File
third_party/wayland-protocols/unstable/explicit-fencing/explicit-fencing-unstable-v1.xml
(right):

https://codereview.chromium.org/2404513002/diff/1/third_party/wayland-protoco...
third_party/wayland-protocols/unstable/explicit-fencing/explicit-fencing-unstable-v1.xml:1:
<protocol name="linux_explicit_synchronization_unstable_v1">
please rebase this CL on https://codereview.chromium.org/2397843002 when you
have a chance.

[fooishbar, 2016-10-12 15:41:56]

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.cc
File components/exo/buffer.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.cc#ne...
components/exo/buffer.cc:245: fence_id =
glCreateFenceCHROMIUM(acquire_fence->AsClientFence());
On 2016/10/09 19:03:16, reveman wrote:
> Please use gles2->CreateFenceCHROMIUM here and it looks like we're leaking
this
> fence. Maybe make fence_id a member variable and call DestroyFenceCHROMIUM in
> Texture::ReleaseTexImage and DestroyResources().
> 
> FYI, deferring it instead of destroying it right away might be better as
destroy
> requires some synchronization overhead to ensure it doesn't happen before
usage
> by (BindTexImage2DCHROMIUM) has taken place and it can be avoided if deferred
> until after we produced and frame and been forced to flush anyhow.

Oops, yes. Where would we defer it though? I can have a probe at this a little
later, for v3 perhaps.

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.h
File components/exo/buffer.h (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/buffer.h#new...
components/exo/buffer.h:14: #include "ui/gfx/gpu_fence.h"
On 2016/10/09 19:03:17, reveman wrote:
> nit: you can avoid this include here in the header and just forward-declare it
> in "namespace gfx" below, consistent with GpuMemoryBuffer. forward-declare is
> always preferred in chromium code.

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc
File components/exo/surface.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc#n...
components/exo/surface.cc:264: // A better representation would be good here.
On 2016/10/09 19:03:17, reveman wrote:
> TRACE_EVENT1(... "fence", !!fence) would be good enough I think

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc#n...
components/exo/surface.cc:269: DLOG(WARNING) << "Surface " <<
GetSurfaceId().ToString() << ": new acquire-fence";
On 2016/10/09 19:03:17, reveman wrote:
> Please remove this debug log before landing this change.

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.cc#n...
components/exo/surface.cc:728: &texture_mailbox, std::move(acquire_fence_),
On 2016/10/09 19:03:17, reveman wrote:
> I think we need to keep the ownership of the acquire fence here in the surface
> instance and just pass a raw pointer to ProduceTextureMailbox() in case we
need
> to produce a new texture mailbox. this can happen in rare circumstances when
the
> GPU process has crashed. 

Phew, that was my guess as to what probably made the most sense. OK great, I'll
do that for v2.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h
File components/exo/surface.h (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:113: // Provide an acquire-fence (as a raw file
descriptor) for the next surface
On 2016/10/09 19:03:17, reveman wrote:
> nit: update comment as this is not a raw file descriptor but instead the
> abstract GpuFence class.

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:114: // commit. A buffer must be attached in the same
transaction as applying a
On 2016/10/09 19:03:17, reveman wrote:
> What happens if a client doesn't respect this? We can't trust the client to do
> the right thing so we need to make sure we do something reasonable if misused.

Probably the same which happens if 'A buffer can only be attached to one surface
at a time' is violated? We can kill the client (harsh, but gets the point across
quickly), or use the first one (discarding others), or the last. I have no real
preference for which would be best.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:116: void FenceAcquire(std::unique_ptr<gfx::GpuFence>
fence);
On 2016/10/09 19:03:17, reveman wrote:
> nit: s/FenceAcquire/SetAcquireFence/. We try to match the wayland interfaces
in
> terms of naming as much as possible in exo code.

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/surface.h#ne...
components/exo/surface.h:342: std::unique_ptr<gfx::GpuFence> acquire_fence_;
On 2016/10/09 19:03:17, reveman wrote:
> nit: can you move acquire_fence_ just below current_buffer_ on line 382 and
keep
> pending_acquire_fence_ here as now.
> nit: a short comment in both cases similar to other pending/active state would
> be nice for consistency.

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:103: const base::FilePath::CharType
kSocketName[] = FILE_PATH_LITERAL("exosphere-0");
On 2016/10/09 19:03:17, reveman wrote:
> We'll have to do this in a separate CL. Maybe try wayland-0 first and move to
> wayland-1, etc. if already in use?

Yeah, this really shouldn't be in here; was a local change which slipped in!

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:2973: // per-surface explict-fencing interface:
On 2016/10/09 19:03:17, reveman wrote:
> nit: for consistency "INTERFACENAME interface:"

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:2989: fence = aura::Env::GetInstance()
On 2016/10/09 19:03:17, reveman wrote:
> How about we move this to exo::Display by adding a Display::CreateLinuxFence
in
> a way that's consistent with CreateLinuxDMABufBuffer? A basic
> DisplatTest.CreateLinuxFence unittest added to display_unittest.cc would be
nice
> too.

Done.

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:3015: void fencing_get_surface(wl_client*
client, wl_resource* resource, uint32_t id,
On 2016/10/09 19:03:17, reveman wrote:
> Can we make this consistent with the alpha_compositing interface and have it
> fail if a fencing interface already exists for this surface?

Yep, but let me do that in v3 so I can sort the rest first.

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:3084: wl_global_create(wl_display_.get(),
On 2016/10/09 19:03:17, reveman wrote:
> We currently don't make the assumption that all this exo code is only going to
> be used on linux even though that might be the only platform we build it on
> today. Can you move this up into the USE_OZONE ifdef and protect all the code
> added in the same way? Consistent with wl_drm and linux dmabuf interface.

Right, makes sense. Remembered that I'd only done that so I could test it on a
generic target_os='chromeos' build, not targeted at actual CrOS.

https://codereview.chromium.org/2404513002/diff/1/third_party/wayland-protoco...
File
third_party/wayland-protocols/unstable/explicit-fencing/explicit-fencing-unstable-v1.xml
(right):

https://codereview.chromium.org/2404513002/diff/1/third_party/wayland-protoco...
third_party/wayland-protocols/unstable/explicit-fencing/explicit-fencing-unstable-v1.xml:1:
<protocol name="linux_explicit_synchronization_unstable_v1">
On 2016/10/09 19:03:17, reveman wrote:
> please rebase this CL on https://codereview.chromium.org/2397843002 when you
> have a chance.

Done.

[fooishbar, 2016-10-12 15:45:20]

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/1/components/exo/wayland/serv...
components/exo/wayland/server.cc:3015: void fencing_get_surface(wl_client*
client, wl_resource* resource, uint32_t id,
On 2016/10/12 15:41:56, fooishbar wrote:
> On 2016/10/09 19:03:17, reveman wrote:
> > Can we make this consistent with the alpha_compositing interface and have it
> > fail if a fencing interface already exists for this surface?
> 
> Yep, but let me do that in v3 so I can sort the rest first.

Done.

[fooishbar, 2016-10-12 15:50:51]

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:103: const base::FilePath::CharType
kSocketName[] = FILE_PATH_LITERAL("exosphere-0");
Sorry, this still crept in from git-cl having squashed my local change in as
well.

[fooishbar, 2016-10-12 16:58:14]

the stray exosphere-0 is gone in this revision; i haven't been able to properly
test this with the simple-shm client, since we always hit the CopyTexImage
fallback which ignores fences.

[reveman, 2016-10-12 19:20:21]

Thanks for adding the test. This looks great. Just fix the nits and make sure to
run "git cl format" to clang format the code properly.

If you can also update the description to match the latest version of the patch
that'd be great. ie. s/Exosphere: Add zcr_linux_explicit_fencing_v1/exo:
Implement zcr_linux_explicit_synchronization_v1/. You can use BUG=653908

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.cc
File components/exo/buffer.cc (right):

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.c...
components/exo/buffer.cc:122: gpu::SyncToken BindTexImage(gfx::GpuFence*
acquire_fence);
nit: sometimes "acquire_fence" name is used and sometimes just "fence", can we
make this consistent throughout this file and just use "fence"?

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.c...
components/exo/buffer.cc:274: if (fence_id_ != 0u)
nit: "if (fence_id_)" is preferred in chromium code

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.c...
components/exo/buffer.cc:308: if (fence_id_ != 0u)
nit: "if (fence_id_)" is preferred in chromium code

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.c...
components/exo/buffer.cc:309: gles2->DestroyFenceCHROMIUM(fence_id_);
nit: set fence_id_ to 0 here so it's easier to tell if we use it after
destruction by mistake

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.c...
components/exo/buffer.cc:324: void Buffer::Texture::DestroyResources() {
Can you add "if (fence_id_) gles2->DestroyFenceCHROMIUM(fence_id_)" here too? Or
a DCHECK_EQ(fence_id_, 0u) if we're confident that release is always called. I'm
not 100% sure it is in the case of the GPU process crash so might be best to
call DestroyFenceCHROMIUM.

https://codereview.chromium.org/2404513002/diff/20001/components/exo/buffer.c...
components/exo/buffer.cc:419: gfx::GpuFence* acquire_fence,
nit: s/acquire_fence/fence/ to be consistent with declaration in .h file

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display.cc
File components/exo/display.cc (right):

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display....
components/exo/display.cc:106: gfx::GpuFenceHandle handle;
nit: Please add "TRACE_EVENT1("exo", "Display::CreateLinuxFence", "fd",
fd.get())" followed by a blank line here. These top-level trace events are very
useful for debugging purposes.

FYI, you can launch chrome with --trace-to-console=exo to have tracing output
for exo clients spewed to the console

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display.h
File components/exo/display.h (right):

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display....
components/exo/display.h:66: std::unique_ptr<gfx::GpuFence> CreateLinuxFence(
nit: "// Creates a GpuFence for a Linux fence file descriptor." above this just
to be consistent with CreateLinuxDMABufBuffer.

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display....
components/exo/display.h:67: base::ScopedFD& fd
nit: remove "&" as base::ScopedFD is preferably passed by value

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display_...
File components/exo/display_unittest.cc (right):

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display_...
components/exo/display_unittest.cc:100: EXPECT_TRUE(fence1);
nit: ASSERT_TRUE as code below will crash if this fails

https://codereview.chromium.org/2404513002/diff/20001/components/exo/display_...
components/exo/display_unittest.cc:113: std::unique_ptr<gfx::GpuFence> fence2 =
nit: just a short comment here to explain that this checks that an invalid fence
is not causing bad behavior

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:103: const base::FilePath::CharType
kSocketName[] = FILE_PATH_LITERAL("exosphere-0");
On 2016/10/12 at 15:50:51, fooishbar wrote:
> Sorry, this still crept in from git-cl having squashed my local change in as
well.

No problem. If you can remove it when you have a chance so people can apply this
unmodified patch for testing purposes without breaking arc++ that'd be great.

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:777: class Synchronization : public
SurfaceObserver {
nit: add the following comment above this class:

// Implements the synchronization interface to a Surface. A window property
// will be set during the lifetime of this class to prevent multiple instances
// from being created for the same Surface.

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:788:
surface_->SetProperty(kSurfaceHasSynchronizationKey, true);
s/true/false/ here

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:792: bool SetAcquireFence(int fd_raw) {
nit: s/int fd_raw/base::ScopedFD fd/ as it's best to add proper ownership asap
in synchronization_set_acquire_fence and avoid passing raw fds around

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:793: std::unique_ptr<gfx::GpuFence> fence;
nit: move down where it's first used

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:821: int fd_raw) {
nit: s/int fd_raw/int32_t fd/

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:824: if
(!synchronization->SetAcquireFence(fd_raw)) {
s/fd_raw/base::ScopedFD(fd)/

https://codereview.chromium.org/2404513002/diff/20001/components/exo/wayland/...
components/exo/wayland/server.cc:3087: 
nit: no need for this blank line

https://codereview.chromium.org/2404513002/diff/20001/third_party/wayland-pro...
File
third_party/wayland-protocols/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
(right):

https://codereview.chromium.org/2404513002/diff/20001/third_party/wayland-pro...
third_party/wayland-protocols/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml:80:
<enum name="error">
I included this in https://codereview.chromium.org/2397843002 so it should no
longer be needed after a rebase.

[fooishbar, 2016-10-13 16:55:35]

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
components/exo/wayland/server.cc:64: #include
"gpu/command_buffer/client/gpu_memory_buffer_manager.h"
oops - this needs to go too.

[fooishbar, 2016-10-13 16:56:52]

Description was changed from

==========
Exosphere: Add zcr_linux_explicit_fencing_v1

Add support for the explicit-fencing protocol, and plumb GpuFence
integration through using the libsync primitive type and the
BindTexImage fence ID.

R=reveman@chromium.org
BUG=
==========

to

==========
exo: Add zcr_linux_explicit_synchronization_v1

Add support for the explicit-fencing protocol, and plumb GpuFence
integration through using the libsync primitive type and the
BindTexImage fence ID.

R=reveman@chromium.org
BUG=653908
==========

[reveman, 2016-10-13 17:13:51]

Just a few nits I missed in my last review. This lgtm after fixing those.

https://codereview.chromium.org/2404513002/diff/80001/components/exo/buffer.cc
File components/exo/buffer.cc (right):

https://codereview.chromium.org/2404513002/diff/80001/components/exo/buffer.c...
components/exo/buffer.cc:477: gpu::SyncToken sync_token =
texture->BindTexImage(std::move(fence));
nit: not need for std::move here anymore now that this is a raw pointer

https://codereview.chromium.org/2404513002/diff/80001/components/exo/buffer.c...
components/exo/buffer.cc:504: std::move(fence), texture,
nit: same here

https://codereview.chromium.org/2404513002/diff/80001/components/exo/surface.h
File components/exo/surface.h (right):

https://codereview.chromium.org/2404513002/diff/80001/components/exo/surface....
components/exo/surface.h:26: #include "ui/gfx/gpu_fence.h"
nit: looks like this could be moved to .cc file and just forward declared here

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
components/exo/wayland/server.cc:796: fence = display_->CreateLinuxFence(fd);
nit: std::unique_ptr<gfx::GpuFence> fence = display_->CreateLinuxFence(fd);

[reveman, 2016-10-13 17:26:02]

two small compile fixes

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
File components/exo/wayland/server.cc (right):

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
components/exo/wayland/server.cc:796: fence = display_->CreateLinuxFence(fd);
On 2016/10/13 at 17:13:51, reveman wrote:
> nit: std::unique_ptr<gfx::GpuFence> fence = display_->CreateLinuxFence(fd);

also, you need to use std::move(fd) here

https://codereview.chromium.org/2404513002/diff/80001/components/exo/wayland/...
components/exo/wayland/server.cc:822: in32_t fd) {
s/in32_t/int32_t/

[fooishbar, 2016-10-20 10:05:51]

rebase, fix unit tests

[reveman, 2016-10-24 16:25:07]

Hi, this might need a rebase on latest gpu fence patches. I fixed the unit test
and made the code build run without ozone. The diff can be found here:
https://codereview.chromium.org/2443823002

Would be great if you could includes those changes into this patch.

[fooishbar, 2016-11-03 12:55:38]

rebase, pull in cl 2443823002