...it turns out the appropriate /dev/bus/usb entry is owned by 
lp.scanner.  :/

Hi All,

Sorry for the lateness of this report, I don't know how many upgrades of 
HPLIP and gphoto have gone through since the problem first appeared, it 
is too many to bother going back and seeing who changed what though.

In a nutshell...

libgphoto2-2 ships: /etc/udev/rules.d/025_libgphoto2.rules
which contains:

a few dozen cameras with ATTRS{idVendor}=="03f0" where ATTRS{idProduct} 
is something ending with "02"

hplip ships: /etc/udev/rules.d/55-hpmud.rules
which contains:

# Check for Photosmart products (0x03f0xx02).
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="??02", OWNER="lp", 
GROUP="scanner", MODE="0660"

...HPLIP is assuming that all Photosmart products are scanners, which 
may well be true and correct (if it is not feasible to list individual 
idProduct's for whatever reason). However, since it does so after 
libgphoto's rules are read, it messes up access to Photosmart cameras.

Simply swapping the order of the two .rules files serves to get Digikam 
working again--but libgphoto's .rules would need to start setting an 
OWNER to ensure that camera devices don't end up owned by lp.plugdev!

So, afaict:

1) the PhotoTools Maintainers can fix this problem by renaming 025_* to 
(say) z60_* and adding (perhaps) OWNER="root" to each entry.

2) the HPLIP Maintainers can fix the problem by getting upstream to 
provide individual idProduct codes (which may or may not require the 
cooperation of the manufacturer).

I don't know which is the better solution (and hence who should get the 
bug), but suspect that 1) could be implemented quicker and is less 
likely to affect currently supported devices negatively (as would 
happen if the list of Photosmart scanners is incomplete).

While I consider this to be something which needs to be worked out 
between the libgphoto and hplip packages, I've included the KDE Extras 
Team and udev because Marco is the one most likely to have the best 
insight into the problem and it is Digikam which appears to be breaking 
(superficially at least, my problem looks the same as #409209, #451783, 
and Bug 155825 in the KDE bug DB, maybe this offers a clue to solving 
one of them).

- Bruce

p.s. Keep me in the loop, please, so I don't get caught with 
duplicate/unnecessary/conflicting rules because of some local fix I've 
implemented... it is the least you can do since I've not filed an RC 
bug against one of you so close to a release.  :-)

pkg-kde-extras mailing list

Reply via email to