Pete Zaitcev wrote: > > From: Lars Doelle <[EMAIL PROTECTED]> > > Date: Mon, 11 Feb 2002 01:08:29 +0100 > > >[...] > > There is some Linux support for IEEE 1284.4 underway, but until this is > > working and integrated, i think one should better disable accepting these > > protocols, as it would never work in the moment. > > David Paschal swears that it would break some other hardware, > check this thread: > http://marc.theaimsgroup.com/?t=99662991400004&r=1&w=2 > Also this: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50218 > > BTW, I fail to understand David's position. He wrote a patch,
My "position" is as follows: 1. Many HP USB printers (mostly multi-function peripherals, see http://hpoj.sourceforge.net/suplist.shtml, but also the LaserJet 1200 and 2200) advertise 7/1/3, 7/1/2, and 7/1/1 alternate settings, in that order. 7/1/3 is for the 1284.4 protocol, to be able to get to all the functions on the peripheral, whereas 7/1/2 and 7/1/1 are for printing only. Also, some HP USB printers, such as some DeskJets and PhotoSmart printers, support a vendor-specific command to switch 7/1/2 from a raw print interface to an MLC interface (the predecessor to 1284.4). 2. My user-mode 1284.4 driver for the HP OfficeJet Linux driver project (http://hpoj.sourceforge.net) depends on being able to get to the 7/1/3 alternate setting. Until now it has taken advantage of the printer.c "bug" where it binds to the first bidirectional interface it finds, which due to the enumeration order happens to be 7/1/3. Of course, this "bug" is problematic for users who want to be able to print directly to /dev/usb/lp0. (Note that this 1284.4 driver is working quite well already, but since it's a user-mode component I intend to keep it as part of the hpoj package rather than integrating it with the kernel.) 3. printer.c needs to be changed to bind to 7/1/2 by default, but for the sake of the hpoj project, there needs to be a way to override this default and bind to 7/1/3. Your (Pete's) printer.c version that shipped with RedHat 7.2 was a reasonable short-term solution, which provided a command-line option to change the default from 7/1/2 to 7/1/whatever. However, in the interest of maximum ease-of-use, there needs to be a more automated and transparent method of doing the switch. 4. I developed a patch which adds several ioctls to resolve the above issues as well as to provide user-mode access to more information about the peripheral, including a linkage to the corresponding /proc/bus/usb/xx/yy file. I also noticed and fixed an apparent array overflow in usblp_probe when exceeding the maximum number of connected USB printers (I may have neglected to mention this previously). > but then he failed to advocate it completely. Patches do not > get applied to Greg's tree by magic. Admittedly I was a bit soft-spoken originally, because I'm not a hard-core kernel hacker and I didn't want to accidentally step on somebody's toes by saying or doing the wrong thing. But in what way did you think I "failed to advocate it completely"? Over the course of several e-mail exchanges I think I explained my position (see above points) and eventually got my patch into what I was led to believe was an acceptable form for inclusion. On December 22 I submitted my (presumably) "final" version to Greg (the USB maintainer) and Vojtech (the printer.c maintainer) with a CC to this list and politely requested that it be incorporated. It apparently was dropped, because it didn't get incorporated and I never got any comments from either of them or anybody else. Perhaps the Christmas holidays were to blame, so I'll try again in a separate message now that I've had a chance to merge in Oliver Neukum's recent changes for 2.5 which were subsequently accepted with no problem. I'll also watch the kernel prepatches more closely and retry after a while if I don't see it get incorporated with no explanation. David _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
