Re: udev-ish replacement for hal-cups-utils?
Hello Tim,
Tim Waugh [2009-07-16 23:31 +0100]:
> The requirements for this are a bit fiddly:
>
> * if CUPS < 1.4 is to be supported, we need to give group lp read/write
> access to the usblp device node
This is provided by 50-udev-default.rules:
KERNEL=="parport[0-9]*",GROUP="lp"
SUBSYSTEM=="printer", KERNEL=="lp*", GROUP="lp"
SUBSYSTEM=="ppdev", GROUP="lp"
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k",
SYMLINK+="usb%k", GROUP="lp"
KERNEL=="lp[0-9]*", GROUP="lp"
KERNEL=="irlpt[0-9]*", GROUP="lp"
> * additionally, the HPLIP "toolbox" program seems to want direct access
> to this node as well, so potentially the console user will get
> read/write access as well using an ACL (although how that can work for
> fast user switching without hal I'm not entirely sure)
This was recently fixed in udev 145:
70-acl.rules: ENV{ID_HPLIP}=="1", ENV{ACL_MANAGE}="1"
Analoguous to the old hal fdis, the hplip package now needs to ship
rules like
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="c302", GROUP="lp",
ENV{ID_HPLIP}="1"
for this to work. This was done in the Ubuntu package, but I don't
know about the upstream status. Till?
> * otherwise, the CUPS usb backend can use libusb so group lp needs
> read/write access to the /dev/bus/usb/xxx/yyy node
How to identify non-hplip USB devices which are printers and talked to
via cups and libusb? Can we rely on printers setting a correct USB
class (7 according to [1])? Or do they need some magic ioctls and
other poking to identify them as printers?
It seems to me that 50-udev-default.rules could just add a rule like
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="07", GROUP="lp"
Kay, do you think that's appropriate?
How did that work in the pre-udev world? hal didn't do anything to
change the group of raw USB devices.
I don't think that auto ACLs are appropriate here, since cupsd isn't
on a "local console" in the ConsoleKit sense, so it wouldn't get
auto-ACLs.
> Can udev set ACLs easily, or should that be done by the callout program?
udev has support for automatic ACLs, similar to the ones that hal
provided. Projects need to ship udev rules which identify particular
devices (ID_GPHOTO2, ID_HPLIP, etc.) and 70-acl.rules in udev then
assigns the ACL_MANAGE=1 tag (the latter is done centrally in udev
just in case the implementation of ACL setting changes).
Thanks,
Martin
[1] http://www.usb.org/developers/defined_class/#BaseClass07h
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
devkit-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Tue, 2009-07-14 at 18:32 +0200, Martin Pitt wrote: > So, one immediate workaround would be to not pass the device ID > itself, but the path (%p) and just read that value plus "/ieee1284_id" > from the python program. That's a little tricky with identifying the > ID at removal time, though (you'd need to remember the quoted one as > well, i. e. consider that an abstract identifier for the real device > ID). Please take a look at the 'udev' branch of system-config-printer: http://git.fedorahosted.org/git/?p=system-config-printer.git;a=shortlog;h=refs/heads/udev I'm trying to use libudev to read the ieee1284_id attribute but am failing. The devpath I'm given is: /devices/pci:00/:00:1d.3/usb5/5-1 I can see that the file I need is: /sys/devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/ieee1284_id but I can't see how to get to it. How do I find out the name "5-1:1.0"? (The code is currently trying usb_interface which is obviously wrong.) Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Fri, 2009-07-17 at 21:56 +0200, Till Kamppeter wrote: > I have looked into udev-configure-printer.c and I see two problems (in > hal_lpadmin this works): > > 1. One device can have more than one queue. Your program supports only > one queue per device according to the syntax of the "remove" call. If > there is actually more than one queue, the one which gets disabled is > probably chosen more or less randomly. > 2. While the device is connected and turned on, additional queues can > get added manually (s-c-p, lpadmin, web interface, ...). These should > also get disabled on device connection. I think these two points amount to the same thing unless I'm reading it wrong. I checked in some changes earlier today which I think address that, at least for the usb://...-only case. In particular take a look at the function for_each_matching_queue(). Something I've thought of since then is about how to handle queues using other backends such as hpfax: I think to handle this we need to pass a *list* of device URIs to the "remove" command, instead of just one. Asking it to do its own MFG/MDL/SERN matching won't work because by that time the device is no longer around, so the CUPS-Get-Devices call won't find any URIs that will match. Hmm, I just realised that I'm doing things the hard way: CUPS-Get-Devices can tell me the actual IEEE 1284 Device ID for each device, so I can just compare the string with what came from '.../ieee1284_id'. I don't even need to parse it! (Although perhaps it would be better to filter out unknown fields in case they are not fixed strings.) > For getting the device ID in "add" mode it must be able to > use both the usblp IOCTL and the libusb method (hal_lpadmin does this, > too). We don't need to do any of this once the '/ieee1284_id' stuff works properly though. > In "remove" mode it must be checked whether the triggering device > is usblp or low-level USB, if it is usblp, it must be checked whether > the corresponding low-level USB device is still there and in that case > terminate without disabling the queue I don't know that this is much of an issue really. Once everyone is using CUPS 1.4 with its libusb-based usb backend, who will still be using usblp? Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
