ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

It's follow-up for https://codereview.chromium.org/1401063002/

In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html
BUG=538325
Committed: https://crrev.com/466c3f1235fdfcabca07e351748ebc2678f59ffa
Cr-Commit-Position: refs/heads/master@{#366591}

[dshwang, 2015-11-27 14:33:08]

Description was changed from

==========
ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888

It's follow-up for https://codereview.chromium.org/1401063002/

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
BUG=538325
==========

to

==========
ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888

It's follow-up for https://codereview.chromium.org/1401063002/

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
BUG=538325
==========

[dshwang, 2015-11-27 14:33:08]

dongseong.hwang@intel.com changed reviewers:
+ alexst@chromium.org, reveman@chromium.org

[dshwang, 2015-11-27 14:33:39]

dongseong.hwang@intel.com changed reviewers:
+ piman@chromium.org

[dshwang, 2015-11-27 14:34:00]

alexst, reveman, could you review? It's follow-up for
https://codereview.chromium.org/1401063002/

[dshwang, 2015-11-27 17:59:54]

https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (left):

https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ =
GBM_FORMAT_XRGB8888;
This hack was introduced by https://codereview.chromium.org/1314553002
Choosing XRGB or XRGB is role of drm_overlay_candidates_hosts, not here.

It causes crash of gl_unittests in 
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...

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

https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:18: fb_pixel_format_ =
gbm_bo_get_format(bo);
fb_pixel_format_ is used in GetBufferFormat() even for GPU_READ_WRITE buffer.

[reveman, 2015-11-27 20:09:33]

lgtm but we should really be querying gbm to find out what formats are
supported.

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

https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:18: fb_pixel_format_ =
gbm_bo_get_format(bo);
On 2015/11/27 at 17:59:54, dshwang_OOO_till_4thDec wrote:
> fb_pixel_format_ is used in GetBufferFormat() even for GPU_READ_WRITE buffer.

can you move this into the initialization list?

[kalyank, 2015-11-27 21:15:20]

kalyan.kondapally@intel.com changed reviewers:
+ kalyan.kondapally@intel.com

[kalyank, 2015-11-27 21:15:20]

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

https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:18: fb_pixel_format_ =
gbm_bo_get_format(bo);
On 2015/11/27 17:59:54, dshwang_OOO_till_4thDec wrote:
> fb_pixel_format_ is used in GetBufferFormat() even for GPU_READ_WRITE buffer.

Here storage format can be different to pixel format. This is not something
OverlayCandidateHost can decide as it’s very specific to how we register the
framebuffer. Currently, we always create fb of 24 bitcolordepth.
GetFramebufferPixelFormat returns the Frame buffer format for this buffer.
GetBufferFormat should return the pixel format, we could just query it directly
from gbm there? If we want to cache the value than we need to separate it from
fb_pixel_format_

[piman, 2015-11-30 19:13:49]

LGTM for content/

[dshwang, 2015-12-11 03:05:07]

Hi thanks for reviewing. I'm back from vacation.

As kalyank notes, drm doesn't support 32bit plane for overlay. If launching with
--ozone-test-single-overlay-support, patch set 2 crash when page flipping.
kalyank introduces to create always 24 bits plane for BGRA in
https://codereview.chromium.org/133350300
This CL extends the hack to cover RGBA also. In addition,
GetFramebufferPixelFormat returns the actual format of the plane, while
GetBufferFormat returns supporting format.
 
kalyank, alexst, could you review again?

[dshwang, 2015-12-11 03:05:35]

Description was changed from

==========
ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888

It's follow-up for https://codereview.chromium.org/1401063002/

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
BUG=538325
==========

to

==========
ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888

It's follow-up for https://codereview.chromium.org/1401063002/

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325
==========

[kalyank, 2015-12-11 04:52:31]

On 2015/12/11 03:05:07, dshwang wrote:
> Hi thanks for reviewing. I'm back from vacation.
> 
> As kalyank notes, drm doesn't support 32bit plane for overlay. If launching
with
> --ozone-test-single-overlay-support, patch set 2 crash when page flipping.
> kalyank introduces to create always 24 bits plane for BGRA in
> https://codereview.chromium.org/133350300
> This CL extends the hack to cover RGBA also. In addition,
> GetFramebufferPixelFormat returns the actual format of the plane, while
> GetBufferFormat returns supporting format.
>  
> kalyank, alexst, could you review again?

Not sure what kernel version you are testing on, looks like you are
missing support for "type" property. This is used to identify 
dedicated cursor plane and ensure we don't use it for any other
purpose. As you actually were able to use Overlays,
that means you ended up using Cursor plane to display Video
buffer. This is because, we don't support ARGB format
on any other plane than Cursor and format checks might have 
succeeded in Plane Manager. This might have resulted in binding 
the Video buffer to Cursor plane resulting in crash. 
What should really happen in this case is that we never end up 
using Overlays and not crash.

I am not sure if I want to call it a hack :). As hardware doesn't
yet have support for alpha composition, the framebuffers are
registered as 24bit and planes (other than cursor) have support
for XRGB. That's the reason we have split FrameBuffer Storage 
format from actual pixel format. This helps checking for
right format support in plane manager.

