gpu: Take surface handle into account when importing buffers.

gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807, 597932
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/15e3d9a4516ad22cc56c1ff162f32f3d03e8de9f
Cr-Commit-Position: refs/heads/master@{#406322}

[reveman, 2016-07-13 20:57:12]

Description was changed from

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807
==========

to

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[reveman, 2016-07-13 20:57:13]

Description was changed from

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[reveman, 2016-07-13 21:01:15]

reveman@chromium.org changed reviewers:
+ dnicoara@chromium.org

[reveman, 2016-07-13 21:13:03]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 21:14:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 21:14:50]

Your CL relies on deprecated CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is deprecated:
     tryserver.blink
   For more details, see http://crbug.com/617627.

[commit-bot: I haz the power, 2016-07-13 21:41:34]

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

[commit-bot: I haz the power, 2016-07-13 21:41:34]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[reveman, 2016-07-13 22:33:18]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 22:34:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[reveman, 2016-07-13 22:42:19]

Description was changed from

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807,597932
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-07-14 01:22:48]

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

[commit-bot: I haz the power, 2016-07-14 01:22:49]

Dry run: This issue passed the CQ dry run.

[Pawel Osciak, 2016-07-14 04:42:35]

posciak@chromium.org changed reviewers:
+ posciak@chromium.org

[Pawel Osciak, 2016-07-14 04:42:36]

media/gpu lgtm

[dnicoara, 2016-07-14 17:23:25]

lgtm

This fixes the allocation issues, but the screen is still black. There seems to
be another issue around importing the buffer back from an FD. (That doesn't seem
to be a userspace issue though.) I'm currently looking at narrowing down the use
case for confirmation.

[reveman, 2016-07-14 18:10:12]

reveman@chromium.org changed reviewers:
+ piman@chromium.org, spang@chromium.org

[reveman, 2016-07-14 18:10:13]

+spang for ui/ozone/
+piman for gpu/

Ok, thanks for investigating. Sounds like we should at least land this as a
first step.

[piman, 2016-07-14 18:32:44]

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
File gpu/ipc/service/gpu_command_buffer_stub.cc (right):

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
gpu/ipc/service/gpu_command_buffer_stub.cc:1008: handle, size, format,
internalformat, surface_handle_);
surface_handle_ will be null for offscreen contexts (everything except the
Display context in the browser - which currently is also the browser compositor
context, but may not stay that way forever, because of the mus story and the
intent to share contexts more broadly).

At the very least, is this handled at the lower level, security-wise?

AFAICT it goes down to DrmThread::CreateBufferFromFds which then calls
device_manager_->GetDrmDevice(widget), expecting the result to be !null - is it
going to be true?

Moving forward, would it make sense to pass the surface_handle explicitly here?

[reveman, 2016-07-14 20:00:59]

ptal

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
File gpu/ipc/service/gpu_command_buffer_stub.cc (right):

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
gpu/ipc/service/gpu_command_buffer_stub.cc:1008: handle, size, format,
internalformat, surface_handle_);
On 2016/07/14 at 18:32:44, piman wrote:
> surface_handle_ will be null for offscreen contexts (everything except the
Display context in the browser - which currently is also the browser compositor
context, but may not stay that way forever, because of the mus story and the
intent to share contexts more broadly).

hm, I'm not sure I understand exactly what this context sharing would mean. Will
we potentially use an offscreen context for onscreen compositing? Or do we just
need offscreen contexts that are not necessarily associated with the primary drm
device?

> 
> At the very least, is this handled at the lower level, security-wise?

I updated to DrmDeviceManager::GetDrmDevice to not crash if passed an invalid
widget in latest patch as that seems consistent with
DrmDeviceManager::RemoveDrmDevice. However, I'd be surprised if a client managed
to create a context for an invalid widget and that did not causing a failure or
crash somewhere else.

> 
> AFAICT it goes down to DrmThread::CreateBufferFromFds which then calls
device_manager_->GetDrmDevice(widget), expecting the result to be !null - is it
going to be true?

GetDrmDevice will always return !null and handles null input by returning the
primary device. I didn't handle an invalid widget as input in a safe way but
that's been addressed in latest patch as mentioned above.

> 
> Moving forward, would it make sense to pass the surface_handle explicitly
here?

Explicitly as part of the CHROMIUM_image extension?

[piman, 2016-07-14 20:39:26]

