[RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I have always been unhappy with the fact that it is so hard to tell whether
the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
only tells you if Streaming I/O is available, but not in which flavors.

So I propose the following:

#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
#define V4L2_CAP_STREAMING_USERPTR 0x08000000
#define V4L2_CAP_STREAMING_DMABUF  0x10000000

All drivers that currently support CAP_STREAMING also support MMAP. For userptr
and dmabuf support we add new caps. These can be set by the core if the driver
uses vb2 since the core can query the io_modes field of vb2_queue.

For the drivers that do not yet support vb2 we can add it manually.

I was considering making it a requirement that the MMAP streaming mode is
always present, but I don't know if that works once we get drivers that operate
on secure memory. So I won't do that for now.

Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO?
It's never been implemented, nor is it likely in the future. And we don't have
all that many bits left before we need to use one of the reserved fields for
additional capabilities.

Regards,

	Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux