https://bugzilla.novell.com/show_bug.cgi?id=469721 User cstender@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469721#c2 --- Comment #2 from Christopher Stender 2009-01-27 09:46:45 MST --- Well, I guess that SusePlugger get this information from hal and the data in hal is not correct because of the wrong fdi file. I've no clue why the info.capabilities is always set to 'scanner'. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=469721 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469721#c5 --- Comment #5 from Johannes Meixner 2009-01-28 01:39:13 MST --- I wonder if SusePlugger knows if a device is already configured or not to avoid an annoying usless popup for already configured devices. For scanners we have the sane-backends-autoconfig RPM and /etc/udev/rules.d/55-hpmud.rules in the hplip RPM which do a full automated setup for many USB scanner models. For printers we have cups-autoconfig which does a full automated setup for any USB printer model if it can find a matching driver for it automatically. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=469721 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469721#c7 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #7 from Johannes Meixner 2009-01-28 08:43:42 MST --- As long as we are not "sure what to do with combo devices" I cannot do anything here. I get the data from the upstream projects as is. I can only use it as is. I cannot do anything else here. I am not a mastermind who magically knows which exact sub-devices whatever USB ID provides. All I can do is to replace the too specific value 'scanner' with a value (choose what you like) which is o.k. for the superset of - 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 If you provide me such a value e.g. 'desktop-peripheral' which gets an ACL set as currently for a 'scanner', I can replace 'scanner' with it. This matches that all those 'desktop-peripheral' devices get the group "lp" assigned (i.e. are treated the same on the traditional group layer) see sane-backends.spec: ------------------------------------------------------------- There is no group "scanner" in /etc/group for openSUSE. For all-in-one devices (i.e. printer + scanner, e.g. "EPSON Stylus" devices) the group must be "lp" so that the CUPS usb backend which runs as user "lp" (who is member of the group "lp") can send printing data to the printer unit (i.e. the printer interface of the USB device). It is sufficiently secure and reasonable easy to use by default the same group "lp" for printers and scanners because both kind of devices usually require physical user access (to get the printed paper or to place a paper on the scanner) so that both kind of devices should usually require the same kind of security. ------------------------------------------------------------- I close it again as WONTFIX in openSUSE 11.1 (what we might do for openSUSE 11.2 is another issue) because: --------------------------------------------------------- The problem could be fixed, but the cost for the fix (the amount of work involved) would be enormous. It would be an economic nightmare to do the fix. This would really be a status TOOEXPENSIVE that Bugzilla does not provide. --------------------------------------------------------- compare http://en.opensuse.org/Bug_Status_WONTFIX -- 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.

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 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsmeix@novell.com, | |lnussel@novell.com --- Comment #9 from Johannes Meixner 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.