FakeVideoCaptureDevice: add support for capturing into Dma-Bufs using VGEM in CrOs

FakeVideoCaptureDevice: add support for capturing into Dma-Bufs using VGEM in CrOs

This CL adds support in FakeVideoCaptureDevice 
such that if the Buffer returned from 
Client::ReserveOutputBuffer() is nullptr, then  
try to obtain it AsPlatformFile(). The returned
PlatformFile is an |fd| and is mmap()ed via vgem
dumb API. 

vgem+dumb is a kernel API present in CrOS and for 
certain DRM drivers, notably xf86 i915.

This CL also adds an AsPlatformFile() method to
VideoCaptureBufferPool::Handle and to
VideoCaptureDevice::Client::Buffer. 

The idea is to give the VideoCaptureDevice the 
possibility to extract Buffer's underlying
file descriptors if the data() coming out of
a ReserveOutputBuffer() is nullptr.

BUG=440843

[mcasas, 2015-04-22 23:28:11]

mcasas@chromium.org changed reviewers:
+ emircan@chromium.org

[mcasas, 2015-04-22 23:28:12]

emircan@ please have a first critical reading. Does
this coincide with your understandings?

[mcasas, 2015-04-23 02:18:08]

Patchset #1 (id:1) has been deleted

[emircan, 2015-04-27 16:35:42]

It is a good idea to add PlatformFile. Also, the use of dumb buffers looks right
except the missing DRM_IOCTL_PRIME_HANDLE_TO_FD conversion.

https://codereview.chromium.org/1106563002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_buffer_pool.cc (right):

https://codereview.chromium.org/1106563002/diff/40001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_buffer_pool.cc:57:
NOTIMPLEMENTED();
On WIN, you can return shared_memory_.handle(), which is a HANDLE. Since
base::PlatformFile is a HANDLE on Win as well, it would work, and function would
be more complete.

