Hi Damian, On 06/08/2015 06:42 AM, Damian Hobson-Garcia wrote: > Hello again, > > On 2015-06-02 10:40 AM, Damian Hobson-Garcia wrote: >> Hello All, >> >> I would like to ask for some comments about a plan to use user space >> video codecs through the V4L interface. I am thinking of a situation >> similar to the one described on the linuxtv.org wiki at >> http://www.linuxtv.org/wiki/index.php/V4L2_Userspace_Library >> >> The basic premise is to use a FUSE-like driver to connect the standard >> V4L2 api to a user space daemon that will work as an mem-to-mem driver >> for decoding/encoding, compression/decompression and the like. This >> allows for codecs that are either partially or wholly implemented in >> user space to be exposed through the standard kernel interface. >> >> Before I dive in to implementing this I was hoping to get some comments >> regarding the following: >> >> 1. I haven't been able to find any implementation of the design >> described in the wiki page. Would anyone know if I have missed it? >> Does this exist somewhere, even in part? It seems like that might be a >> good place to start if possible. >> >> 2. I think that this could be implemented as either an extension to FUSE >> (like CUSE) or as a V4L2 device driver (that forwards requests through >> the FUSE API). I think that the V4L2 device driver would be >> sufficient, but would the fact that there is no specific hardware tied >> to it be an issue? Should it instead be presented as a more generic >> device? >> >> 3. And of course anything else that comes to mind. > > I've been advised that implementing kernel APIs is userspace is probably > not the most linux-friendly way to go about things and would most likely > not be accepted into the kernel. I can see the logic of > that statement, but I was wondering if I could confirm that here. Is > this type of design a bad idea? Writing userspace drivers for hardware components is certainly not something we want to see. The kernel is the gateway between userspace and hardware, so the kernel is the one that controls the hardware. There are some exceptions (printers and scanners come to mind), but by and large this rule holds. But you want to do something different if I understand correctly: you want to make a V4L2 API to interface to userspace codecs. That does not affect the kernel at all, and I see no reason why this can't be done. Basically libv4l2 allows the concept of plugins where all open/close/ioctl/etc. operations go through the plugin. Today plugins interface with a kernel V4L2 driver, but it is also possible to make a plugin that is completely in userspace. Nobody ever did it, but we discussed it in the past. The only problem is that since there is no actual /dev/videoX device, what do you specify here? Perhaps a predefined /dev/video-<codecname>X 'device name'? There is currently only one plugin that is part of v4l-utils: v4l-utils/lib/libv4l-mplane That might be a good starting point. Hope this helps, Regards, Hans > Also, if this method is not recommended, should there be a 1-2 line > disclaimer on the "V4L2_Userspace_Library" wiki page that mentions this? > > Thank you, > Damian > -- > 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 > -- 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
