On Thu, Oct 06, 2005 at 12:43:06PM +0200, Julien BLACHE wrote:
> The problem is that your device exposes only one USB device when it
> should really expose at least 2 devices or functions. This is an
> engineering problem on the manufacturer's side, and unfortunately
> they're all doing the same shit.
While you are right that two separate USB device descriptors are
better, I think it's not against the USB spec to have two different
device types in the same USB device implemented as different USB interfaces.
> Epson unfortunately doesn't provide anything comparable to what HP does
> for its multifunction devices, that is, a userspace daemon/driver
> managing the access to the device. This isn't a clean solution either,
> but it's cheaper (than having the hardware properly expose 2 devices
> or functions) and it works.
>
> So to make it clear: there is no solution to your problem. usblp will
> bind the device at the kernel level, prohibiting user processes from
> accessing the device through libusb.
As far as I know, usblp binds only to the interface of the printer part.
Example:
device-->configuration 1-->interface1 (scanner)
| |->interface2 (printer)
|
|->configuration 2-->interface1 ...
|->...
The problem is that usblp claims interface2 (which is perfectly
legal). SANE tries to set configuration1 (which is also legal, but
most of the time not necessary, because it's already selected). libusb
(or the kernel?) blocks this call because you can't change the
configuration while an interface is claimed (also makes sense).
libusb/the kernel could be more intelligent and be aware that
configuration 1 is already seleted and that no change is necessary and
therefore no error must be returned. As this is not implemented, the
below mentioned patch tries to set the configuration because this
seems to be needed by some OS (MacOS X?) but ignores any errors of
this operation. This has been reported to work with usblp.
Real errors (e.g. scanner interface is claimed by another process) are
detected by the next step, usb_claim_interface().
> > I think that maybe a fix can be integrated in the debian version of sane
> > until a new version with the fix is released, since it is a bug that
> > seems to touch all the people with multifunction devices.
>
> I'm not willing to apply this patch in its current form. It might be
> harmful for other devices.
I don't think so. The only case I can imagine at the moment is that
for some device the configuration must be changed to 2 for the
scanning to work but for printing only configuration 1 works. In this
case the SANE backend has to call sanei_usb_set_configuration anyway
(which isn't changed by the patch). Also, sanei_usb_set_configuration
is not used by any backend.
The patch is from SANE CVS, btw.
Bye,
Henning
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
