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. > > Now since neither usb.org appears not to provide a scanner class, nor many > vendors wouldn't care to use it also, I wouldn't go so far as to call it a "hack". For multi-function devices, there is a definite advantage in being able to address all functions based on a single kernel device (with user-mode help), instead of trying to figure out that /dev/usb/lpX and /dev/usb/scannerY happen to be different functions on the same device, where X doesn't necessarily equal Y. As you mentioned, there is currently no standard USB scanner class, nor is there a standard fax-send, fax-receive, etc. class. The fact of the matter is that for a large set of HP printers and MFPs, this is how it's done, so we have to accomodate it if we don't want to have to boot into Windows in order to use them.
> 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. I'll add my voice to Pete and Oliver in saying that it is very impractical and completely unnecessary to go to the trouble of maintaining a large list of vendor/product ID pairs to say which ones should use 7/1/2 and which ones should use 7/1/3. Furthermore, new models with different IDs come out over time, which would require people to upgrade their kernel (a very daunting task for many) just to get the new IDs before they can use a standard USB printer-class device. The best solution, which my patch implements, is to start out by default with 7/1/2 (or 7/1/1 if no 7/1/2) to at least allow basic printing support (the path of least surprise), and provide the ioctls for the hpoj MLC/1284.4 driver to automatically switch to 7/1/3 if it wants with no further user intervention. My patch also adds support for a certain back-door way that some HP non-7/1/3 printers switch their 7/1/2 alternate settings from raw-printing to MLC/1284.4, which is needed in order to support the photo-card readers on many HP PhotoSmart printers; this too might seem like an odd way of doing things, but once again, that's just how these products work. > (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.) It already has least preference for 7/1/1. But since you mentioned this, I took another look at my patch and decided to make another small change, and change the preference order to 7/1/2 (highest), 7/1/1, and then 7/1/3. Previously, it was 7/1/2, 7/1/3, and 7/1/1, based on Pete's earlier work in this area, but it seems to me that in the interest of making printing work out-of-the-box, we should by default prefer 7/1/1 over 7/1/3 if there's no 7/1/2, although I've never actually seen a device with only 7/1/1 and 7/1/3 but no 7/1/2. Oliver Neukum wrote: > 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 ? While I can't comment on non-HP printers or future HP products, I can say that it's not safe to assume that none of them will also do the same thing. Therefore, it's best to go with my more open-ended solution for printer.c, and leave it to me to handle the rest in user mode for HP MFPs. (Did I understand and answer your question correctly?) David _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
