Add initial SHM-only Wayland Ozone implementation

Add initial SHM-only Wayland Ozone implementation

This is just the bare minimum to get a window on the screen.

Things like cursor handling, input handling, and vsync provider will come in
subsequent commits.

BUG=578890
Committed: https://crrev.com/44616bf0c27ddb9d93f838019a2b845cf62289c6
Cr-Commit-Position: refs/heads/master@{#372770}

[Michael Forney, 2016-01-21 02:07:51]

Description was changed from

==========
Add initial SHM-only Wayland Ozone implementation

This is just the bare minimum to get a window on the screen.

Things like cursor handling, input handling, and vsync provider will come in in
subsequent commits.

BUG=578890
==========

to

==========
Add initial SHM-only Wayland Ozone implementation

This is just the bare minimum to get a window on the screen.

Things like cursor handling, input handling, and vsync provider will come in
subsequent commits.

BUG=578890
==========

[Michael Forney, 2016-01-21 22:11:48]

forney@google.com changed reviewers:
+ rjkroege@chromium.org, spang@chromium.org

[Michael Forney, 2016-01-21 22:11:48]

Hi Michael and Rob,

This is a minimal implementation of a wayland ozone platform.

As discussed with Rob, this is restricted to software rendering only for now so
that we can rely on the PlatformWindow and SurfaceFactoryOzone being in the same
process.

With mus+ash, the browser and GPU process will be merged, and then we can
implement GL-rendering as well.

I have keyboard/pointer support ready to go, but split it into a separate commit
to minimize the size of this initial CL.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/ozone_platform_wayland.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/ozone_platform_wayland.cc:60:
display_->StartProcessingEvents();
It looks like base::MessageLoopForUI::current() is not set up when InitializeUI
gets called, so I am waiting until a PlatformWindow gets created. Is there a
better place to call this?

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_object.h (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_object.h:18: #define
DEFINE_TRAITS_WITH_DELETER(name, deleter_fn)                    \
If this is not acceptable, I can either expand the macro calls below, or drop
the constexpr and move this to a wayland_object.cc file (or do both).

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:157: return false;
Even with returning false here, I have to comment out
https://chromium.googlesource.com/chromium/src/+/bf0b91e43cd331c6ebdb80755a2a...
in order to get it to actually fall back to software rendering.

Am I missing some option or something to get it to fallback, or if not, what are
the implications of removing the fatal log message?

[spang, 2016-01-22 23:42:32]

spang@chromium.org changed reviewers:
+ kalyan.kondapally@intel.com, tiago.vignatti@intel.com

[spang, 2016-01-22 23:42:33]

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/ozone_platform_wayland.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/ozone_platform_wayland.cc:60:
display_->StartProcessingEvents();
On 2016/01/21 22:11:48, Michael Forney wrote:
> It looks like base::MessageLoopForUI::current() is not set up when
InitializeUI
> gets called, so I am waiting until a PlatformWindow gets created. Is there a
> better place to call this?

It's a longstanding issue that InitializeUI() runs before message loop
construction.

Other platforms are starting their listeners in OnDispatcherListChanged().

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_display.h (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.h:32: xdg_shell* GetShell();
These one line assessors should all named in unix_hacker_style() to signify that
they're cheap & uninteresting.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_object.h (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_object.h:18: #define
DEFINE_TRAITS_WITH_DELETER(name, deleter_fn)                    \
On 2016/01/21 22:11:48, Michael Forney wrote:
> If this is not acceptable, I can either expand the macro calls below, or drop
> the constexpr and move this to a wayland_object.cc file (or do both).

I'd prefer the macros expanded because token pasting breaks grep. I don't think
we're afraid of a little repetition.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:42: skia::RefPtr<SkSurface>
sksurface_;
SkSurface would become sk_surface_. Most code seems to just say surface_ though.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:60: base::ScopedFD
fd(mkostemp(tmp, O_CLOEXEC));
I think you want to use base::SharedMemory which will prefer to allocate in
/dev/shm.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:157: return false;
On 2016/01/21 22:11:48, Michael Forney wrote:
> Even with returning false here, I have to comment out
>
https://chromium.googlesource.com/chromium/src/+/bf0b91e43cd331c6ebdb80755a2a...
> in order to get it to actually fall back to software rendering.
> 
> Am I missing some option or something to get it to fallback, or if not, what
are
> the implications of removing the fatal log message?

Your link is cut off :(

[Michael Forney, 2016-01-23 01:08:05]

Thanks for the comments :)

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/ozone_platform_wayland.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/ozone_platform_wayland.cc:60:
display_->StartProcessingEvents();
On 2016/01/22 23:42:32, spang wrote:
> On 2016/01/21 22:11:48, Michael Forney wrote:
> > It looks like base::MessageLoopForUI::current() is not set up when
> InitializeUI
> > gets called, so I am waiting until a PlatformWindow gets created. Is there a
> > better place to call this?
> 
> It's a longstanding issue that InitializeUI() runs before message loop
> construction.
> 
> Other platforms are starting their listeners in OnDispatcherListChanged().

Cool, thanks for the suggestion. That does appear to work.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_display.h (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.h:32: xdg_shell* GetShell();
On 2016/01/22 23:42:32, spang wrote:
> These one line assessors should all named in unix_hacker_style() to signify
that
> they're cheap & uninteresting.

Done.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_object.h (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_object.h:18: #define
DEFINE_TRAITS_WITH_DELETER(name, deleter_fn)                    \
On 2016/01/22 23:42:32, spang wrote:
> On 2016/01/21 22:11:48, Michael Forney wrote:
> > If this is not acceptable, I can either expand the macro calls below, or
drop
> > the constexpr and move this to a wayland_object.cc file (or do both).
> 
> I'd prefer the macros expanded because token pasting breaks grep. I don't
think
> we're afraid of a little repetition.

Done.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:42: skia::RefPtr<SkSurface>
sksurface_;
On 2016/01/22 23:42:32, spang wrote:
> SkSurface would become sk_surface_. Most code seems to just say surface_
though.

I called it sk_surface_ to make the distinction between the wl_surface* that is
used in PresentCanvas (which could be confusing).

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:60: base::ScopedFD
fd(mkostemp(tmp, O_CLOEXEC));
On 2016/01/22 23:42:32, spang wrote:
> I think you want to use base::SharedMemory which will prefer to allocate in
> /dev/shm.

I should've guessed something like this would already exist. Done.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:157: return false;
On 2016/01/22 23:42:33, spang wrote:
> On 2016/01/21 22:11:48, Michael Forney wrote:
> > Even with returning false here, I have to comment out
> >
>
https://chromium.googlesource.com/chromium/src/+/bf0b91e43cd331c6ebdb80755a2a...
> > in order to get it to actually fall back to software rendering.
> > 
> > Am I missing some option or something to get it to fallback, or if not, what
> are
> > the implications of removing the fatal log message?
> 
> Your link is cut off :(

Sorry, I copied from a draft comment on a previous patch set, and didn't realize
that the link was truncated.

https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/co...

[spang, 2016-01-25 18:57:58]

vignatti@ kalyank@ Do the wayland bits look right?

Overall it looks fine to me but I am not familiar with the wayland API.

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/40001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:157: return false;
On 2016/01/23 01:08:05, Michael Forney wrote:
> On 2016/01/22 23:42:33, spang wrote:
> > On 2016/01/21 22:11:48, Michael Forney wrote:
> > > Even with returning false here, I have to comment out
> > >
> >
>
https://chromium.googlesource.com/chromium/src/+/bf0b91e43cd331c6ebdb80755a2a...
> > > in order to get it to actually fall back to software rendering.
> > > 
> > > Am I missing some option or something to get it to fallback, or if not,
what
> > are
> > > the implications of removing the fatal log message?
> > 
> > Your link is cut off :(
> 
> Sorry, I copied from a draft comment on a previous patch set, and didn't
realize
> that the link was truncated.
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/co...

Some CrOS-only code doesn't support software rendering. I'm not aware of the
specifics; it probably breaks in strange ways or crashes, so we have the
assertion.

Maybe you can compile MUS instead? Rob..?

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:80: size_.width() * 4,
&DeleteSharedMemory, shared_memory.release(),
Is it possible for NewRasterDirectReleaseProc to fail? You'll leak the
base::SharedMemory in that case.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_window.h (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_window.h:29: void ApplyPendingBounds();
It would be nice to comment these.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_window.h:65: wl::Object<xdg_surface>
xdg_surface_;
What's the difference between these two things?

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_window.h:67: gfx::Rect bounds_,
pending_bounds_;
Just one declaration per line.

[Michael Forney, 2016-01-25 19:16:45]

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_window.h (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_window.h:65: wl::Object<xdg_surface>
xdg_surface_;
On 2016/01/25 18:57:58, spang wrote:
> What's the difference between these two things?

The wl_surface is a generic surface object that is used for normal windows,
cursors, drag-and-drop surfaces and more. Creating a wl_surface alone will have
no actual effect until you assign it a "role".

Assigning the xdg_surface role causes it to appear as a top-level window and
allows you to do desktop-y things like maximize/minimize/fullscreen/set
title/interactive resize.

[rjkroege, 2016-01-25 20:41:31]

Do you have a plan for how to test this? What is it?

https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
File media/ozone/media_ozone_platform.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
media/ozone/media_ozone_platform.cc:60: MediaOzonePlatform*
CreateMediaOzonePlatformWayland() {
someday I suppose that we should have the same dynamic platform facility here as
we do in the core? I will file a bug.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_display.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.cc:21: static const
wl_registry_listener registry_listener = {
is Chrome allowed to use this style of construction yet?

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_display.h (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.h:10: #include
"base/message_loop/message_pump_libevent.h"
Sadly, I can't remember why but I recall that this may prove regrettable.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.h:57: std::map<gfx::AcceleratedWidget,
WaylandWindow*> windows_;
nit: reading this name at a glance suggests vector or array. consider changing
it to better reflect its use.

[spang, 2016-01-25 21:23:59]

https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
File media/ozone/media_ozone_platform.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
media/ozone/media_ozone_platform.cc:60: MediaOzonePlatform*
CreateMediaOzonePlatformWayland() {
On 2016/01/25 20:41:31, rjkroege wrote:
> someday I suppose that we should have the same dynamic platform facility here
as
> we do in the core? I will file a bug.

I'm not sure how we want to proceed here.

Currently the only ozone build with working accelerated decode is CrOS, and it
hardcodes the assumption of platform=drm. So it'd simply blow up if you tried to
run it with another platform.

It's been suggested that instead of subclassing VDA, we should instead move one
level lower and subclass VAAPIDevice or V4L2Device (each being optional). Then
you could support accelerated decode only via one of chrome's preferred APIs,
and the video guys have already done most of the work of integrating. This is
much simpler than trying to implement your own VDA and lends itself better to
how our code is organized (we wouldn't need media/ozone/ at all).

I think the video guys were designing a mojom for VDAs, so it might be
interesting to look into that.

[kalyank, 2016-01-25 22:05:16]

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:104: // draw to the buffer
at any time, even if it is being used by the Wayland
Also, we should make sure that we don't release buffer while it's still being
used by Wayland compositor.

[kalyank, 2016-01-25 22:06:32]

On 2016/01/25 21:23:59, spang wrote:
>
https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
> File media/ozone/media_ozone_platform.cc (right):
> 
>
https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
> media/ozone/media_ozone_platform.cc:60: MediaOzonePlatform*
> CreateMediaOzonePlatformWayland() {
> On 2016/01/25 20:41:31, rjkroege wrote:
> > someday I suppose that we should have the same dynamic platform facility
here
> as
> > we do in the core? I will file a bug.
> 
> I'm not sure how we want to proceed here.
> 
> Currently the only ozone build with working accelerated decode is CrOS, and it
> hardcodes the assumption of platform=drm. So it'd simply blow up if you tried
to
> run it with another platform.
> 
> It's been suggested that instead of subclassing VDA, we should instead move
one
> level lower and subclass VAAPIDevice or V4L2Device (each being optional). Then
> you could support accelerated decode only via one of chrome's preferred APIs,
> and the video guys have already done most of the work of integrating. This is
> much simpler than trying to implement your own VDA and lends itself better to
> how our code is organized (we wouldn't need media/ozone/ at all).
> 
> I think the video guys were designing a mojom for VDAs, so it might be
> interesting to look into that.

Not sure why we want to subclass VAAPIDevice/V4L2Device ? Isn't it just
Buffer Allocation (NativePixmap) and Display which should be really
platform specific.

[spang, 2016-01-25 22:47:29]

On 2016/01/25 22:06:32, kalyank wrote:
> On 2016/01/25 21:23:59, spang wrote:
> >
>
https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
> > File media/ozone/media_ozone_platform.cc (right):
> > 
> >
>
https://codereview.chromium.org/1610683003/diff/60001/media/ozone/media_ozone...
> > media/ozone/media_ozone_platform.cc:60: MediaOzonePlatform*
> > CreateMediaOzonePlatformWayland() {
> > On 2016/01/25 20:41:31, rjkroege wrote:
> > > someday I suppose that we should have the same dynamic platform facility
> here
> > as
> > > we do in the core? I will file a bug.
> > 
> > I'm not sure how we want to proceed here.
> > 
> > Currently the only ozone build with working accelerated decode is CrOS, and
it
> > hardcodes the assumption of platform=drm. So it'd simply blow up if you
tried
> to
> > run it with another platform.
> > 
> > It's been suggested that instead of subclassing VDA, we should instead move
> one
> > level lower and subclass VAAPIDevice or V4L2Device (each being optional).
Then
> > you could support accelerated decode only via one of chrome's preferred
APIs,
> > and the video guys have already done most of the work of integrating. This
is
> > much simpler than trying to implement your own VDA and lends itself better
to
> > how our code is organized (we wouldn't need media/ozone/ at all).
> > 
> > I think the video guys were designing a mojom for VDAs, so it might be
> > interesting to look into that.
> 
> Not sure why we want to subclass VAAPIDevice/V4L2Device ? Isn't it just
> Buffer Allocation (NativePixmap) and Display which should be really
> platform specific.

Probably, so s/Device/Display/ then.

[Michael Forney, 2016-01-26 02:24:46]

On 2016/01/25 20:41:31, rjkroege wrote:
> Do you have a plan for how to test this? What is it?

My plan is to create a dummy wayland server in the test, create a wl_client on
one end of a socketpair, and set WAYLAND_SOCKET to the other end so that
WaylandDisplay will connect to it.

Then, we can add tests to make sure that PlatformWindow methods result in
requests on the server side, and that events from the server make it through to
the PlatformWindowDelegate.

I haven't started work on that yet, but can do so if you want that done before
this CL is submitted.

[Michael Forney, 2016-01-26 02:25:26]

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_display.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.cc:21: static const
wl_registry_listener registry_listener = {
On 2016/01/25 20:41:31, rjkroege wrote:
> is Chrome allowed to use this style of construction yet?

Good question. It looks like designated initializers are not even part of any
C++ standard. Fixed now.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_display.h (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.h:10: #include
"base/message_loop/message_pump_libevent.h"
On 2016/01/25 20:41:31, rjkroege wrote:
> Sadly, I can't remember why but I recall that this may prove regrettable.

Hmm. You mean using MessagePumpLibevent? That's what's recommended in
https://www.chromium.org/developers/design-documents/ozone. Are there other
alternatives I should consider?

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_display.h:57: std::map<gfx::AcceleratedWidget,
WaylandWindow*> windows_;
On 2016/01/25 20:41:31, rjkroege wrote:
> nit: reading this name at a glance suggests vector or array. consider changing
> it to better reflect its use.

Changed to window_map_.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_surface_factory.cc (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:80: size_.width() * 4,
&DeleteSharedMemory, shared_memory.release(),
On 2016/01/25 18:57:57, spang wrote:
> Is it possible for NewRasterDirectReleaseProc to fail? You'll leak the
> base::SharedMemory in that case.

It looks like it does do some width/height/stride validation, so I am now
checking that it was successfully constructed before releasing the shared_memory
pointer.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_surface_factory.cc:104: // draw to the buffer
at any time, even if it is being used by the Wayland
On 2016/01/25 22:05:16, kalyank wrote:
> Also, we should make sure that we don't release buffer while it's still being
> used by Wayland compositor.

Acknowledged.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
File ui/ozone/platform/wayland/wayland_window.h (right):

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_window.h:29: void ApplyPendingBounds();
On 2016/01/25 18:57:58, spang wrote:
> It would be nice to comment these.

Done.

https://codereview.chromium.org/1610683003/diff/60001/ui/ozone/platform/wayla...
ui/ozone/platform/wayland/wayland_window.h:67: gfx::Rect bounds_,
pending_bounds_;
On 2016/01/25 18:57:57, spang wrote:
> Just one declaration per line.

Done.

[spang, 2016-01-29 01:55:29]

lgtm

[kalyank, 2016-01-29 22:42:26]

non owner lgtm

[Michael Forney, 2016-01-29 23:15:58]

forney@google.com changed reviewers:
+ jbudorick@chromium.org

[Michael Forney, 2016-01-29 23:15:59]

jbudorick: Can you review the build/common.gypi change?

[jbudorick, 2016-01-29 23:20:24]

build/common.gypi lgtm

[rjkroege, 2016-02-01 18:06:23]

lgtm

[Michael Forney, 2016-02-01 20:28:11]

The CQ bit was checked by forney@google.com

[commit-bot: I haz the power, 2016-02-01 20:29:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1610683003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1610683003/100001

[commit-bot: I haz the power, 2016-02-01 21:44:17]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-02-01 21:45:05]

Description was changed from

==========
Add initial SHM-only Wayland Ozone implementation

This is just the bare minimum to get a window on the screen.

Things like cursor handling, input handling, and vsync provider will come in
subsequent commits.

BUG=578890
==========

to

==========
Add initial SHM-only Wayland Ozone implementation

This is just the bare minimum to get a window on the screen.

Things like cursor handling, input handling, and vsync provider will come in
subsequent commits.

BUG=578890

Committed: https://crrev.com/44616bf0c27ddb9d93f838019a2b845cf62289c6
Cr-Commit-Position: refs/heads/master@{#372770}
==========

[commit-bot: I haz the power, 2016-02-01 21:45:06]

Patchset 6 (id:??) landed as
https://crrev.com/44616bf0c27ddb9d93f838019a2b845cf62289c6
Cr-Commit-Position: refs/heads/master@{#372770}