ozone: gbm: Add overlay support

ui/ozone/platform/dri/dri_wrapper.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/ozone/platform/dri/dri_wrapper.h"
 
 #include <fcntl.h>
 #include <unistd.h>
 #include <xf86drm.h>
 #include <xf86drmMode.h>
 
 #include "base/logging.h"
 
 namespace ui {
+namespace {
+uint32_t ToFixedPoint(double v) {
+  // This returns a number in a 16-bit.16-bit fixed point.
+  return v * 65536.0;
+}
+}  // namespace
 
 DriWrapper::DriWrapper(const char* device_path) {
   fd_ = open(device_path, O_RDWR | O_CLOEXEC);
 }
 
 DriWrapper::~DriWrapper() {
   if (fd_ >= 0)
     close(fd_);
 }
 
@@ skipping 54 matching lines @@
                           uint32_t framebuffer,
                           void* data) {
   CHECK(fd_ >= 0);
   return !drmModePageFlip(fd_,
                           crtc_id,
                           framebuffer,
                           DRM_MODE_PAGE_FLIP_EVENT,
                           data);
 }
 
+bool DriWrapper::PageFlipOverlay(uint32_t crtc_id,
+                                 uint32_t framebuffer,
+                                 const gfx::Rect& location,
+                                 const gfx::RectF& source,

[alexst (slow to review), 2014/07/08 17:22:32]

In this case source is meant to be in [0, 1] uv space, like texture lookups.
Passing it as is below doesn't give you the right values, you need to multiply
it by size.

[achaulk, 2014/07/08 18:16:37]

Right

[dnicoara, 2014/07/10 17:00:56]

Seems like an implementation detail that isn't present in the interface
description. Can we have all parameters in the same coordinate space?

[achaulk, 2014/07/10 17:07:50]

I guess we could pass the surface size in here and then multiply it here instead

[dnicoara, 2014/07/10 17:25:47]

I guess the placement of the comment is unfortunate. My worry is that CC is
making a call and passing 2 gfx::Rects in different coordinate systems. So the
Ozone interface is not bringing in CC implementation details. I'm thinking that
CC should perform the conversion and pass the gfx::Rects in the same coordinate
space.

[achaulk, 2014/07/10 17:42:29]

Well, arguably this is a drm detail that cc shouldn't have to care about. cc
exports the source rect as a set of GL texture coordinates, which makes sense
for it.

I could move the conversion into gl_surface_ozone since gl images know their
size.

[dnicoara, 2014/07/10 19:17:13]

Reading more, I think you're trying to say that CC doesn't actually have the
actual size?

In this case, I don't care much where we perform the conversion as long as we
add some documentation to surface_ozone_egl.h to be very explicit about this
behavior.

[achaulk, 2014/07/10 19:44:40]

CC has the right size for the primary plane (not sure about webgl), but I don't
think it's the right place to convert. CC deals with GL-isms like texture
coordinates.

[dnicoara, 2014/07/10 19:53:52]

Alex, can you chime in, I don't have enough experience on the CC & webgl.

[alexst (slow to review), 2014/07/10 20:22:05]

Yeah, it's an artifact of GL. CC doesn't know the size of the buffer even if it
knows the size of the quad it renders.

For example, WebGL will downsize its buffers if it's running low on memory, so
your application may be 800x600 on the screen, but only have a 640x480 buffer.
CC doesn't know the buffer size and it's the thing that issues the call. GPU
process does, but even that aside, newer HW wants this in uv space to make sure
pixel perfect compatibility is achieved with GL. I don't know the gory details,
but that's the requirement I took from HWC.

We still want to be able to say, display a subrect of that (expressed as a
texcoord) whichever way you know how. The fact that drm works in fixed point is
a drm detail, but we have enough detail here to convert. Anyway, that's why it's
in [0,1] space, but as for the place to convert it inside ozone, I have no
preference.

[dnicoara, 2014/07/10 20:27:58]

OK, thank you, so we have to do it in Ozone. Please just add a comment to
surface_ozone_egl.h to better describe the input parameters.

[achaulk, 2014/07/11 16:57:49]

Done.

+                                 int overlay_plane) {
+  CHECK(fd_ >= 0);
+  return !drmModeSetPlane(fd_,
+                          overlay_plane,
+                          crtc_id,
+                          framebuffer,
+                          0,
+                          location.x(),
+                          location.y(),
+                          location.width(),
+                          location.height(),
+                          ToFixedPoint(source.x()),
+                          ToFixedPoint(source.y()),
+                          ToFixedPoint(source.width()),
+                          ToFixedPoint(source.height()));
+}
+
 ScopedDrmFramebufferPtr DriWrapper::GetFramebuffer(uint32_t framebuffer) {
   CHECK(fd_ >= 0);
   return ScopedDrmFramebufferPtr(drmModeGetFB(fd_, framebuffer));
 }
 
 ScopedDrmPropertyPtr DriWrapper::GetProperty(drmModeConnector* connector,
                                              const char* name) {
   for (int i = 0; i < connector->count_props; ++i) {
     ScopedDrmPropertyPtr property(drmModeGetProperty(fd_, connector->props[i]));
     if (!property)
@@ skipping 42 matching lines @@
   CHECK(fd_ >= 0);
   return !drmModeMoveCursor(fd_, crtc_id, x, y);
 }
 
 void DriWrapper::HandleEvent(drmEventContext& event) {
   CHECK(fd_ >= 0);
   drmHandleEvent(fd_, &event);
 }
 
 }  // namespace ui