https://codereview.chromium.org/1106563002/diff/40001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_buffer_pool.cc:90:
DCHECK_EQ(gmb_->GetHandle().type, gfx::OZONE_NATIVE_BUFFER);
This can be implemented for GpuMemoryBufferImplSharedMemory as well, sinc eit
exposes the underlying handle.
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
File media/video/capture/fake_video_capture_device.cc (right):

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
media/video/capture/fake_video_capture_device.cc:35: class MmapedFile {
Mmapped or mmaped? They both sound wrong tbh.

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
media/video/capture/fake_video_capture_device.cc:70:
drm_fd_.reset(HANDLE_EINTR(open(device_path, O_RDWR)));
I think we need the handle to dma_buf_fd conversion here.
See page 13 on
http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
media/video/capture/fake_video_capture_device.cc:90: struct drm_mode_create_dumb
creq = {};
memset(&creq, 0, sizeof(creq));

[mcasas, 2015-04-30 02:54:45]

Patchset #3 (id:60001) has been deleted

[mcasas, 2015-04-30 17:33:18]

Patchset #3 (id:80001) has been deleted

[mcasas, 2015-05-01 01:38:42]

Patchset #3 (id:100001) has been deleted

[mcasas, 2015-05-01 02:43:58]

Patchset #3 (id:120001) has been deleted

[mcasas, 2015-05-01 02:44:06]

Patchset #3 (id:140001) has been deleted

[mcasas, 2015-05-01 02:52:22]

Patchset #3 (id:160001) has been deleted

[mcasas, 2015-05-01 18:34:34]

Patchset #4 (id:190001) has been deleted

[mcasas, 2015-05-01 18:57:12]

Patchset #4 (id:210001) has been deleted

[mcasas, 2015-05-01 20:23:48]

Patchset #4 (id:230001) has been deleted

[mcasas, 2015-05-06 23:31:11]

Patchset #1 (id:20001) has been deleted

[mcasas, 2015-05-06 23:31:25]

Patchset #2 (id:170001) has been deleted

[mcasas, 2015-05-06 23:31:34]

Patchset #2 (id:250001) has been deleted

[mcasas, 2015-05-07 02:08:07]

Patchset #2 (id:270001) has been deleted

[mcasas, 2015-05-07 15:54:43]

Patchset #2 (id:270001) has been deleted

[mcasas, 2015-05-07 15:59:45]

mcasas@chromium.org changed reviewers:
+ marcheu@chromium.org

[mcasas, 2015-05-07 15:59:46]

emircan@ please have another look.

marcheu@ PTAL fake_video_capture_device.cc vgem parts

https://codereview.chromium.org/1106563002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_buffer_pool.cc (right):

https://codereview.chromium.org/1106563002/diff/40001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_buffer_pool.cc:57:
NOTIMPLEMENTED();
On 2015/04/27 16:35:42, emircan wrote:
> On WIN, you can return shared_memory_.handle(), which is a HANDLE. Since
> base::PlatformFile is a HANDLE on Win as well, it would work, and function
would
> be more complete.

Done.

https://codereview.chromium.org/1106563002/diff/40001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_buffer_pool.cc:90:
DCHECK_EQ(gmb_->GetHandle().type, gfx::OZONE_NATIVE_BUFFER);
On 2015/04/27 16:35:42, emircan wrote:
> This can be implemented for GpuMemoryBufferImplSharedMemory as well, sinc eit
> exposes the underlying handle.
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...

Done.

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
File media/video/capture/fake_video_capture_device.cc (right):

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
media/video/capture/fake_video_capture_device.cc:70:
drm_fd_.reset(HANDLE_EINTR(open(device_path, O_RDWR)));
On 2015/04/27 16:35:42, emircan wrote:
> I think we need the handle to dma_buf_fd conversion here.
> See page 13 on
>
http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf 

Yeah we needed to jump through many hoops...
See all the vgem+dumb mapping added @ PS2.

https://codereview.chromium.org/1106563002/diff/40001/media/video/capture/fak...
media/video/capture/fake_video_capture_device.cc:90: struct drm_mode_create_dumb
creq = {};
On 2015/04/27 16:35:42, emircan wrote:
> memset(&creq, 0, sizeof(creq));

No need for that when using the = {} syntax
above (initializer).

[dshwang, 2015-05-12 12:58:43]

dongseong.hwang@intel.com changed reviewers:
+ dongseong.hwang@intel.com

[dshwang, 2015-05-12 12:58:44]

https://codereview.chromium.org/1106563002/diff/290001/media/video/capture/fa...
File media/video/capture/fake_video_capture_device.cc (right):

https://codereview.chromium.org/1106563002/diff/290001/media/video/capture/fa...
media/video/capture/fake_video_capture_device.cc:67:
base::FileEnumerator::FILES,
false, base::FileEnumerator::DIRECTORIES,

I use this logic in https://codereview.chromium.org/1124063003/ as mcasas
advised.
How about getting vgem fd from drm_display_host_manager.cc, instead of opening
fd in ad-hoc way?

[mcasas, 2015-05-12 19:11:32]

On 2015/05/12 12:58:44, dshwang wrote:
>
https://codereview.chromium.org/1106563002/diff/290001/media/video/capture/fa...
> File media/video/capture/fake_video_capture_device.cc (right):
> 
>
https://codereview.chromium.org/1106563002/diff/290001/media/video/capture/fa...
> media/video/capture/fake_video_capture_device.cc:67:
> base::FileEnumerator::FILES,
> false, base::FileEnumerator::DIRECTORIES,
> 
> I use this logic in https://codereview.chromium.org/1124063003/ as mcasas
> advised.
> How about getting vgem fd from drm_display_host_manager.cc, instead of opening
> fd in ad-hoc way?

Media can't open a communication channel to Gpu process, it might need to be
done in VideoCaptureBufferPool, when creating the Buffer Handle [1]. It 
would be great if VCBP could abstract the implementation, and FakeVCD
be completely agnostic. I'll wait until your CL is done and then 
probably refactor this CL.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/re...

[mcasas, 2015-11-04 21:31:34]

On 2015/05/12 19:11:32, mcasas wrote:
> On 2015/05/12 12:58:44, dshwang wrote:
> >
>
https://codereview.chromium.org/1106563002/diff/290001/media/video/capture/fa...
> > File media/video/capture/fake_video_capture_device.cc (right):
> > 
> >
>
https://codereview.chromium.org/1106563002/diff/290001/media/video/capture/fa...
> > media/video/capture/fake_video_capture_device.cc:67:
> > base::FileEnumerator::FILES,
> > false, base::FileEnumerator::DIRECTORIES,
> > 
> > I use this logic in https://codereview.chromium.org/1124063003/ as mcasas
> > advised.
> > How about getting vgem fd from drm_display_host_manager.cc, instead of
opening
> > fd in ad-hoc way?
> 
> Media can't open a communication channel to Gpu process, it might need to be
> done in VideoCaptureBufferPool, when creating the Buffer Handle [1]. It 
> would be great if VCBP could abstract the implementation, and FakeVCD
> be completely agnostic. I'll wait until your CL is done and then 
> probably refactor this CL.
> 
> [1]
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/re...

Hey guys, I'm closing this issue since is not applicable 
anymore: users of GMBs should not extract their underlying
storages, and instead just use Map()-Unmap(). Thanks
for your time.