Hi Johannes, I also looked into modifying the 55-hpmud.rules file so that it checked for HP devices with a 7/1/2 printer interface, but this method does not work. The sysfs tree does have some interface class information, but it is not complete. So the check for the 7/1/2 printer interface will sometimes fail.
Ubunto/Debain have this exact check (45-hplip.rules), but it does not always work. The PROGRAM "check_mfp_printer" assumes the 7/1/2 printer in always on alt interface 0 and this is not always the case. Sometimes the 7/1/2 printer interface is on alt interface 1 and this will cause the check to fail. So since the sysfs tree does not have all the necessary information at udev event time the only real solution is checking for known pids. :( -dave > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Johannes Meixner > Sent: Tuesday, September 18, 2007 7:22 AM > To: hplip-help@lists.sourceforge.net > Subject: Re: [Hplip-help] no hp-toolbox device status even if > hpssd runs as root > > > Hello, > > On Sep 14 20:58 Suffield, David wrote (shortened): > > Yes having all the HPLIP supported product-ids available is > a good idea. > > > > We are entering all HPLIP product-ids into the > data/models/models.dat > > file. Should be in the next HPLIP release. The 55-hpmud.rules file > > will be generated from the data file. The default udev > privileges will > > be > > MODE=0666 for tar ball installs, but the distros can create > there own > > rules file(s) and policy. > > > > In order to help distros set their own user policies, we > are including > > the script file for generating the 55-hpmud.rules file in > the tar ball. > > Fine! > > > Obviously such a fixed list of USB IDs makes it impossible > that it works out-of-the-box for new but compatible models. > > Therefore I thought I could improve > /etc/udev/rules.d/55-hpmud.rules by testing for the USB > device class but it seems to be really tricky (or impossible) > because different devices result very different USB device > class values: > > "lsusb -v" shows e.g. for my DeskJet 3320c: > ------------------------------------------------------------------- > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x03f0 Hewlett-Packard > idProduct 0x7004 DeskJet 3320c > ... > bInterfaceClass 7 Printer > bInterfaceSubClass 1 Printer > bInterfaceProtocol 2 Bidirectional > ------------------------------------------------------------------- > so that one needs to find out the device class at interface level. > > But how should this work for a device with several interfaces > like e.g. my LaserJet 1220: > ------------------------------------------------------------------- > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x03f0 Hewlett-Packard > idProduct 0x0417 > ... > bInterfaceClass 7 Printer > bInterfaceSubClass 1 Printer > bInterfaceProtocol 3 IEEE 1284.4 compatible bidirectional > ... > bInterfaceClass 7 Printer > bInterfaceSubClass 1 Printer > bInterfaceProtocol 2 Bidirectional > ... > bInterfaceClass 7 Printer > bInterfaceSubClass 1 Printer > bInterfaceProtocol 1 Unidirectional > ------------------------------------------------------------------- > here all interfaces belong to the same class "printer" (but > the LaserJet 1220 is in fact a printer+scanner all-in-one-device). > > In contrast an OfficeJet 7210 printer+scanner+cardreader+fax > all-in-one-device shows up as > ------------------------------------------------------------------- > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x03f0 Hewlett-Packard > idProduct 0x4111 > ... > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 204 > bInterfaceProtocol 0 > ... > bInterfaceClass 7 Printer > bInterfaceSubClass 1 Printer > bInterfaceProtocol 2 Bidirectional > ... > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > ... > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 212 > bInterfaceProtocol 0 > ... > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 6 SCSI > bInterfaceProtocol 80 Bulk (Zip) > ------------------------------------------------------------------- > > I cannot imagine how generic udev rules could be found so > that HPLIP supported devices match but no other devices. > > Therefore it seems all one can do is to use a fixed list of > the currently known USB device IDs. > > But this will force unexperienced users to update HPLIP (and > request the newest HPLIP from the distributors) for each new model :-( > > > Kind Regards > Johannes Meixner > -- > SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > Germany AG Nuernberg, HRB 16746, GF: Markus Rex > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft Defy all > challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > HPLIP-Help mailing list > HPLIP-Help@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hplip-help > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ HPLIP-Help mailing list HPLIP-Help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-help