lgtm

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
File gpu/ipc/service/gpu_command_buffer_stub.cc (right):

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
gpu/ipc/service/gpu_command_buffer_stub.cc:1008: handle, size, format,
internalformat, surface_handle_);
On 2016/07/14 20:00:59, reveman wrote:
> On 2016/07/14 at 18:32:44, piman wrote:
> > surface_handle_ will be null for offscreen contexts (everything except the
> Display context in the browser - which currently is also the browser
compositor
> context, but may not stay that way forever, because of the mus story and the
> intent to share contexts more broadly).
> 
> hm, I'm not sure I understand exactly what this context sharing would mean.
Will
> we potentially use an offscreen context for onscreen compositing? Or do we
just
> need offscreen contexts that are not necessarily associated with the primary
drm
> device?

The latter. Today the browser compositor (ui::Compositor) doesn't own the
GLRenderer, it sends a CompositorFrame to the Display - which then itself uses a
GLRenderer to produce the final frame.
They just happen to use the same context (which is a view context, which has a
!null surface_handle_), but they don't have to.

> 
> > 
> > At the very least, is this handled at the lower level, security-wise?
> 
> I updated to DrmDeviceManager::GetDrmDevice to not crash if passed an invalid
> widget in latest patch as that seems consistent with
> DrmDeviceManager::RemoveDrmDevice. However, I'd be surprised if a client
managed
> to create a context for an invalid widget and that did not causing a failure
or
> crash somewhere else.
> 
> > 
> > AFAICT it goes down to DrmThread::CreateBufferFromFds which then calls
> device_manager_->GetDrmDevice(widget), expecting the result to be !null - is
it
> going to be true?
> 
> GetDrmDevice will always return !null and handles null input by returning the
> primary device. I didn't handle an invalid widget as input in a safe way but
> that's been addressed in latest patch as mentioned above.

Ok, I see. So if the surface_handle_ is null (for an offscreen context), we'll
revert to the primary device?
> 
> > 
> > Moving forward, would it make sense to pass the surface_handle explicitly
> here?
> 
> Explicitly as part of the CHROMIUM_image extension?

Possibly, or maybe implicitly as an internal detail of the implementation?

I guess I'm not sure I fully grok the constraint here. Is it that this surface
handle must match the handle the image will be swapped/overlayed to?

[reveman, 2016-07-14 21:23:40]

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
File gpu/ipc/service/gpu_command_buffer_stub.cc (right):

https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
gpu/ipc/service/gpu_command_buffer_stub.cc:1008: handle, size, format,
internalformat, surface_handle_);
On 2016/07/14 at 20:39:26, piman wrote:
> On 2016/07/14 20:00:59, reveman wrote:
> > On 2016/07/14 at 18:32:44, piman wrote:
> > > surface_handle_ will be null for offscreen contexts (everything except the
> > Display context in the browser - which currently is also the browser
compositor
> > context, but may not stay that way forever, because of the mus story and the
> > intent to share contexts more broadly).
> > 
> > hm, I'm not sure I understand exactly what this context sharing would mean.
Will
> > we potentially use an offscreen context for onscreen compositing? Or do we
just
> > need offscreen contexts that are not necessarily associated with the primary
drm
> > device?
> 
> The latter. Today the browser compositor (ui::Compositor) doesn't own the
GLRenderer, it sends a CompositorFrame to the Display - which then itself uses a
GLRenderer to produce the final frame.
> They just happen to use the same context (which is a view context, which has a
!null surface_handle_), but they don't have to.

Ok, creating an image for one context (drm device) and then trying to schedule
it as an overlay with another context/device is not really supported. Maybe the
solution is to just make sure the normal backbuffer image is always created for
the Display context that will schedule it as an overlay and overlay scheduling
of buffers associated with different drm devices fails gracefully with fallback
to normal compositing.

> 
> > 
> > > 
> > > At the very least, is this handled at the lower level, security-wise?
> > 
> > I updated to DrmDeviceManager::GetDrmDevice to not crash if passed an
invalid
> > widget in latest patch as that seems consistent with
> > DrmDeviceManager::RemoveDrmDevice. However, I'd be surprised if a client
managed
> > to create a context for an invalid widget and that did not causing a failure
or
> > crash somewhere else.
> > 
> > > 
> > > AFAICT it goes down to DrmThread::CreateBufferFromFds which then calls
> > device_manager_->GetDrmDevice(widget), expecting the result to be !null - is
it
> > going to be true?
> > 
> > GetDrmDevice will always return !null and handles null input by returning
the
> > primary device. I didn't handle an invalid widget as input in a safe way but
> > that's been addressed in latest patch as mentioned above.
> 
> Ok, I see. So if the surface_handle_ is null (for an offscreen context), we'll
revert to the primary device?

Correct.

