Hi Romain,

Romain Beauxis a écrit :

Hi all !

I wonder wether the extended device should be the default shown to user, and the pair basic+extended only available when asked ?

For now, there is 2 video devices. They distinguish only by the v4l device name, an information that is often displayed by the applications (see v4linfo for example). The extended device has for name: "Ext. <name of base driver>" My main problem is how to virtually open the base driver from the v42ext driver.

No matter how this can be done, via udev or the kernel itself, I think in most of cases, e.g. basic webcam streaming, the end user will need only uncompressed data, so two different devices for the same hardware would make it more confusing .. ?

Well, it may be confusing for some time but the aim is to get rid of this helper daemon solution. In a long term, applications will link to the v4l2 library directly. In a short term, the helper daemon shall use it and uncompress frames to provide them for the application. Another solution, proposed by Jiri Slaby is to modify each base driver to extend its functionalities. On second thought, his solution may be less complex and there may be a simple solution in order to make a generic extension (by modifying video_ioctl2 for example).

Also, I guess we have to start a daemon project around this.. Should we do it here or anywhere else ?

Yes, this is the right place to do that. There are 2 main tasks around this daemon: - define the v4l2ext driver/helper daemon interface. This interface should be as simple as possible and used to fit only the present needs. - define the helper daemon interface/v4l2 library interface. As I said, the applications will link to this v4l2 library directly to access the v4l drivers in future. Look at the daemon as a subset of an application that would receive compressed frames and uses the v4l2 library to uncompress these frames. I should write the realization part of the specification to clarify all this.

Romain

Thierry