Hi Brent, On Wednesday 02 February 2011 19:51:54 Brent Weatherall wrote: > Hello. I just want to clarify my understanding of the use of XUs in the > Linux UVC driver. > > When a device driver wishes to use an XU for a device, it must first add > the XU descriptions (so to speak) to the standard Linux UVC driver. The > Linux kernel driver module (usbhid.ko for example) is indeed the layer > this happens in, correct or no?
Not exactly. XU descriptors contain (among other information) a list of controls supported by the device for that particular extension unit. As extension units are vendor-specific, the Linux UVC driver (uvcvideo.ko) doesn't know about those controls. It must be taught how to map those XU controls to V4L2 controls. > I am working with a device that operates with the standard UVC interface > and detects the proper XU additions automatically (which I am assuming is > normal). I have found if I unplug the device to reset it and plug it back > in and then run the test application (which adds the XU controls every > time) the device will time out. If I leave the device plugged in it > usually works, but it is not guaranteed. To correct this I must restart > my USB system completely (i.e. rmmod > /lib/modules/2.6.35-22-generic/kernel/drivers/hid/usbhid/usbhid.ko, rmmod > /lib/modules/2.6.35-22-generic/kernel/drivers/hid/hid.ko, insmod > /lib/modules/2.6.35-22-generic/kernel/drivers/hid/hid.ko, insmod > /lib/modules/2.6.35-22-generic/kernel/drivers/hid/usbhid/usbhid.ko). usbhid has nothing to do with this. The UVC driver is uvcvideo.ko. > From a driver standpoint, should I check for the presence of the XU > controls and then only add them if they are not present? There's not way to check from userspace if mappings have already been added. That's not a big issue, you can just add them, and the driver will return - EEXIST if they're already present. I'm working on making the mappings device-specific, so you will need to add them every time a device is plugged in. > I would expect adding them every time should not cause the system to break > down, but I could be wrong. Theoretically speaking, is this most likely a > UVC problem, or most likely a device problem? Again, just theoretically > speaking. It must definitely not break down. Whether it's a uvcvideo or device issue is hard to tell, you haven't really told me what goes wrong. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