> > 
> > > 
> > > Moving forward, would it make sense to pass the surface_handle explicitly
> > here?
> > 
> > Explicitly as part of the CHROMIUM_image extension?
> 
> Possibly, or maybe implicitly as an internal detail of the implementation?
> 
> I guess I'm not sure I fully grok the constraint here. Is it that this surface
handle must match the handle the image will be swapped/overlayed to?

Yes. Current code does this implicitly but it of course relies on having a
surface handle to find the drm device to use and that might need to be improved
for us to be able to create images using an offscreen context without a surface
handle that can be swapped/overlayed using a context that is not associated with
the primary drm device.

Can we have contexts in the same share group that use different drm devices? If
not then maybe that's a good way to find out what the appropriate drm device for
imports are when creating images using an offscreen context.

[reveman, 2016-07-14 21:23:44]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 21:24:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 21:24:42]

Your CL relies on deprecated CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is deprecated:
     tryserver.blink
   For more details, see http://crbug.com/617627.

[piman, 2016-07-14 21:42:44]

On Thu, Jul 14, 2016 at 2:23 PM, <reveman@chromium.org> wrote:

>
>
>
https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
> File gpu/ipc/service/gpu_command_buffer_stub.cc (right):
>
>
>
https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
> gpu/ipc/service/gpu_command_buffer_stub.cc:1008: handle, size, format,
> internalformat, surface_handle_);
> On 2016/07/14 at 20:39:26, piman wrote:
> > On 2016/07/14 20:00:59, reveman wrote:
> > > On 2016/07/14 at 18:32:44, piman wrote:
> > > > surface_handle_ will be null for offscreen contexts (everything
> except the
> > > Display context in the browser - which currently is also the browser
> compositor
> > > context, but may not stay that way forever, because of the mus story
> and the
> > > intent to share contexts more broadly).
> > >
> > > hm, I'm not sure I understand exactly what this context sharing
> would mean. Will
> > > we potentially use an offscreen context for onscreen compositing? Or
> do we just
> > > need offscreen contexts that are not necessarily associated with the
> primary drm
> > > device?
> >
> > The latter. Today the browser compositor (ui::Compositor) doesn't own
> the GLRenderer, it sends a CompositorFrame to the Display - which then
> itself uses a GLRenderer to produce the final frame.
> > They just happen to use the same context (which is a view context,
> which has a !null surface_handle_), but they don't have to.
>
> Ok, creating an image for one context (drm device) and then trying to
> schedule it as an overlay with another context/device is not really
> supported.
>

(not trying to block this CL if it works, you have a lgtm, I'm just trying
to figure out the right semantics)

Isn't it how it works for video/webgl overlays, though? Image is created in
the renderer context (offscreen), then possibly scheduled as an overlay in
the Display context, if possible.


> Maybe the solution is to just make sure the normal backbuffer
> image is always created for the Display context that will schedule it as
> an overlay and overlay scheduling of buffers associated with different
> drm devices fails gracefully with fallback to normal compositing.
>
> >
> > >
> > > >
> > > > At the very least, is this handled at the lower level,
> security-wise?
> > >
> > > I updated to DrmDeviceManager::GetDrmDevice to not crash if passed
> an invalid
> > > widget in latest patch as that seems consistent with
> > > DrmDeviceManager::RemoveDrmDevice. However, I'd be surprised if a
> client managed
> > > to create a context for an invalid widget and that did not causing a
> failure or
> > > crash somewhere else.
> > >
> > > >
> > > > AFAICT it goes down to DrmThread::CreateBufferFromFds which then
> calls
> > > device_manager_->GetDrmDevice(widget), expecting the result to be
> !null - is it
> > > going to be true?
> > >
> > > GetDrmDevice will always return !null and handles null input by
> returning the
> > > primary device. I didn't handle an invalid widget as input in a safe
> way but
> > > that's been addressed in latest patch as mentioned above.
> >
> > Ok, I see. So if the surface_handle_ is null (for an offscreen
> context), we'll revert to the primary device?
>
> Correct.
>
> > >
> > > >
> > > > Moving forward, would it make sense to pass the surface_handle
> explicitly
> > > here?
> > >
> > > Explicitly as part of the CHROMIUM_image extension?
> >
> > Possibly, or maybe implicitly as an internal detail of the
> implementation?
> >
> > I guess I'm not sure I fully grok the constraint here. Is it that this
> surface handle must match the handle the image will be swapped/overlayed
> to?
>
> Yes. Current code does this implicitly but it of course relies on having
> a surface handle to find the drm device to use and that might need to be
> improved for us to be able to create images using an offscreen context
> without a surface handle that can be swapped/overlayed using a context
> that is not associated with the primary drm device.
>
> Can we have contexts in the same share group that use different drm
> devices?
>