[kalyank, 2015-12-11 04:57:41]

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right):

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:17: : drm_(drm), bo_(bo),
fb_pixel_format_(gbm_bo_get_format(bo)) {
Unless its a scanout buffer and the buffer is registered, fb_pixel_format_should
just return 0. We should just leave this as before.

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ ==
GBM_FORMAT_ABGR8888)
ABGR, is this format going to be used ?

[dshwang, 2015-12-11 07:17:33]

alexst, kalyank, could you review again?

On 2015/12/11 04:52:31, kalyank wrote:
> Not sure what kernel version you are testing on, looks like you are
> missing support for "type" property. This is used to identify 
> dedicated cursor plane and ensure we don't use it for any other
> purpose. As you actually were able to use Overlays,
> that means you ended up using Cursor plane to display Video
> buffer. This is because, we don't support ARGB format
> on any other plane than Cursor and format checks might have 
> succeeded in Plane Manager. This might have resulted in binding 
> the Video buffer to Cursor plane resulting in crash. 
> What should really happen in this case is that we never end up 
> using Overlays and not crash.

I tests using amd64-generic_freon on Broadwell.

chrome is fine, but content_unittests crash. This CL intends to fix
content_unittests

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right):

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:17: : drm_(drm), bo_(bo),
fb_pixel_format_(gbm_bo_get_format(bo)) {
On 2015/12/11 04:57:41, kalyank wrote:
> Unless its a scanout buffer and the buffer is registered,
fb_pixel_format_should
> just return 0. We should just leave this as before.

Ok, agree.
To clarify, rename it to framebuffer_pixel_format_;

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ ==
GBM_FORMAT_ABGR8888)
On 2015/12/11 04:57:41, kalyank wrote:
> ABGR, is this format going to be used ?

ABGR is not used by chrome. However, ozone gbm supports ABGR scanout buffer, and
content_unittests covers if it works.
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...

[kalyank, 2015-12-11 19:07:12]

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right):

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ ==
GBM_FORMAT_ABGR8888)
On 2015/12/11 07:17:32, dshwang wrote:
> On 2015/12/11 04:57:41, kalyank wrote:
> > ABGR, is this format going to be used ?
> 
> ABGR is not used by chrome. However, ozone gbm supports ABGR scanout buffer,
and
> content_unittests covers if it works.
>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...

Only BGRA and RGBA are advertised. In BGRA case, format has to be
GBM_FORMAT_BGRX8888.

[dshwang, 2015-12-13 05:28:52]

Description was changed from

==========
ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888

It's follow-up for https://codereview.chromium.org/1401063002/

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325
==========

to

==========
ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

It's follow-up for https://codereview.chromium.org/1401063002/

In addition, this CL fixes content_unittests crash about
gfx::BufferFormat::RGBA_8888

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325
==========

[dshwang, 2015-12-13 05:34:44]

Change the CL's purpose; support gfx::BufferFormat::RGBX_8888

Currently, ozone supports RGBX_8888 incompletely. It's why content_unittests
crashes. Support it completely.

alexst, kalyank, could you review again?

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right):

https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ ==
GBM_FORMAT_ABGR8888)
On 2015/12/11 19:07:12, kalyank wrote:
> On 2015/12/11 07:17:32, dshwang wrote:
> > On 2015/12/11 04:57:41, kalyank wrote:
> > > ABGR, is this format going to be used ?
> > 
> > ABGR is not used by chrome. However, ozone gbm supports ABGR scanout buffer,
> and
> > content_unittests covers if it works.
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...
> 
> Only BGRA and RGBA are advertised. In BGRA case, format has to be
> GBM_FORMAT_BGRX8888.

