The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e20a28481a953a96aed30f5a284ecb4395d9d2a3

commit e20a28481a953a96aed30f5a284ecb4395d9d2a3
Author: dcastagna <dcastagna@chromium.org>
Date: Fri Feb 24 01:26:04 2017

exo: Add --transparent-background to wayland client.

We want to support translucent HW overlays.

This CL adds an option to wayland_motion_events to have a transparent
background that can be used to help debuging and testing translucent HW
overlays.

BUG= 695296 

Review-Url: https://codereview.chromium.org/2710353002
Cr-Commit-Position: refs/heads/master@{#452708}

[modify] https://crrev.com/e20a28481a953a96aed30f5a284ecb4395d9d2a3/components/exo/wayland/clients/motion_events.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8409354a9334874b7d00d4f1379a0a2d62c8fbd7

commit 8409354a9334874b7d00d4f1379a0a2d62c8fbd7
Author: dcastagna <dcastagna@chromium.org>
Date: Tue Mar 14 02:11:13 2017

cc: Add gfx::BufferFormat to cc::ResourceProvider::Resource.

cc::ResourceProvider::Resource::format corresponds to the format as seen
from the compositor and/or GL.

This format might not be the same as the actual buffer format that was
used to create the resource.
For example, a YUV buffer can be used to create a texture/resource with
RGBX internalformat.

The actual format of the buffer is needed to determine if configurations
of quads/resources can be used as overlays. So far we always assumed
the format for overlay candidates was RGBA.

This CL adds a cc::ResourceProvider::Resource::buffer_format that
is the format of the buffer used to create the resource.

Exo code has been changed accordingly to add set the appropriate format.

This CL just adds all the plumbing necessary to bring BufferFormat
all the way to OverlayCandidate, but doesn't change any logic when
creating overlay candidates.

BUG= 695296 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2748903002
Cr-Commit-Position: refs/heads/master@{#456573}

[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/ipc/transferable_resource.mojom
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/ipc/transferable_resource_struct_traits.cc
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/ipc/transferable_resource_struct_traits.h
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/output/overlay_candidate.cc
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/resources/resource_provider.cc
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/resources/resource_provider.h
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/resources/transferable_resource.cc
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/cc/resources/transferable_resource.h
[modify] https://crrev.com/8409354a9334874b7d00d4f1379a0a2d62c8fbd7/components/exo/buffer.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f38d0be624e674372eef59873b7da2206e8275df

commit f38d0be624e674372eef59873b7da2206e8275df
Author: dcastagna <dcastagna@chromium.org>
Date: Tue Mar 14 02:27:06 2017

cc: Reject non-opaque fullscreen overlay candidates.

When replacing the primary plane with a fullscreen overlay,
we need to make sure that the quad is completely opaque.

OverlayCandidate::FromDrawQuad currently rejects non-opaque drawquads.

Since we're planning to use non-opaque overlays, FromDrawQuad will allow
transparent candidates in the future.

This CL makes sure that the fullscreen strategy explicitly rejects
non-opaque quads and doesn't rely on OverlayCandidate::FromDrawQuad
that will soon change its behavior.

BUG= 695296 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2739473002
Cr-Commit-Position: refs/heads/master@{#456583}

[modify] https://crrev.com/f38d0be624e674372eef59873b7da2206e8275df/cc/output/overlay_strategy_fullscreen.cc
[modify] https://crrev.com/f38d0be624e674372eef59873b7da2206e8275df/cc/output/overlay_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8b03b3715b4f951d87890c6ef9f6cbe027f777f0

commit 8b03b3715b4f951d87890c6ef9f6cbe027f777f0
Author: dcastagna <dcastagna@chromium.org>
Date: Tue Mar 14 19:29:59 2017

cc: Make OverlayCandidate use gfx::BufferFormat instead of cc::ResourceFormat.

Use gfx::BufferFormat instead of cc::ResourceFormat in OverlayCandidate.

With crrev.com/2748903002 gfx::BufferFormat has been added to Resource.
OverlayCandidate can now use that gfx::BufferFormat instead of using
and hardcoded RGBA Resource format.

This patch was pulled from crrev.com/2683763003 patch 1. The original author is dongseong.hwang.

BUG= 695296 , 683347 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2745143003
Cr-Commit-Position: refs/heads/master@{#456785}

[modify] https://crrev.com/8b03b3715b4f951d87890c6ef9f6cbe027f777f0/cc/output/overlay_candidate.cc
[modify] https://crrev.com/8b03b3715b4f951d87890c6ef9f6cbe027f777f0/cc/output/overlay_candidate.h
[modify] https://crrev.com/8b03b3715b4f951d87890c6ef9f6cbe027f777f0/components/display_compositor/compositor_overlay_candidate_validator_ozone.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/786f5cde9ec32c296aa372006df3fa3e07dd03be

commit 786f5cde9ec32c296aa372006df3fa3e07dd03be
Author: dcastagna <dcastagna@chromium.org>
Date: Wed Mar 15 14:59:28 2017

cc: Pick the biggest Quad when selecting an overlay.

When selecting an overlay with OverlayStrategySingleOnTop, that picks
only one quad to be used as HW overlays, prefer a bigger quad than
a small one.

This is convenient in cases where we get buffers from exo, where one
buffer reprents a title bar and one the content.
Before this patch we might have schedule the title bar as HW overlay
since it comes first in the rendering order.
After this CL we should prioritize the content.

BUG= 695296 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2746393005
Cr-Commit-Position: refs/heads/master@{#457079}

[modify] https://crrev.com/786f5cde9ec32c296aa372006df3fa3e07dd03be/cc/output/overlay_strategy_single_on_top.cc
[modify] https://crrev.com/786f5cde9ec32c296aa372006df3fa3e07dd03be/cc/output/overlay_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d7a8aef95959ab06d2b565fe129fd27ed42b963

commit 9d7a8aef95959ab06d2b565fe129fd27ed42b963
Author: dcastagna <dcastagna@chromium.org>
Date: Thu Mar 16 17:45:05 2017

ozone: Add an opaque fb to ScanoutBuffer for primary planes.

While all planes on rockchip support alpha, scanning out a primary
plane with an fb that was created with a format with alpha will result
in black pixels.

This patch adds an additional fb to a ScanoutBuffer to be used for the
primary plane.
When a buffer is created with a format that has alpha (e.g: RGBA),
an additional fb with a format without alpha (e.g. RGBX) will be added for
the same buffer.

In this way, when the buffer is scheduled for scanout as primary plane
we can use the fb added with a format without alpha and actually see
colors on the screen, instead of having everything black.

BUG= 695296 

Review-Url: https://codereview.chromium.org/2743403005
Cr-Commit-Position: refs/heads/master@{#457482}

[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/common/drm_util.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/common/drm_util.h
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/drm_buffer.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/drm_buffer.h
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/drm_overlay_validator.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/drm_overlay_validator_unittest.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/gbm_buffer_base.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/gbm_buffer_base.h
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/hardware_display_plane_manager_atomic.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/hardware_display_plane_manager_legacy.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/mock_scanout_buffer.cc
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/mock_scanout_buffer.h
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/scanout_buffer.h
[modify] https://crrev.com/9d7a8aef95959ab06d2b565fe129fd27ed42b963/ui/ozone/platform/drm/gpu/screen_manager.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/21fe8132924302ea1d830c3df055725cd9efeb8b

commit 21fe8132924302ea1d830c3df055725cd9efeb8b
Author: dcastagna <dcastagna@chromium.org>
Date: Thu Mar 16 20:04:17 2017

cc: Enable non-opaque harware overlays.

This CL enables alpha-blended HW overlays.

Additionally, it clears up the way overlay candidates might or might not
be considered based on buffer format and alpha blending requested:

- An opacity on the quad different than 1 will cause the candidate to
  always be rejected since we can't modulate the alpha of an overlay plane.

- We support only kSrc (no blending) and kSrcOver (blend) blending modes.

- For fullscreen overlays we can allow both blending modes as long as the
  opaque rect is as big as the buffer (ShouldDrawWithBlending() true).
  An opaque FD will always be used in this case (crrev.com/2743403005).

- For non-fullscreen overlays, we can't allow kSrc if the buffer has a
  format with an alpha channel, since the alpha channel might not be
  initialized and we don't disable blending when scanning out yet.

BUG= 695296 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2749783006
Cr-Commit-Position: refs/heads/master@{#457528}

[modify] https://crrev.com/21fe8132924302ea1d830c3df055725cd9efeb8b/cc/output/overlay_candidate.cc
[modify] https://crrev.com/21fe8132924302ea1d830c3df055725cd9efeb8b/cc/output/overlay_strategy_fullscreen.cc
[modify] https://crrev.com/21fe8132924302ea1d830c3df055725cd9efeb8b/cc/output/overlay_strategy_single_on_top.cc
[modify] https://crrev.com/21fe8132924302ea1d830c3df055725cd9efeb8b/cc/output/overlay_unittest.cc