Hello,
the project of the V4L2 library that you have proposed recently looks interesting, as I think it could solve some of the gaps in the V4L2 infrastructure in a reasonable and transparent way.
I have looked at the specifications of the library and your comments about it. I have some concerns about the explicit mention of a lock for the device handled by the base driver when it is accessed from the extended driver. In this case, the base driver is already supposed to implement the correct locking schema for the devices it handles, no matter where they are accessed from. The extended driver should forward the system calls and give the result back without adding extra locks on those devices. This is how the original V4L2 core module works too; for instance, it's perfectly allowed to open a device twice. However, this does not mean that the extended driver cannot implement locks on the _virtual_ extended devices it handles, but these locks should not interfere with the base driver.
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
Unfortunately, I do not have much time to actively code, but I will be keeping an eye on the development and send my comments when needed.
Best regards Luca
Luca Risolia napsal(a):
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
The problem with this is that most applications try to open/stat only /dev/videoX, nothing else and this will break the transparency.
thanks,
On Thursday 05 July 2007 09:06:15 Jiri Slaby wrote:
Luca Risolia napsal(a):
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
The problem with this is that most applications try to open/stat only /dev/videoX, nothing else and this will break the transparency.
Hmm.. what do you think about "/dev/videoX", "/dev/video(X+32)", with X ranging from 1 to 32 reserved for real devices only. The problem is to identify a virtual, extended device corresponding to a real device _before_ opening it. Actually, unless the user always knows how to properly configure the system, associations of real and virtual devices with minor numbers would be casual in a dynamic context with multiple drivers and devices.
Cheers Luca
Luca Risolia napsal(a):
On Thursday 05 July 2007 09:06:15 Jiri Slaby wrote:
Luca Risolia napsal(a):
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
The problem with this is that most applications try to open/stat only /dev/videoX, nothing else and this will break the transparency.
Hmm.. what do you think about "/dev/videoX", "/dev/video(X+32)", with X ranging from 1 to 32 reserved for real devices only.
Sounds good to me. (But will reduce number of possible real video devices by half.)
The problem is to identify a virtual, extended device corresponding to a real device _before_ opening it. Actually, unless the user always knows how to properly configure the system, associations of real and virtual devices with minor numbers would be casual in a dynamic context with multiple drivers and devices.
I also thought about different device naming, i.e. adding " (extended)" to the device name (video_device.name) when it's opened through v4l2-lib.
Maybe we might also involve udev somehow (providing .rules with the daemon, which must be packaged and distributed too).
regards,
Jiri Slaby a écrit :
Luca Risolia napsal(a):
On Thursday 05 July 2007 09:06:15 Jiri Slaby wrote:
Luca Risolia napsal(a):
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
The problem with this is that most applications try to open/stat only /dev/videoX, nothing else and this will break the transparency.
Hmm.. what do you think about "/dev/videoX", "/dev/video(X+32)", with X ranging from 1 to 32 reserved for real devices only.
Sounds good to me. (But will reduce number of possible real video devices by half.)
Well, I don't know if it is possible to do that without interferring with the v4l framework.
The problem is to identify a virtual, extended device corresponding to a real device _before_ opening it. Actually, unless the user always knows how to properly configure the system, associations of real and virtual devices with minor numbers would be casual in a dynamic context with multiple drivers and devices.
I also thought about different device naming, i.e. adding " (extended)" to the device name (video_device.name) when it's opened through v4l2-lib.
Maybe we might also involve udev somehow (providing .rules with the daemon, which must be packaged and distributed too).
Yes, by creating a specific rule for the v4l2_extension module, we can create symlinks that would be more explicit if needed. In fact I to differentiate a base v4l driver from the extended v4l driver by extending the VIDIOC_QUERYCAP ioctl. Most applications get the device name by calling this ioctl to get the struct v4l2_capability, that contains the char *card field (assumption). This field contains "Syntek USB Video Camera" for example. The extended driver would prefix with "Extended" to this name: "Extended Syntek USB Video Camera" The application would show 2 different devices to the user.
regards,
Cheers, Thierry
Hmm.. what do you think about "/dev/videoX", "/dev/video(X+32)", with X ranging from 1 to 32 reserved for real devices only.
Sounds good to me. (But will reduce number of possible real video devices by half.)
Well, I don't know if it is possible to do that without interferring with the v4l framework.
You may try to use a dynamic device number range. This will work fine with udev, avoiding to limit the device range on V4L.
Em Qui, 2007-07-05 às 09:06 +0200, Jiri Slaby escreveu:
Luca Risolia napsal(a):
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
The problem with this is that most applications try to open/stat only /dev/videoX, nothing else and this will break the transparency.
The device name is related to udev, not to Kernel. This can be addressed inside the distros. We can generate some suggested way for handling V4L devices with udev.
thanks,
Hello Luca,
Luca Risolia a écrit :
Hello,
the project of the V4L2 library that you have proposed recently looks interesting, as I think it could solve some of the gaps in the V4L2 infrastructure in a reasonable and transparent way.
I have looked at the specifications of the library and your comments about it. I have some concerns about the explicit mention of a lock for the device handled by the base driver when it is accessed from the extended driver. In this case, the base driver is already supposed to implement the correct locking schema for the devices it handles, no matter where they are accessed from. The extended driver should forward the system calls and give the result back without adding extra locks on those devices. This is how the original V4L2 core module works too; for instance, it's perfectly allowed to open a device twice. However, this does not mean that the extended driver cannot implement locks on the _virtual_ extended devices it handles, but these locks should not interfere with the base driver.
In fact this is what I wanted to specify. The extended driver locks the base v4l driver by forwarding the "open" system call. This appears on the SD just under the "Open/close access the hardware".
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
Unfortunately, I do not have much time to actively code, but I will be keeping an eye on the development and send my comments when needed.
Thanks, do not hesitate to give advices. I am correcting and continuing the extension code to have something usable. I think as soon as the code will be started, this will be easier to implement the other bricks. But I have so little time that the first release is long to come :)
Best regards Luca
Cheers, Thierry
-
Jiri Slaby -
Luca Risolia -
Mauro Carvalho Chehab -
Thierry Merle