I think the drm device is used for different things, 2 could be involved:
1- creating/importing buffers to use as a texture, as well as pushing GPU
commands
2- presenting images on screen

I believe that all contexts in the same share group must share (1) -
otherwise I'm not sure how creating a texture in one context and destroying
it in another context would work.

I /think/ (2) does not necessarily have to be the same as (1) in Ozone, and
maybe that's the root of the issue here. It may be that we have to import
the dma_buf onto 2 separate DRM devices, one to render to, and one to scan
out from. So I think it's not so much that we need to pick the right drm
device when importing it as a texture - it has to be the one used by the
context for texturing - but when scheduling for overlays, if the drm device
it was imported into is not the same it will be scanned out from, we
probably need to re-import it to the latter one, and that could be what's
missing here.


> If not then maybe that's a good way to find out what the
> appropriate drm device for imports are when creating images using an
> offscreen context.
>
> https://codereview.chromium.org/2148983002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-07-14 22:35:29]

On Thu, Jul 14, 2016 at 5:42 PM, Antoine Labour <piman@chromium.org> wrote:

>
>
> On Thu, Jul 14, 2016 at 2:23 PM, <reveman@chromium.org> wrote:
>
>>
>>
>>
https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
>> File gpu/ipc/service/gpu_command_buffer_stub.cc (right):
>>
>>
>>
https://codereview.chromium.org/2148983002/diff/20001/gpu/ipc/service/gpu_com...
>> gpu/ipc/service/gpu_command_buffer_stub.cc:1008: handle, size, format,
>> internalformat, surface_handle_);
>> On 2016/07/14 at 20:39:26, piman wrote:
>> > On 2016/07/14 20:00:59, reveman wrote:
>> > > On 2016/07/14 at 18:32:44, piman wrote:
>> > > > surface_handle_ will be null for offscreen contexts (everything
>> except the
>> > > Display context in the browser - which currently is also the browser
>> compositor
>> > > context, but may not stay that way forever, because of the mus story
>> and the
>> > > intent to share contexts more broadly).
>> > >
>> > > hm, I'm not sure I understand exactly what this context sharing
>> would mean. Will
>> > > we potentially use an offscreen context for onscreen compositing? Or
>> do we just
>> > > need offscreen contexts that are not necessarily associated with the
>> primary drm
>> > > device?
>> >
>> > The latter. Today the browser compositor (ui::Compositor) doesn't own
>> the GLRenderer, it sends a CompositorFrame to the Display - which then
>> itself uses a GLRenderer to produce the final frame.
>> > They just happen to use the same context (which is a view context,
>> which has a !null surface_handle_), but they don't have to.
>>
>> Ok, creating an image for one context (drm device) and then trying to
>> schedule it as an overlay with another context/device is not really
>> supported.
>>
>
> (not trying to block this CL if it works, you have a lgtm, I'm just trying
> to figure out the right semantics)
>
> Isn't it how it works for video/webgl overlays, though? Image is created
> in the renderer context (offscreen), then possibly scheduled as an overlay
> in the Display context, if possible.
>

We don't actually support this today (video/webgl overlays on non primary
drm device) but yes, a GLImage created by the renderer cannot be scheduled
as an overlay on a non-primary drm device. However, it can still be used as
a texture.


