https://bugzilla.novell.com/show_bug.cgi?id=469721 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469721#c9 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsmeix@novell.com, | |lnussel@novell.com --- Comment #9 from Johannes Meixner <jsmeix@novell.com> 2009-01-29 01:38:22 MST --- Again and again (read my comments above!): I do not know if a USB ID is - a plain printer - a plain scanner - a printer + scanner all-in-one device - a printer + scanner + fax all-in-one device - a printer + scanner + cardreader all-in-one device - a printer + scanner + fax + cardreader all-in-one device I get the data from the upstream projects as is. I can only use it as is. I cannot do anything else here. According to comment #8 it seems you can distinguish it? Because you wrote "we can know that they are pure scanner or printer" and as I already wrote that I do not know this, it must be you who knows it? None of the all-in-one devices which I have ever seen has multiple USB devices (i.e. multiple /dev/bus/usb/*/* device nodes). Epson all-in-one devices usually provide their different units as different USB interfaces so that on USB interface level one can theoretically distinguish the printer unit from the scanner unit from whatever else unit. But I do not have any information on the USB interface level about this devices (except the one Epson all-in-one device which I have for my tests where I can run "lsusb -v"). HP all-in-one devices do not provide their different units via different USB interfaces. For HP all-in-one devices the access happens via the MLC/1284.4 transport protocol which was developed as an enhancement for the parallel port to access multiple units of a all-in-one device via parallel port which requires the ECP mode for the parallel port, see http://hplipopensource.com/node/128 HP all-in-one device access via USB is done as some kind of "emulated parallel port access via USB". HP all-in-one devices also provide different USB interfaces but those differ regarding the parallel port mode, for example my HP LaserJet 1220 printer + scanner has: --------------------------------------------------------------------- idVendor 0x03f0 Hewlett-Packard idProduct 0x0417 LaserJet 1200 series .. 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 --------------------------------------------------------------------- I.e. there are only "Printer" interfaces even when this particular device has actually also a scanner unit. The device access happens always via a "Printer" interface to the "full device" and the MLC/1284.4 transport protocol distinguishes then if the printer unit or the scanner unit (or whatever else unit) is actually meant. Therefore it is not possible at all to distinguish the different units in a HP all-in-one device via whatever USB information. Regarding access policy: (I added Ludwig Nussel to Cc for expert knowledge if needed) When we used resmgr in the past there was actually only one kind of access: The "desktop" access which grants read/write access to the whole device for locally logged in users. Regardless that resmgr knows about different group names or device types (or whatever this stuff was called) in the end all was mapped to the "desktop" access policy. It is exactly what a normal user expects regarding default out-of-the-box device access permissions: When he has a device on his desktop (USB devices are usually located next to the computer) he expects to have access permissions for the whole device by default. A user would not understand if he would be only allowed to print but not allowed to get the printer device status (see above - even plain HP printers need by default read/write access for the whole device according to our default access policy - i.e. for "desktop" users). And this is exactly what I can provide with my knowledge and what the upstream projects provide with their data: The USB IDs for the whole devices and nothing more. Therefore I can generate lists in any syntax you like (I only would really like if the syntax was stable) which provide the USB IDs for the whole devices. Then whatever subsystem you like (I don't care if it is resmgr or HAL or whatever successor of HAL) can provide our default out-of-the-box device access permissions. Note the difference: It is perfectly fine when resmgr or HAL or whatever else provides functionality to do a manual fine-tuning of the device access permissions via manual editing of whatever config files. But in contrast it would be a horrible overcomplicated oversophisticated nightmare when I should provide fine-tuned default out-of-the-box device access rules. Actually this would be totally impossible for me (see my comments above!). Regarding HAL: I would really like to understand why HAL related issues become too often horrible complicated nightmares, e.g.: bug #462639: After long and laborious work it was in the end a bug in hal which is solved by a simple hal update. bug #438867: Also long and laborious work and I was unable to find the reason in HAL because it is so complicated. See the "More precisely" part at https://bugzilla.novell.com/show_bug.cgi?id=438867#c54 what I would like to have. Unfortunately HAL does not provide this. HAL provides something else which is from my point of view (as a user of the HAL system) oversophisticated and overcomplicated (I mean HAL's user interface not whatever internals of HAL - I am not interested in HAL's internals) - regardless if the root cause is actually HAL or the kernel - from my point of view this "thingy" is a nightmare. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.