Dear all, Laurent Pinchart and I are currently working on adding support for so-called UVC extensions to his USB Video Class driver (http://linux-uvc.berlios.de/).
For those not familiar with the UVC specification, here's a quick description of what the situation looks like: (The complete spec can be found at http://www.usb.org/developers/devclass_docs/) - Devices contain a number of different units, among them the processing unit and extension units, the latter ones identified by GUIDs. - Each extension unit contains a number of so-called controls, identified by numbers called control selectors. - Each control gives read-only or read/write access to some device feature. Extension units allow vendors to add functions to their devices that are not contained in the spec, e.g. motor control, querying the firmware version, or updating the firmware. While the Linux UVC driver is a V4L2 driver and most controls (brightness, contrast, etc.) are mapped to V4L2 controls, this does not always make sense (see some of the above examples). Therefore we were discussing ways to expose these extension units in a generic manner. Apart from the obvious way of introducing driver-specific ioctls we thought about making them accessible via sysfs. Some of the advantages include: - Simple scripting and control debugging (no need for C to access the V4L2 API) - Easy access for external panel applications - Easy enumeration of extension units and controls As an example, the tree structure could look something like this (slightly simplified): /sys/class/video4linux/video0/ | |--extension_units/ | |--{00000000-0000-0000-000000000001}/ |--{12345678-1234-1234-abcdefabcdef}/ | |--ctrl_1/ |--ctrl_2/ | |--ctrl_selector |--min |--max |--cur Applications could read from and write to extension units simply by using the provided files. The mapping from the driver internal objects that represent units, controls, etc. is pretty straightforward with the use of kobjects. Now the question: Does this sound like a good idea? Is sysfs the right way to do such a thing or are there better alternatives? It seems along the lines of the USB subsystem which exposes many of the properties of USB devices in a similar manner. Also, the PVRUSB2 driver has a similar interface for its controls (http://www.isely.net/pvrusb2/usage.html#sysfs). Our main concern is the number of kobjects that would be used in this approach (a few dozen per camera). Any feedback is welcome! :-) Cheers, Martin Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
