ozone: Add overlay candidate implementation that queries support via IPC

ozone: Add overlay candidate implementation that queries support via IPC

Querying is done asynchronously, with a browser-side cache of responses.
GPU will try out the requested overlay configuration and report if it was
successful. Response delay is typically 1 frame but could be more in
rare situations. A maximum cache size is imposed so that a video that's being
moved/resized won't cause memory consumption to explode

TBR=danakj (trivial enum change)

Committed: https://crrev.com/ad89643990d9b2320960d1912695cc1418a3fdab
Cr-Commit-Position: refs/heads/master@{#333073}

[achaulk, 2015-05-26 17:31:04]

achaulk@chromium.org changed reviewers:
+ dnicoara@chromium.org, spang@chromium.org

[achaulk, 2015-05-26 17:31:04]

One grand unified CL that includes usage and no overengineering

[dnicoara, 2015-05-28 21:09:54]

Should the cache be discarded when the display configuration or window bounds
change? I can see different connectors having different capabilities and it
would be possible to move the windows between displays or go to mirror mode.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
File ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc (right):

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:84:
SendRequest(*candidates, PendingCheck(next_request_id_++, lookup));
The more I read, the clearer it is to me that the request_id isn't needed. All
messages are sent sequentially, and processed similarly. So when you receive
them they'll be in the same order you sent them in. The widget id should be
sufficient.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:90: void
DrmHostOverlayCandidates::OnChannelEstablished(
Also, you'll want to clear all pending requests if the GPU process goes away
since they'll never be answered.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:94:
channel_established_ = true;
You can use DrmGpuPlatformSupportHost::IsConnected() for this.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:120:
send_callback_.Run(new OzoneGpuMsg_CheckOverlayCapabilities(
Should this post taks using the |send_runner|?

FYI DrmGpuPlatformSupportHost::Send() is a nice wrapper to post the IPC message.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
File ui/ozone/platform/drm/host/drm_overlay_manager.cc (right):

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_overlay_manager.cc:20: is_supported_ =
base::CommandLine::ForCurrentProcess()->HasSwitch(
This is never used.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_overlay_manager.cc:29: return new
DrmHostOverlayCandidates(w, platform_support_host_);
This is leaking the DrmHostOverlayCandidates.

[achaulk, 2015-05-29 18:49:21]

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
File ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc (right):

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:84:
SendRequest(*candidates, PendingCheck(next_request_id_++, lookup));
On 2015/05/28 21:09:54, dnicoara wrote:
> The more I read, the clearer it is to me that the request_id isn't needed. All
> messages are sent sequentially, and processed similarly. So when you receive
> them they'll be in the same order you sent them in. The widget id should be
> sufficient.

Done.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:90: void
DrmHostOverlayCandidates::OnChannelEstablished(
On 2015/05/28 21:09:54, dnicoara wrote:
> Also, you'll want to clear all pending requests if the GPU process goes away
> since they'll never be answered.

If the GPU process goes away nothing matters because this will never be used
again

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:94:
channel_established_ = true;
On 2015/05/28 21:09:54, dnicoara wrote:
> You can use DrmGpuPlatformSupportHost::IsConnected() for this.

Done.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:120:
send_callback_.Run(new OzoneGpuMsg_CheckOverlayCapabilities(
On 2015/05/28 21:09:54, dnicoara wrote:
> Should this post taks using the |send_runner|?
> 
> FYI DrmGpuPlatformSupportHost::Send() is a nice wrapper to post the IPC
message.

Done.

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
File ui/ozone/platform/drm/host/drm_overlay_manager.cc (right):

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_overlay_manager.cc:20: is_supported_ =
base::CommandLine::ForCurrentProcess()->HasSwitch(
On 2015/05/28 21:09:54, dnicoara wrote:
> This is never used.

Oh, yeah this should gate object creation

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_overlay_manager.cc:29: return new
DrmHostOverlayCandidates(w, platform_support_host_);
On 2015/05/28 21:09:54, dnicoara wrote:
> This is leaking the DrmHostOverlayCandidates.

Yeah I was still deciding where it should be destroyed at

[dnicoara, 2015-05-29 19:28:24]

Any thoughts on the display change scenario mentioned in my last comment?

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
File ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc (right):

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:90: void
DrmHostOverlayCandidates::OnChannelEstablished(
On 2015/05/29 18:49:20, achaulk wrote:
> On 2015/05/28 21:09:54, dnicoara wrote:
> > Also, you'll want to clear all pending requests if the GPU process goes away
> > since they'll never be answered.
> 
> If the GPU process goes away nothing matters because this will never be used
> again

I thought the compositor for the primary widget just gets reused. Wouldn't you
need to clear |pending_checks_| when the GPU goes away?

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_host_overlay_candidates.h (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.h:33: class
DrmHostOverlayCandidates : public OverlayCandidatesOzone,
We should name this DrmOverlayCandidatesHost for consistency.

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_overlay_manager.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_manager.cc:27:
scoped_ptr<OverlayCandidatesOzone> DrmOverlayManager::GetOverlayCandidates(
This should be renamed to CreateOverlayCandidates()

The cast impl also needs to be updated (should probably split the API change as
a separate change after everyone is happy with the changes).

[achaulk, 2015-05-29 19:36:36]

We should clear the cache in that case, yes, but I'm going to add that in a
later CL

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
File ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc (right):

https://codereview.chromium.org/1157793004/diff/1/ui/ozone/platform/drm/host/...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.cc:90: void
DrmHostOverlayCandidates::OnChannelEstablished(
On 2015/05/29 19:28:23, dnicoara wrote:
> On 2015/05/29 18:49:20, achaulk wrote:
> > On 2015/05/28 21:09:54, dnicoara wrote:
> > > Also, you'll want to clear all pending requests if the GPU process goes
away
> > > since they'll never be answered.
> > 
> > If the GPU process goes away nothing matters because this will never be used
> > again
> 
> I thought the compositor for the primary widget just gets reused. Wouldn't you
> need to clear |pending_checks_| when the GPU goes away?

No, the OutputSurface at least gets re-created in that case, so this will too

[spang, 2015-06-01 18:54:21]

I still think, broadly speaking, that presentation decisions (including overlay
queries) should happen through the command buffer.

alexst@ said he didn't want to reevaluate the interface at this time. I suppose
this way is reasonable in that case.

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
File ui/ozone/common/gpu/ozone_gpu_message_params.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
ui/ozone/common/gpu/ozone_gpu_message_params.cc:46:
display_rect(gfx::ToNearestRect(candidate.display_rect)),
why is it a RectF in OverlayCandidatesOzone and a Rect in OverlayCheck_Params?

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
File ui/ozone/common/gpu/ozone_gpu_messages.h (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
ui/ozone/common/gpu/ozone_gpu_messages.h:73: IPC_STRUCT_TRAITS_END()
newline

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/stub_ov...
File ui/ozone/common/stub_overlay_manager.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/stub_ov...
ui/ozone/common/stub_overlay_manager.cc:16: scoped_ptr<OverlayCandidatesOzone>
StubOverlayManager::GetOverlayCandidates(
s/Get/Create/

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/drm_gpu_platform_support.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/drm_gpu_platform_support.cc:276: bool
DrmGpuPlatformSupport::TestOverlayCapabilities(
Feels misplaced here. This class wires up IPC, there shouldn't be any
significant logic in it.

Maybe move to DrmWindow?

[spang, 2015-06-01 19:47:40]

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/drm_window.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/drm_window.cc:146: return controller_ &&
Shouldn't it be

if (!controller_)
  return true;

Flipping an offscreen window is an no-op and cannot fail no matter how many
overlays we have. No point in doing any composition.

[achaulk, 2015-06-01 20:43:08]

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
File ui/ozone/common/gpu/ozone_gpu_message_params.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
ui/ozone/common/gpu/ozone_gpu_message_params.cc:46:
display_rect(gfx::ToNearestRect(candidate.display_rect)),
On 2015/06/01 18:54:20, spang wrote:
> why is it a RectF in OverlayCandidatesOzone and a Rect in OverlayCheck_Params?

We convert to ints internally, this is post-conversion

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
File ui/ozone/common/gpu/ozone_gpu_messages.h (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/gpu/ozo...
ui/ozone/common/gpu/ozone_gpu_messages.h:73: IPC_STRUCT_TRAITS_END()
On 2015/06/01 18:54:21, spang wrote:
> newline

Done.

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/stub_ov...
File ui/ozone/common/stub_overlay_manager.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/common/stub_ov...
ui/ozone/common/stub_overlay_manager.cc:16: scoped_ptr<OverlayCandidatesOzone>
StubOverlayManager::GetOverlayCandidates(
On 2015/06/01 18:54:21, spang wrote:
> s/Get/Create/

As per danny's comment, the API change will be separate

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/drm_gpu_platform_support.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/drm_gpu_platform_support.cc:276: bool
DrmGpuPlatformSupport::TestOverlayCapabilities(
On 2015/06/01 18:54:21, spang wrote:
> Feels misplaced here. This class wires up IPC, there shouldn't be any
> significant logic in it.
> 
> Maybe move to DrmWindow?

Sure

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/drm_window.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/drm_window.cc:146: return controller_ &&
On 2015/06/01 19:47:39, spang wrote:
> Shouldn't it be
> 
> if (!controller_)
>   return true;
> 
> Flipping an offscreen window is an no-op and cannot fail no matter how many
> overlays we have. No point in doing any composition.

Sure? It doesn't really matter what we return

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_host_overlay_candidates.h (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_host_overlay_candidates.h:33: class
DrmHostOverlayCandidates : public OverlayCandidatesOzone,
On 2015/05/29 19:28:23, dnicoara wrote:
> We should name this DrmOverlayCandidatesHost for consistency.

Done.

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_overlay_manager.cc (right):

https://codereview.chromium.org/1157793004/diff/20001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_manager.cc:27:
scoped_ptr<OverlayCandidatesOzone> DrmOverlayManager::GetOverlayCandidates(
On 2015/05/29 19:28:23, dnicoara wrote:
> This should be renamed to CreateOverlayCandidates()
> 
> The cast impl also needs to be updated (should probably split the API change
as
> a separate change after everyone is happy with the changes).

Acknowledged.

[spang, 2015-06-01 23:23:52]

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc (right):

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:12: const size_t
kMaxCacheSize = 10000;
How likely do we expect a config to be reused >>10,000 frames later?

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:18: return
l.plane_z_order < r.plane_z_order ||
Can you split this into multiple statements?

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:124: cache_[check] =
true;
Should we also cache negative results?

[achaulk, 2015-06-02 14:37:43]

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc (right):

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:12: const size_t
kMaxCacheSize = 10000;
On 2015/06/01 23:23:51, spang wrote:
> How likely do we expect a config to be reused >>10,000 frames later?

Well it depends. The answers are generally considered to be constant forever,
but since we have a (screen rect, buffer size, format) tuple to key off of,
scrolling + zooming + adaptive video size could easily add a few hundred to
thousand entries pretty quickly and if we left it unbounded it could eat up
memory, and if we make it too small we will clear it too often

5-10k seems like a good compromise range where it still won't take too much
memory and won't need to be re-queried too often

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:124: cache_[check] =
true;
On 2015/06/01 23:23:51, spang wrote:
> Should we also cache negative results?

Everything defaults to negative when it's added, so there's no need to update
anything in that case

[spang, 2015-06-02 17:14:34]

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc (right):

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:12: const size_t
kMaxCacheSize = 10000;
On 2015/06/02 14:37:43, achaulk wrote:
> On 2015/06/01 23:23:51, spang wrote:
> > How likely do we expect a config to be reused >>10,000 frames later?
> 
> Well it depends. The answers are generally considered to be constant forever,
> but since we have a (screen rect, buffer size, format) tuple to key off of,
> scrolling + zooming + adaptive video size could easily add a few hundred to
> thousand entries pretty quickly and if we left it unbounded it could eat up
> memory, and if we make it too small we will clear it too often

Yeah, the space of configurations is very large. So I'm wondering if a cache of
10000 entries actually has a enough higher hit rate than a cache of 100 entries
to justify the increased memory cost. If 100x larger cache has a negligible
effect on the hit rate, we shouldn't do it.

I think "clearing too often" being a worry is just a sign that clearing the
cache isn't a very good eviction policy. Maybe look into base::MRUCache.

Can we make it small for now and increase the size once we have justification
for it?

> 
> 5-10k seems like a good compromise range where it still won't take too much
> memory and won't need to be re-queried too often

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:124: cache_[check] =
true;
On 2015/06/02 14:37:43, achaulk wrote:
> On 2015/06/01 23:23:51, spang wrote:
> > Should we also cache negative results?
> 
> Everything defaults to negative when it's added, so there's no need to update
> anything in that case

Ah I see it now, thanks.

[achaulk, 2015-06-02 19:38:38]

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc (right):

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:12: const size_t
kMaxCacheSize = 10000;
On 2015/06/02 17:14:34, spang wrote:
> On 2015/06/02 14:37:43, achaulk wrote:
> > On 2015/06/01 23:23:51, spang wrote:
> > > How likely do we expect a config to be reused >>10,000 frames later?
> > 
> > Well it depends. The answers are generally considered to be constant
forever,
> > but since we have a (screen rect, buffer size, format) tuple to key off of,
> > scrolling + zooming + adaptive video size could easily add a few hundred to
> > thousand entries pretty quickly and if we left it unbounded it could eat up
> > memory, and if we make it too small we will clear it too often
> 
> Yeah, the space of configurations is very large. So I'm wondering if a cache
of
> 10000 entries actually has a enough higher hit rate than a cache of 100
entries
> to justify the increased memory cost. If 100x larger cache has a negligible
> effect on the hit rate, we shouldn't do it.
> 
> I think "clearing too often" being a worry is just a sign that clearing the
> cache isn't a very good eviction policy. Maybe look into base::MRUCache.
> 
> Can we make it small for now and increase the size once we have justification
> for it?
> 
> > 
> > 5-10k seems like a good compromise range where it still won't take too much
> > memory and won't need to be re-queried too often
> 

Done.

https://codereview.chromium.org/1157793004/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_overlay_candidates_host.cc:18: return
l.plane_z_order < r.plane_z_order ||
On 2015/06/01 23:23:51, spang wrote:
> Can you split this into multiple statements?

Done.

[spang, 2015-06-02 19:40:43]

lgtm

[spang, 2015-06-02 19:43:27]

one last nit

https://codereview.chromium.org/1157793004/diff/80001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/drm_gpu_platform_support.h (right):

https://codereview.chromium.org/1157793004/diff/80001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/drm_gpu_platform_support.h:76: const
std::vector<OverlayCheck_Params>& overlays);
Forgot to remove this.

[dnicoara, 2015-06-02 19:56:45]

lgtm pending OverlayManagerOzone interface update

[achaulk, 2015-06-04 17:30:40]

achaulk@chromium.org changed reviewers:
+ nasko@chromium.org

[achaulk, 2015-06-04 17:30:41]

+nasko for IPC

[nasko, 2015-06-04 22:33:56]

IPC LGTM

[achaulk, 2015-06-05 15:34:10]

The CQ bit was checked by achaulk@chromium.org

[achaulk, 2015-06-05 15:34:10]

The patchset sent to the CQ was uploaded after l-g-t-m from spang@chromium.org,
dnicoara@chromium.org
Link to the patchset: https://codereview.chromium.org/1157793004/#ps120001
(title: "rebase")

[commit-bot: I haz the power, 2015-06-05 15:36:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1157793004/120001

[commit-bot: I haz the power, 2015-06-05 15:43:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-05 15:43:58]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[achaulk, 2015-06-05 15:45:16]

The CQ bit was checked by achaulk@chromium.org

[commit-bot: I haz the power, 2015-06-05 15:46:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1157793004/120001

[commit-bot: I haz the power, 2015-06-05 15:53:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-05 15:53:49]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[achaulk, 2015-06-05 15:55:42]

The CQ bit was checked by achaulk@chromium.org

[achaulk, 2015-06-05 15:55:42]

The patchset sent to the CQ was uploaded after l-g-t-m from
dnicoara@chromium.org, nasko@chromium.org, spang@chromium.org
Link to the patchset: https://codereview.chromium.org/1157793004/#ps140001
(title: "add missing license header")

[commit-bot: I haz the power, 2015-06-05 15:57:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1157793004/140001

[commit-bot: I haz the power, 2015-06-05 16:57:37]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2015-06-05 16:58:24]

Patchset 8 (id:??) landed as
https://crrev.com/ad89643990d9b2320960d1912695cc1418a3fdab
Cr-Commit-Position: refs/heads/master@{#333073}