On Tuesday 12 February 2002 15:48, Lars Doelle wrote:
> Hmm, i have another suggestion:
>
> I had a look at the descriptors, and found three interfaces, but each in a
> different alternate setting and same endpoints. This is really a hack. HP
> should have provided two interfaces with a printer and a scanner class with
> different endpoints in one alternate setting and that's it, instead
> starting to tunnel. usb.org should never have accepted 1282.4 if they'd
> take their own product serious.
You are right. Unfortunately they _have_ accepted it.
Can we now be confident that no other printers will implement it
and put a workaround into printer.c ?
> Now since neither usb.org appears not to provide a scanner class, nor many
> vendors wouldn't care to use it also, we'll certainly all die in the end
> with vendor/product pairs instead of anything decent.
Yes, scanners are screwed. But we have to deal with the situation.
> So my suggestion is to go this way and put a vendor/product list into
> printer.c indicating when a 7/1/3 should really be picked and call the
> device then /dev/usb/hpoj, so that you can pick it up with your user space
> driver, thus avoiding breaking /dev/lp semantics and adding new ioctls.
Then we'd better implement a blacklist and not take these devices and have
a seperate 1282.4 driver or leave it to user space (the existing solution)
The problem is that we effectively lock people to the hpoj package this way.
The devices seem to be usable as printers only conventionally and you can't
easily tell what the user wants.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