>
>
>> Maybe the solution is to just make sure the normal backbuffer
>> image is always created for the Display context that will schedule it as
>> an overlay and overlay scheduling of buffers associated with different
>> drm devices fails gracefully with fallback to normal compositing.
>>
>> >
>> > >
>> > > >
>> > > > At the very least, is this handled at the lower level,
>> security-wise?
>> > >
>> > > I updated to DrmDeviceManager::GetDrmDevice to not crash if passed
>> an invalid
>> > > widget in latest patch as that seems consistent with
>> > > DrmDeviceManager::RemoveDrmDevice. However, I'd be surprised if a
>> client managed
>> > > to create a context for an invalid widget and that did not causing a
>> failure or
>> > > crash somewhere else.
>> > >
>> > > >
>> > > > AFAICT it goes down to DrmThread::CreateBufferFromFds which then
>> calls
>> > > device_manager_->GetDrmDevice(widget), expecting the result to be
>> !null - is it
>> > > going to be true?
>> > >
>> > > GetDrmDevice will always return !null and handles null input by
>> returning the
>> > > primary device. I didn't handle an invalid widget as input in a safe
>> way but
>> > > that's been addressed in latest patch as mentioned above.
>> >
>> > Ok, I see. So if the surface_handle_ is null (for an offscreen
>> context), we'll revert to the primary device?
>>
>> Correct.
>>
>> > >
>> > > >
>> > > > Moving forward, would it make sense to pass the surface_handle
>> explicitly
>> > > here?
>> > >
>> > > Explicitly as part of the CHROMIUM_image extension?
>> >
>> > Possibly, or maybe implicitly as an internal detail of the
>> implementation?
>> >
>> > I guess I'm not sure I fully grok the constraint here. Is it that this
>> surface handle must match the handle the image will be swapped/overlayed
>> to?
>>
>> Yes. Current code does this implicitly but it of course relies on having
>> a surface handle to find the drm device to use and that might need to be
>> improved for us to be able to create images using an offscreen context
>> without a surface handle that can be swapped/overlayed using a context
>> that is not associated with the primary drm device.
>>
>> Can we have contexts in the same share group that use different drm
>> devices?
>>
>
> I think the drm device is used for different things, 2 could be involved:
> 1- creating/importing buffers to use as a texture, as well as pushing GPU
> commands
> 2- presenting images on screen
>
> I believe that all contexts in the same share group must share (1) -
> otherwise I'm not sure how creating a texture in one context and destroying
> it in another context would work.
>
> I /think/ (2) does not necessarily have to be the same as (1) in Ozone,
> and maybe that's the root of the issue here. It may be that we have to
> import the dma_buf onto 2 separate DRM devices, one to render to, and one
> to scan out from. So I think it's not so much that we need to pick the
> right drm device when importing it as a texture - it has to be the one used
> by the context for texturing - but when scheduling for overlays, if the drm
> device it was imported into is not the same it will be scanned out from, we
> probably need to re-import it to the latter one, and that could be what's
> missing here.
>

Yes, if we want maximum support then that's probably what we should do. We
can then use the buffer as a texture with one drm device and schedule it as
an overlay with another drm device. The best way to support this might be
to pass GMB quads between compositors instead of texture mailboxes as that
allows us to explicitly do the import (create the GLImage) for each
compositor and the drm device used by that compositor.


>
>
>> If not then maybe that's a good way to find out what the
>> appropriate drm device for imports are when creating images using an
>> offscreen context.
>>
>> https://codereview.chromium.org/2148983002/
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[commit-bot: I haz the power, 2016-07-15 00:41:27]

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

[commit-bot: I haz the power, 2016-07-15 00:41:29]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[reveman, 2016-07-18 23:58:59]

reveman@chromium.org changed reviewers:
+ rjkroege@chromium.org

[reveman, 2016-07-18 23:59:00]

+rjkroege for ui/ozone/public

[reveman, 2016-07-18 23:59:10]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-18 23:59:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-18 23:59:59]

Your CL relies on deprecated CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is deprecated:
     tryserver.blink
   For more details, see http://crbug.com/617627.

[commit-bot: I haz the power, 2016-07-19 01:55:55]

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

[commit-bot: I haz the power, 2016-07-19 01:55:56]

Dry run: This issue passed the CQ dry run.

[rjkroege, 2016-07-19 17:54:44]

lgtm

[reveman, 2016-07-19 18:12:28]

The CQ bit was checked by reveman@chromium.org

[reveman, 2016-07-19 18:12:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
dnicoara@chromium.org, posciak@chromium.org
Link to the patchset: https://codereview.chromium.org/2148983002/#ps40001
(title: "avoid crash in DrmDeviceManager::GetDrmDevice when passed invalid
widget")

[commit-bot: I haz the power, 2016-07-19 18:13:39]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 18:13:42]

Your CL relies on deprecated CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is deprecated:
     tryserver.blink
   For more details, see http://crbug.com/617627.

[commit-bot: I haz the power, 2016-07-19 18:21:46]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-07-19 18:24:03]

Description was changed from

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807,597932
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
gpu: Take surface handle into account when importing buffers.

This makes us use the appropriate DRM device when importing
native GMBs on Ozone instead of always using the primary device.

BUG=626807,597932
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/15e3d9a4516ad22cc56c1ff162f32f3d03e8de9f
Cr-Commit-Position: refs/heads/master@{#406322}
==========

[commit-bot: I haz the power, 2016-07-19 18:24:05]

Patchset 3 (id:??) landed as
https://crrev.com/15e3d9a4516ad22cc56c1ff162f32f3d03e8de9f
Cr-Commit-Position: refs/heads/master@{#406322}