[Pkg-kde-extras] udev rules HP Photosmart (was: Digikam stopped detecting my HP Photosmart camera...)

[Bruce Sass]

On Thu July 10 2008 05:06:32 pm Marco d'Itri wrote:
> On Jul 10, Mark Purcell <msp at debian.org> wrote:
> > > ...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.
>
> This should be clarified first: are both packages supposed to access
> the same device or just libgphoto?

HP's Photosmart series contains both printers/scanners (which HPLIP is 
interested in) and cameras (libgphoto's domain).

> > > 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 it's not actually working if both packages need to access the same
> device.

Different devices; swapping the order works because it lets the more 
specific selector have last crack at defining the device.

> > > 1) the PhotoTools Maintainers can fix this problem by renaming
> > > 025_* to (say) z60_* and adding (perhaps) OWNER="root" to each
> > > entry.
>
> For a start, the ???_ prefixes have been superseded by ??- prefixes
> which are used by other distributions as well.
> BTW, recent udev releases set the default permissions at 91-, which
> is much later than what other distributions do (so the rules file can
> benefit from the environment variables set by earlier rules).
>
> I do not know which users and groups are actually required by each
> package, so I'd rather not comment about the best order of rules
> files. But I want to stress that it's a bad practice to write rules
> which depend on their relative order with respect of the rules of a
> different package.

gphoto requires GROUP == plugdev,
HPLIP requires GROUP == scanner
neither seem to care about OWNER
afaict

> > > 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).
>
> If there is no intersection among the devices supported by each
> package then this one is the correct solution even if it takes some
> more work. Otherwise, I think your packages should agree on a common
> user or group.

I am not aware of any combination camera/scanner devices,
but who knows what the future will bring. :)


- Bruce