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.
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. 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. (printer.c should be fixed to prefere 7/1/2 over 7/1/1 if both exist, independent of the order in the descriptor, btw.) Just my unqualified thoughts Lars _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
