VaapiVideoAccelerator: make Vaapi accelerator work with ozone

ui/ozone/platform/dri/gbm_buffer.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/gbm_buffer.h"
 
 #include <gbm.h>
 
 #include "base/logging.h"
 
@@ skipping 53 matching lines @@
 }
 
 GbmPixmap::~GbmPixmap() {
 }
 
 void* GbmPixmap::GetEGLClientBuffer() {
   return buffer_->bo();
 }
 
 int GbmPixmap::GetDmaBufFd() {
-  NOTIMPLEMENTED();
-  return -1;
+  return gbm_bo_get_fd(buffer_->bo());

[Pawel Osciak, 2014/10/08 08:17:23]

I think we should be closing the fd somewhere once we are done with it?

[llandwerlin-old, 2014/10/08 09:31:18]

When we give the fd to LibVA, it is wrapped using
drm_intel_bo_gem_create_from_prime :
http://cgit.freedesktop.org/mesa/drm/tree/intel/intel_bufmgr.h?id=86b37c61c78...

Libdrm then does refcounting on the drm_intel_bo objects, and ensure the fd is
closed when unused.

As mentionned https://codereview.chromium.org/490233002/#msg41 , we need some
patches in libdrm (or upgrade to 2.4.57 to have drm BOs properly managed between
GL and LibVA.

[Pawel Osciak, 2014/10/26 13:06:46]

This ends up in DRM_IOCTL_PRIME_FD_TO_HANDLE and that calls get_dma_buf() which
increases the refcount on associated file. Also, the documentation for
gbm_bo_get_fd() says we need to be closing it. And the users such as Wayland are
doing this (e.g.
http://people.freedesktop.org/~chadversary/mesa/doxygen/kevin-rogovin/dd/d68/...).

[llandwerlin-old, 2014/10/29 13:52:47]

Right, thanks, we effectively leaking the fd here. I will add a comment in the
drm picture provider to explain how all this works.

[kalyank, 2014/11/01 18:33:47]

Now, this should be handled with the latest rebase I guess. GBMPixmap will close
the fd during destruction.

+}
+
+uint32_t GbmPixmap::GetStride() {
+  return gbm_bo_get_stride(buffer_->bo());
 }
 
 }  // namespace ui