Got it. New CL supports both BGRX8888 and RGBX8888.

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c...
File ui/ozone/platform/drm/client_native_pixmap_factory_gbm.cc (right):

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c...
ui/ozone/platform/drm/client_native_pixmap_factory_gbm.cc:53: format ==
gfx::BufferFormat::RGBX_8888 ||
ozone gbm supports RGBX also.

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c...
File ui/ozone/platform/drm/common/drm_util.cc (right):

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c...
ui/ozone/platform/drm/common/drm_util.cc:310: int
GetFourCCFormatForFramebuffer(gfx::BufferFormat format) {
Now, this code is maintained by this function.

[kalyank, 2015-12-15 00:55:12]

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat();
These changes now broke checks in VaapiWrapper. 
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...

Expectation is to return the framebuffer format here. Perhaps have another API
like GetStorageFormat which returns the internal format and GetBufferFormat
would return the pixel format as you have done.

[dshwang, 2015-12-15 04:48:31]

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):

https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat();
On 2015/12/15 00:55:12, kalyank wrote:
> These changes now broke checks in VaapiWrapper. 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> 
> Expectation is to return the framebuffer format here. Perhaps have another API
> like GetStorageFormat which returns the internal format and GetBufferFormat
> would return the pixel format as you have done.

Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because Vaapi
wants to decode directly into dma_buf. [1][2]
[1]
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...
[2]
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...

So it doesn't break promise with VaapiWrapper.

In addition (1), content (e.g. VaapiWrapper) should not know how ozone changes
framebuffer format internally. It's so implementation detail. If something
becomes wrong, ozone should handle it by itself. It's why I felt format changing
is a bit hackish and move the code into one place.

In addition (2), VaapiWrapper creates only BGRX_8888 and UYVY_422. When
extending more format support for Vaapi, the switch statement should be updated
at the time. VaapiWrapper is ozone client, not ozone.

[kalyank, 2015-12-15 05:18:48]

On 2015/12/15 04:48:31, dshwang (in Korea) wrote:
>
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
> File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):
> 
>
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
> ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat();
> On 2015/12/15 00:55:12, kalyank wrote:
> > These changes now broke checks in VaapiWrapper. 
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > 
> > Expectation is to return the framebuffer format here. Perhaps have another
API
> > like GetStorageFormat which returns the internal format and GetBufferFormat
> > would return the pixel format as you have done.
> 
> Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because Vaapi
> wants to decode directly into dma_buf. [1][2]
> [1]
>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...
> [2]
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> 
> So it doesn't break promise with VaapiWrapper.

Well it does and I dont like vaapiWrapper making assumptions that this is the
internal
format for this given format. That should come from NativePixmap in this case,
so
in future when we have support for alpha composition/32 bit formats it should be
handled in GbmBufferBase which is responsible for frame buffer registration.

> In addition (1), content (e.g. VaapiWrapper) should not know how ozone changes
> framebuffer format internally. It's so implementation detail. If something
> becomes wrong, ozone should handle it by itself. It's why I felt format
changing
> is a bit hackish and move the code into one place.

Not really, correct format needs to be used depending on the usage.Depending
on if you want to sample from it or Scan it out, you need to know the format
and internal/storage/framebuffer format.

> 
> In addition (2), VaapiWrapper creates only BGRX_8888 and UYVY_422. When
> extending more format support for Vaapi, the switch statement should be
updated
> at the time. VaapiWrapper is ozone client, not ozone.

[kalyank, 2015-12-15 05:22:00]

On 2015/12/15 05:18:48, kalyank wrote:
> On 2015/12/15 04:48:31, dshwang (in Korea) wrote:
> >
>
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
> > File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):
> > 
> >
>
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
> > ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat();
> > On 2015/12/15 00:55:12, kalyank wrote:
> > > These changes now broke checks in VaapiWrapper. 
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > > 
> > > Expectation is to return the framebuffer format here. Perhaps have another
> API
> > > like GetStorageFormat which returns the internal format and
GetBufferFormat
> > > would return the pixel format as you have done.
> > 
> > Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because
Vaapi
> > wants to decode directly into dma_buf. [1][2]
> > [1]
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...
> > [2]
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > 
> > So it doesn't break promise with VaapiWrapper.
> 
> Well it does and I dont like vaapiWrapper making assumptions that this is the
> internal
> format for this given format. That should come from NativePixmap in this case,
> so
> in future when we have support for alpha composition/32 bit formats it should
be
> handled in GbmBufferBase which is responsible for frame buffer registration.
> 
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
You can check how this is being used here. Have you tried enabling Overlay
support and
play video ?

[dshwang, 2015-12-15 05:40:59]

