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.