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?
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?), 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.
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.
Regards,
Phil.
-
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
