On Wed, 12 Dec 2007, Phil Endecott wrote: > Dear Experts, > > A while ago I asked some questions about how/if a user-space > usbdevice_fs driver can influence the configuration that the kernel > chooses when a device is attached. You kindly explained that a > user-space driver must allow the kernel to choose a configuration and > then change it using ioctl(USBDEVFS_SETCONFIGURATION). I have some > code that seems to work in most cases using this approach. > > Unfortunately, I've now found a case where this doesn't work; I have a > camera (07b4:0102 Olympus Optical Co., Ltd Camedia E-10/C-220/C-50 > Camera) which doesn't like getting a second set_configuration() call > without first getting a reset. A second set_configuration() is > STALLed. I think this sort of "quirk" is common in imperfect > real-world devices, no?
Unfortunately yes. > I think that my solution for the time being will be to first test > whether the configuration that I want to use is the same as the one > that the kernel has chosen (which I think I can find via sysfs; it's > not possible via usbdevice_fs is it?), Sort of. You can send a Get-Configuration request directly to the device and see what it says. There is no ioctl to retrieve the value directly. Using sysfs might be easier. > and only call > ioctl(USBDEVFS_SETCONFIGURATION) if it differs. I'll then only have a > problem with a device that has this "quirk" and has multiple > configurations and where I want to use a different one than the > kernel's default, which I hope is rare. I worry a little, though, that > doing set_configuration with the same configuration number can be used > legitimately as a kind of "soft reset" (???) and I'm making that impossible. Sometimes it is used that way. You are better off if you keep the two usages distinct. Then one pathway wouldn't do anything if the old and new configs were the same, and the other pathway would always use the current config number. One thing to watch out for is that the USBDEVFS_SETCONFIGURATION call will fail if any interface is bound to a driver. Writing to the sysfs bConfigurationValue file doesn't have this requirement. > Anyway, I'm sending this message as a "heads up" that this issue > exists; I understand that there is a new replacement for usbdevice_fs > in the works, and if it could do anything to sidestep the problem, that > would be useful. The real problem here is the camera's failure to respond to a second Set-Config command. I don't see how anything we do can fix that. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