On 2015/12/15 05:22:00, kalyank wrote:
> On 2015/12/15 05:18:48, kalyank wrote:
> > On 2015/12/15 04:48:31, dshwang (in Korea) wrote:
> > >
> >
>
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
> > > File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g...
> > > ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat();
> > > On 2015/12/15 00:55:12, kalyank wrote:
> > > > These changes now broke checks in VaapiWrapper. 
> > > >
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > > > 
> > > > Expectation is to return the framebuffer format here. Perhaps have
another
> > API
> > > > like GetStorageFormat which returns the internal format and
> GetBufferFormat
> > > > would return the pixel format as you have done.
> > > 
> > > Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because
> Vaapi
> > > wants to decode directly into dma_buf. [1][2]
> > > [1]
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...
> > > [2]
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > > 
> > > So it doesn't break promise with VaapiWrapper.
> > 
> > Well it does and I dont like vaapiWrapper making assumptions that this is
the
> > internal
> > format for this given format. That should come from NativePixmap in this
case,
> > so
> > in future when we have support for alpha composition/32 bit formats it
should
> be
> > handled in GbmBufferBase which is responsible for frame buffer registration.
> > 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> You can check how this is being used here. Have you tried enabling Overlay
> support and
> play video ?

yes, as description said TEST=chrome --ozone-platform=gbm
--ozone-use-surfaceless --ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html

Could you feedback again? do you think this CL lgtm?

[kalyank, 2015-12-15 06:27:50]

>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > You can check how this is being used here. Have you tried enabling Overlay
> > support and
> > play video ?
> 
> yes, as description said TEST=chrome --ozone-platform=gbm
> --ozone-use-surfaceless --ozone-test-single-overlay-support
> http://www.quirksmode.org/html5/tests/video.html
> 
> Could you feedback again? do you think this CL lgtm?

Non owner LGTM.

[dshwang, 2015-12-15 07:46:52]

dongseong.hwang@intel.com changed reviewers:
+ spang@chromium.org

[dshwang, 2015-12-15 07:47:36]

On 2015/12/15 06:27:50, kalyank wrote:
> Non owner LGTM.

Thank you for reviewing.

alexst, spang, could you review ui/ozone?

[kalyank, 2015-12-21 20:10:08]

kalyan.kondapally@intel.com changed reviewers:
+ dnicoara@chromium.org

[kalyank, 2015-12-21 20:10:48]

On 2015/12/15 07:47:36, dshwang (in Korea) wrote:
> On 2015/12/15 06:27:50, kalyank wrote:
> > Non owner LGTM.
> 
> Thank you for reviewing.
> 
> alexst, spang, could you review ui/ozone?

+dnicoara

[dnicoara, 2015-12-21 21:36:41]

lgtm

[dshwang, 2015-12-22 12:31:47]

The CQ bit was checked by dongseong.hwang@intel.com

[dshwang, 2015-12-22 12:31:47]

The patchset sent to the CQ was uploaded after l-g-t-m from
reveman@chromium.org, piman@chromium.org, kalyan.kondapally@intel.com
Link to the patchset: https://codereview.chromium.org/1483633002/#ps100001
(title: "fix gl_image_ozone_native_pixmap also, which gl_unittests check")

[commit-bot: I haz the power, 2015-12-22 12:32:22]

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

[commit-bot: I haz the power, 2015-12-22 13:00:51]

Description was changed from

==========
ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

It's follow-up for https://codereview.chromium.org/1401063002/

In addition, this CL fixes content_unittests crash about
gfx::BufferFormat::RGBA_8888

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325
==========

to

==========
ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

It's follow-up for https://codereview.chromium.org/1401063002/

In addition, this CL fixes content_unittests crash about
gfx::BufferFormat::RGBA_8888

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325
==========

[commit-bot: I haz the power, 2015-12-22 13:00:52]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-12-22 13:02:01]

Description was changed from

==========
ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

It's follow-up for https://codereview.chromium.org/1401063002/

In addition, this CL fixes content_unittests crash about
gfx::BufferFormat::RGBA_8888

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325
==========

to

==========
ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.

It's follow-up for https://codereview.chromium.org/1401063002/

In addition, this CL fixes content_unittests crash about
gfx::BufferFormat::RGBA_8888

TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm
--ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless
--ozone-test-single-overlay-support
http://www.quirksmode.org/html5/tests/video.html
BUG=538325

Committed: https://crrev.com/466c3f1235fdfcabca07e351748ebc2678f59ffa
Cr-Commit-Position: refs/heads/master@{#366591}
==========

[commit-bot: I haz the power, 2015-12-22 13:02:02]

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