Re: udev-ish replacement for hal-cups-utils?
On Mon, 2009-07-13 at 18:34 +0200, Till Kamppeter wrote: > Are there no Python bindings for libudev? That's sort of what I was asking. :-) Alternatively, if there is access to this information using simple shell utilities or something, that would also work. > The data written into the HAL DB is the printer's device ID. This way it > is available at the printer disconnection event, when it cannot get > queried any more from the printer. So we need another place to store > this data. The PPD is the best place to store it IMHO. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Mon, 2009-07-13 at 17:45 +0100, Tim Waugh wrote: > That's sort of what I was asking. :-) > > Alternatively, if there is access to this information using simple shell > utilities or something, that would also work. Actually all we need is the IEEE 1284 Device ID. I'll try to look at adding the udev rules along (with the add/remove printer hook) to system-config-printer this week. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Mon, 2009-07-13 at 21:17 +0200, Till Kamppeter wrote:
> If you update the driver and update the PPDs of the existing queues
> (automatically done by Gutenprint and also by all drivers in Ubuntu and
> by all drivers from OpenPrinting) the replacement of the PPD makes the
> device ID injected by hal_lpadmin getting lost.
Hmm. Actually I wish drivers wouldn't do that, but I guess it isn't
always avoidable.
To recap on why this data needs to be stored: we need the device ID,
obtained from the device at connection time, at the point where the
device has already been disconnected. This is so we can match it to the
existing CUPS queue by constructing a device URI and comparing with
those of the existing queues.
Looks like I'll need to investigate Martin's suggestion of using
IMPORT{program} then.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Tue, 2009-07-14 at 13:22 +0200, Till Kamppeter wrote: > 2. All shell-unfriendly characters in the device ID are replaced by '_': > > Original: > > MANUFACTURER:Hewlett-Packard;COMMAND SET:PJL,DW-PCL,ASCII;MODEL:hp > designjet 130nr (C7791D);CLASS:PRINTER;DESCRIPTION:Hewlett-Packard hp > designjet 130nr; > > What got into /tmp/printer.log: > > MANUFACTURER:Hewlett-Packard_COMMAND SET:PJL,DW-PCL,ASCII_MODEL:hp > designjet 130nr _C7791D__CLASS:PRINTER_DESCRIPTION:Hewlett-Packard hp > designjet 130nr_ Wow. I wish I understood why any programs are still trying to munge command lines by replacing strings like '%p' on their own instead of using actual environment variables and letting the shell (or wordexp() if you like) do it correctly. The 'printf' style is useful for constructing strings of characters, but no good at all at constructing an argument vector. In this case we actually need the text of the Device ID completely unaltered. It's useless otherwise. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org 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: > Tim Waugh [2009-07-14 14:20 +0100]: > > I wish I understood why any programs are still trying to munge command > > lines by replacing strings like '%p' on their own > > We just discussed that in #udev, indeed stuff gets quoted if you use > these arguments in rules (pretty much because you do pass them as > command line arguments, into shells, etc.). It's no reason to quote anything if the programs are executed correctly using an argv. Anyway, just pointing out that it makes it a complete waste of time for udev to collect this information, as it can't pass it on in any useful form. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-16 at 10:44 +0200, Till Kamppeter wrote: > So we need a utility written in C which can poll the printer's device ID > with both libusb and usblp methods, so that it returns the device ID > independent whether the device was discovered via low-level USB or > through the usblp kernel module. It should do nothing more than output > "ID_IEEE1284=" on stdout. No, I think this is wrong. Firstly: do we actually need it to fetch the Device ID using the usblp ioctl() method at all? I think it's fine to require that the CUPS usb backend uses libusb. Secondly, it must do more than just collect the Device ID: it must also decide whether this matches any existing queue. Otherwise, we'll *always* end up invoking Python. If a queue needs to be added, enabled, or disabled, then it would need to execve() the Python script to do that. (In fact, enable/disable are simple enough that it could do that without external help.) Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Tue, 2009-07-14 at 13:30 +0200, Kay Sievers wrote:
> On Tue, Jul 14, 2009 at 09:24, Martin Pitt If it makes stuff easier, there is (since a long time) a "REMOVE_CMD"
> in standard udev rules. A rule from any event can define a command to
> run when the device goes away:
> 95-udev-late.rules:
> ACTION=="remove", ENV{REMOVE_CMD}!="", RUN+="$env{REMOVE_CMD}"
So that can be set using IMPORT on the "add" action?
I think this is what's required then:
1. udev-configure-printer:
C program
udev invokes it with IMPORT+="..." to remember Device ID
Operation:
Fetch Device ID
Decide whether we have a queue configured
(Note, during boot cupsd may not have started yet so we'll
need to retry)
For ACTION=="add":
If queue configured but disabled (by us), enable it
If queue not configured, invoke udev-add-printer (see below)
For ACTION=="remove":
If queue configured and enabled, disable it
2. udev-add-printer:
Python program (so it can use cupshelpers)
"Add printer" parts of hal_lpadmin
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-16 at 18:46 +0200, Martin Pitt wrote: > Tim Waugh [2009-07-16 16:59 +0100]: > > It's no reason to quote anything if the programs are executed correctly > > using an argv. > > But RUN clauses in udev rules are mere strings, and thus cannot be > picked apart properly. This line is a mere string too: udev-configure-printer "$IEEE1284_ID" You'll now point out that double-quotes are needed to keep the environment variable expansion in a single word for the argument vector. That's what single quotes are for. :-) ACTION=="add" RUN+='udev-configure-printer "$IEEE1284_ID"' but I don't think udev understands that syntax. My point is that it ought to have been made that way. In other words, a command line is a string that can be picked apart into separate words for an argument vector, by the shell or by wordexp(). The way to pass in arbitrary strings safely is with properly quoted environment variables. > In fact, udev doesn't "collect" sysfs attributes, it just provides one > interface for sysfs. But I agree that this is a bit unfortunate. Probably the best idea for now is to use your suggestion of reading % p/ieee1284_id from the file system. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
Of course, all this is to say nothing of setting the permissions on the device node. :-) 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 * otherwise, the CUPS usb backend can use libusb so group lp needs read/write access to the /dev/bus/usb/xxx/yyy node * 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) From previous experience, if ACLs are used at all they need to be used in all rules so that previously-set ACLs don't get overwritten. Can udev set ACLs easily, or should that be done by the callout program? Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org 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 devkit-devel@lists.freedesktop.org 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 devkit-devel@lists.freedesktop.org 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). Bad news on this front: that ieee1284_id file is supplied by the usblp module, which we are trying to avoid. > A more interesting approach is to use libgudev, which provides a > gobject-based interface to udev. Ideally it'd be easy to auto-generate python > bindings with gobject introspection, but I never did that before. I'll > look into that in the next days, and report back if that's a viable > approach. There's no need, we are in C at the point we need to read the Device ID. So I guess I'll have to do it using libusb. (Not sure how libgudev or libudev would help there...) Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Sun, 2009-07-19 at 19:58 +0200, Till Kamppeter wrote: > Do not wonder why I talk about yesterday's GIT snapshot of > udev-configure-printer, but today's version (commit cca637e7 on the udev > branch) immediately segfaults in the "add" procedure, see more in the > end of this mail. Oh, that's a shame. You should be able to use gdb to find out what it's up to -- just 'gdb --args udev/udev-configure-printer add /devices/...' as root. > It fixes the following problems: > > Hunk in line 150: > > When parsing device IDs, convert the manufacturer name "Hewlett-Packard" > to "HP" and "Lexmark International" to "Lexmark" using case-insensitive > matching. CUPS does this, too and so we have to do it to match against > device IDs from CUPS. Also device IDs obtained by CUPS' "usb" backend > and IDs from HPLIP's "hp"/"hpfax" backends can defer by the manufacturer > names in the device IDs which they report. Actually we don't need to do this. As I hinted (perhaps too softly, sorry) in my last email we don't need to examine the device URI to find matching devices because the CUPS-Get-Devices request returns a device-id attribute which we can use to check against. Theoretically we could just strcmp() the two Device IDs, but in practice some vendors use Device IDs to store state information which can change from retrieval to retrieval. As a result we just compare MFG and MDL, and SERN if it is available. > Hunks in line 212 and 226: > > Do really get the device ID from udev, for real testing and for testing > on my typical desktop configuration of 10 HP printers on the USB (and no > Epson). This method only reports device IDs if my modified udev rules > from my last posting are used and if the usblp kernel module id loaded. Hmm, did you see my commits from today? We use libusb to fetch the Device ID. It's no good relying on usblp -- the libusb-enabled CUPS usb backend won't report any devices if usblp is loaded. I would much rather have the udev-configure-printer hook dependent only on the low-level device, so that there are fewer moving parts to go wrong. > Hunk in line 348: > > Modified the comparing of device IDs. HPLIP often reports a device ID > with serial number when the "real" device ID (reported by udev or by the > CUPS "usb" backend) does not report the serial number. So we should > consider also as a match if one device ID has a serial number and the > other not. Only if the two IDs have different serial numbers we should > consider it as a mismatch. This sounds like an HPLIP bug to me. A Device ID is a Device ID. Why would they change what the device is reporting? Quite honestly I'm fed up with adding in hacks here and there just for the sake of HPLIP. > Hunk in line 551: > > Put the device URIs in quotes for the call of udev-configure-printer on > device removal. Some device IDs (for example of the DesignJet 130) > contain weird characters. Thank you. I'd forgotten URIs weren't necessarily shell safe... how embarrassing. :-) > URIs of the "usb" CUPS backend get principally not assigned due to the > following problem: udev seems to keep the usblp-based printer device > claimed throughout the whole udev procedure, so that other processes > like the callouts for example cannot access the devices. For finding > device URIs corresponding to the currently discovered device ID > udev-configure-printer makes a CUPS_GET_DEVICES IPP request and on such > a request CUPS does a live discovery of all printers by running all > backends without command line arguments. This finds nicely all printer > URIs except exactly the one "usb:/..." URI of the device currently under > consideration, probably because the device is claimed by udev and so the > CUPS "usb" backend cannot access it. So "usb:/..." URIs get never assigned. Indeed. This problem goes away if we just use libusb to fetch the Device ID using the low-level device rule. > This function is also used on a printer connection event, > so no CUPS_GET_DEVICES IPP request is needed. Note also that > CUPS_GET_DEVICES takes some seconds and so it is better to avoid it. It doesn't take very long at all if we limit the included schemes (which we do). > A more straightforward method would be to never trigger > udev-configure-printer on high-level devices but always on low-level > devices. This way the real connection/disconnection events are used. If > getting the device ID by libusb fails it should be checked whether there > is a corresponding high-level device to take the device ID from there. Yes, I think this is needed. > Another improvement which I recommend but I did not test yet (and it > should not break anything) is to make the comparing of device IDs near > line 348 completely case-insensitive (strcasecmp instead of strcmp). > CUPS backends report the IDs of HP printers sometimes with "hp" and > sometimes with "HP" for example. But the device-id attributes will pass the case sensitivity through
Re: udev-ish replacement for hal-cups-utils?
On Mon, 2009-07-20 at 00:15 +0200, Till Kamppeter wrote:
> Unfortunately, the device URIs of both the "hp" and "usb" backend are
> massaged, in the "usb" backend it is only that the manufacturer name
> Hewlett-Packard is replaced by HP and Lexmark International by Lexmark,
> in the "hp" backend the serial number is added
>
> This is the device ID reported by the CUPS "usb" backend:
>
> MFG:Hewlett-Packard;MDL:HP LaserJet 1020;CMD:ACL;CLS:PRINTER;DES:HP
> LaserJet 1020;FWVER:20080222;
>
> This is the one from HPLIP ("hp" backend):
>
> MFG:HP;MDL:HP LaserJet 1020;CLS:PRINTER;DES:HP LaserJet 1020;SN:JL377QZ;
And what is the actual device ID reported by the device? I bet you'll
find it exactly matches what the usb backend says. I think you are
getting confused with the CUPS code that generates the device *URI*,
which does replace some vendor strings and remove the manufacturer
prefix from the model name if present. But the device-id attribute is
what the device gave us, unaltered.
> We must be prepared for broken backends, and this fixes easily many
> broken ones.
I don't accept this. When there are broken backends they ought to be
fixed. This is especially true of HPLIP which is supposed to be free
software after all.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Mon, 2009-07-20 at 17:59 +0200, Till Kamppeter wrote: > I have looked into the source code of the CUPS USB backends (usblp > version and libusb version) and they really report the original, > unmodified device ID. > > I could report this to the HPLIP people telling that they should let > their backends report the unmodified device ID, but it can lead to > > 1. One cannot connect two printers of the same model any more, as the > original device ID has no serial number Please take a look at the current udev branch (d08eb47). For the specific case where the device does not provide its own SERN field in the Device ID, there are two possible cases we now allow for: 1. Adding a SERN field to the Device ID, consisting of the USB serial number. On reflection this does make some amount of sense. This is what the HPLIP backend does. 2. Including the USB device ID in the device URI. This is what the CUPS usb backend does when compiled with libusb support. On Tue, 2009-07-21 at 02:03 +0200, Till Kamppeter wrote: > 1. Bug in removal procedure, looks like that the program was only tested > on a system with only one printer. Here is the fix: Thanks, applied. > 2. "Incorrect line in /var/run/udev-configure-printer/usb-uris:" warnings > > The warnings were triggered by blank lines in > /var/run/udev-configure-printer/usb-uris and in addition, every line has > one extra character in the end. I think that should be fixed with a difference change I checked in to use '\n' as a token delimiter as well as '\t'. > 3. HPLIP broken device IDs As I mentioned in my last email, I think this should work now in a way that's fair to all manufacturers. > 4. HPLIP Fax queues (not tested yet) > > Fax URIs of HPLIP do not have the device ID of the actual printer so > that they get associated with the Fax PPD files. The easiest to get > Fax queues enabled and disabled (and also created if no fax queue is > there) is probably that when an "hp:/..." URI is added to the matching > URIs to automatically add also the "hpfax:/..." URI with "..." being > the same as in the "hp:/..." URI. Unfortunately, this is again an ugly > HPLIP exception. Yes, I see. There's basically no "right" way to do this then. :-( I think the only option we have here is to look for 'fax' in either the CUPS device URI scheme or the device-id MDL field. Assuming fax machines will always be part of a multi-function device that also prints, let's do this when adding a queue: When two CUPS devices, one of which matches the Device ID of the device, are identical except for the scheme part, and the remaining URI has a scheme ending with 'fax', set up a queue for the *fax URI as well. > Note that I have always connected or disconnected only one printer at > a time. As there is one file to store the matching URIs for all > printers I can imagine that the file can get completely messed up when > several printers get connected or disconnected at the same time, for > example by plugging a USB hub with several printers on it. This > problem should also get addressed. I've added locking now. Thanks for pointing it out. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Wed, 2009-07-22 at 03:53 +0200, Till Kamppeter wrote:
> Here I suggest a samll change. If there are both URIs which fit with
> serial number and which fit without serial number, take them all
> together into the valid URI list (instead of dropping all non-serial if
> one with serial is found, to assure the disabling and re-enabling of
> existing queues.
Yes, OK, that makes sense.
> URI selection for new queues should only be made based
> on how well the URI fits to the hardware, for example if there is an
> HPLIP URI, prefer using it instead of the plain CUPS "usb" URI.
Ideally, of course, hpijs would use the back-channel/side-channel
support present in the CUPS backend. Then it would automatically gain
support for USB, parallel port and network devices, allowing a whole
load of code to be removed from HPLIP including the hp backend itself.
It seems to only require looking at the Device ID, which can be fetched
using the side-channel command CUPS_SC_CMD_GET_DEVICE_ID.
For the time being, I'll get udev-configure-printer to prefer the hp
backend over the usb backend, as the above is not likely to happen
without someone making a large patch.
> In general, blank lines (whitespace-only lines) should be ignored.
This is not a user-modifiable file. There won't be blank lines.
> The URI problem is solved, the problem that HPLIP replaces all
> manufacturer names "hp", "hewlett-packard", and "Hewlett-Packard"
> (case-insensitive match) by "HP" still requires this ugly patch:
No, it requires HPLIP to report the correct device-id for the device.
Look, here is a patch to actually do that:
http://cvs.fedoraproject.org/viewvc/devel/hplip/hplip-device-id.patch?view=markup
> I have already tried opening the URI file for reading and writing
> ("w+"), lock it with a write lock (exclusive), read it, process data,
> write it, and then close it. Problem is that I do not succeed to
> truncate the file to zero before writing it.
Did you try using ftruncate()? ;-) Fixed.
> The following patch adds better error reporting and also fixes the
> problem that if the URI map empties (all printers disconnected), the
> line for the last printer still remains in the URI map file. It should
> go away, too.
I don't see that problem here. More comments about this patch:
> if (fd == -1)
> -return map;
> +{
> + syslog (LOG_ERR, "Unable to open for reading " USB_URI_MAP);
> + return map;
> +}
This is not an error.
> fclose (f);
> + close(fd);
> return map;
The fclose call closes the underlying file descriptor.
> - for (each = map; each; each = each->next)
> + if (map != NULL)
> {
> - size_t i;
> - fprintf (f, "%s\t%s", each->devpath, each->uris.uri[0]);
> - for (i = 1; i < each->uris.n_uris; i++)
> - fprintf (f, "\t%s", each->uris.uri[i]);
> - fwrite ("\n", 1, 1, f);
> + for (each = map; each; each = each->next)
> + {
> + size_t i;
> + fprintf (f, "%s\t%s", each->devpath, each->uris.uri[0]);
> + for (i = 1; i < each->uris.n_uris; i++)
> + fprintf (f, "\t%s", each->uris.uri[i]);
> + fwrite ("\n", 1, 1, f);
> + }
> + fclose (f);
> + close(fd);
> }
> - fclose (f);
> + else
> +unlink(USB_URI_MAP);
> }
The 'for (each = map; each; ...' bit handled map==NULL without any
problems. Not sure what problem you are trying to solve there.
> 2. This patch for the "remove" process makes parents and children of the
> original device path which was used for the "add" process also disable
> the queues. This should make the "remove" process more reliable,
> especially on systems where the usblp module is still in use.
The usb-uris map always contains the devpath of the ("usb","usb_device")
device. Did you see an actual problem here?
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Wed, 2009-07-22 at 21:30 +0200, Till Kamppeter wrote: > Great, have you also posted an upstream bug report with the patch, on > http://launchpad.net/hplip/? No, not yet. > The "usb"-and-"hp"-only CUPS_GET_DEVICES IPP request does not actually > work for me (CUPS 1.3.11). I get back the answers of all CUPS backends, > not only of "hp" and "usb". Therefore I have inserted this code piece to > filter out the unwished backends manually. That must be new in CUPS 1.4 then. Thanks. > The very last change is to take into account that serial numbers can be > shorter than 12 characters. Serial numbers from the Device ID field can be any length, yes, but 'serial' in that context is the USB serial number. As I understand it these must have a minimum of 12 characters. > - uris->uri[uris->n_uris + i] = uris_noserial.uri[i]; > + uris->uri[uris->n_uris + i] = strdup(uris_noserial.uri[i]); Good catch, thanks. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-23 at 00:10 +0200, Till Kamppeter wrote: > >> The very last change is to take into account that serial numbers can be > >> shorter than 12 characters. > > > > Serial numbers from the Device ID field can be any length, yes, but > > 'serial' in that context is the USB serial number. As I understand it > > these must have a minimum of 12 characters. > > > > But as usually serial numbers of the hardware devices get used here, we > must support also these, so we must use any non-empty string. What I'm saying is that the 'serial' variable is *always* the USB serial number, and never the SERN field (that's id->sern). Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-23 at 12:21 +0200, Till Kamppeter wrote: > "hp:/usb/HP_Color_LaserJet_CM3530_MFP?serial=CNFND01964" contains a USB > serial number, but this serial number has only 10 characters. OK, we'll have to be less strict about that then. That's a shame. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-23 at 10:49 +0200, Till Kamppeter wrote: > You are missing the NULL check here (musb.c, line 2083): > > ieee1284_id = udev_device_get_sysattr_value (ddev, "ieee1284_id"); > strncpy (device_id, ieee1284_id, len); > device_id[len - 1] = '\0'; Thank you, fixed. > An additional strange thing here is that we reach this point as without > usblp the libusb method should always obtain the device ID. So perhaps > the code has another bug and I got my device IDs always by the kernel > module/udev method? Perhaps the permissions are not correct on /dev/bus/usb/xxx/yyy? Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Wed, 2009-07-22 at 22:11 +0200, Till Kamppeter wrote: > How do you handle the enabling and disabling the Fax queues when the > printer is connected or disconnected? I didn't, but I've added that. The way udev-configure-printer does it now is to identify the device URIs that match the device, then look for "paired" device URIs where the URI is the same as one of our matching ones but the scheme is different. We then consider that device URI as associated with the device as well. > And if you add a fax queue with > udev-add-printer triggered by the missing print queue, do you make sure > thatb there was no fax queue yet? No, thank you for spotting it. Fixed. > My suggestion is to also check hpfax: URIS and to match them with the > device ID of the detected device by searching manufacturer name, model > name, and serial number in the device URI (not the device ID), like you > do already with serial numbers. I don't want to make any assumptions about the structure of a device URI because (a) there's no standard way of forming them for backends to adhere to, and (b) any given backend may decide to change the format of its advertised URIs. Looking for the USB serial number is a special case, and is done as a last resort. Even then, it is done in an entirely generic manner, not expecting it to appear anywhere particular in the URI, but hoping it will appear somewhere. It happens that this is the case for at least two CUPS backends. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-23 at 17:02 +0200, Till Kamppeter wrote: > OK, have you already implemented that? Can you commit it to the git repo? I merged the udev branch in 1.1.x yesterday and further fixes have been going there. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-23 at 19:15 +0300, Ozan Çağlayan wrote: > I've tested it with an ML-1610 and it worked fine except it gets > configured two times because of the udev rule which triggers the helper > upon the low-level addition and the lp one. I think I know how that might have happened. I've just checked in the fix. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Thu, 2009-07-23 at 16:55 +0200, Till Kamppeter wrote: > I have applied it to our Ubuntu HPLIP package and now the segfault goes > away, but if there is no usblp kernel module, most device IDs do not get > read from the printers. See below. I have run the backend twice and on > both runs the same printers did not report their device IDs, all > PCL-based inkjets. I've been looking at this today. I've changed my hplip patch so that it uses some of the existing hpmud machinery to fetch the Device ID using libusb. Could you try again with CVS revision 1.3 of devel/hplip/hplip-device-id.patch? http://cvs.fedoraproject.org/viewvc/devel/hplip/hplip-device-id.patch?revision=1.3 > Is it possible that they do not get set in time before > udev-configure-printer gets started (they are set by another udev rule > file)? Yes, it's possible. Is that actually what the problem is? Can you look with strace (i.e. strace -f cupsd) to see? Which rule sets the permissions, anyway? Is it 70-acl.rules from /lib/udev/rules.d? Perhaps printers.rules ought to be set later than that (although since 'p'>'a' it already should be). Thanks for helping out with testing. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Fri, 2009-07-24 at 03:30 +0200, Till Kamppeter wrote: > The attached patch solves all problems. Now I can cleanly plug and > unplug 10 printers at once, with and without the usblp kernel module > being available/present! Thanks. Applied. > Jul 24 02:57:04 till-laptop udev-add-printer: TypeError: getDevices() > takes no keyword arguments I've put in fallback code so that the include_schemes parameter is omitted if not recognised. > Now it would be much nicer to let the fax queue have the name > > HP-LaserJet-3390-Fax Done. > but the notification refers to the network queue which already existed > before. Fixed. I've also brought the check for whether we already have a usb-uris entry for this devpath to earlier than our check for device URIs. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Fri, 2009-07-24 at 21:10 +0200, Till Kamppeter wrote: > We are arriving at our destination! It's in sight but we're not there yet. Next step is to separate out the CUPS parts into a D-Bus system service. :-) I'm working on code to do that so we have these methods: UsbPrinterAdd (string devpath, string deviceid) UsbPrinterRemove (string devpath) where devpath is the usb_device devpath. Then the udev rules simply call these methods, which immediately return and perform processing in the background -- with locking, as before, of course. In the future this service could be used to add queues (including selecting an appropriate driver) for bluetooth printers, network printers, you name it. > Only one small bug which you have > introduced when moving the duplicate devpath check to the beginning. > Patch attached. Oops, thanks. Applied. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Fri, 2009-07-24 at 21:47 +0200, Till Kamppeter wrote: > When will this come? Right now? Later? It's not working yet -- later, perhaps next week. I just started working on it today. I'll be doing development on that in the udev branch, with just fixes to the existing system we've been working on going into the 1.1.x branch until the new work is complete. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
On Fri, 2009-07-24 at 21:47 +0200, Till Kamppeter wrote: > When will this come? Right now? Later? It's implemented now, and merged into 1.1.x. I've removed the udev branch. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: udev-ish replacement for hal-cups-utils?
I've reverted the D-Bus system service change, as Till pointed out a race condition with doing it that way. Instead we'll do it by forking the process, as before. On Wed, 2009-08-05 at 16:05 +0300, Ozan Çağlayan wrote: > Aug 5 15:42:44 ozan2009-pardus /lib/udev/hpljP1005: foo2zjs: loading HP > LaserJet P1005 firmware /lib/firmware/sihpP1005.dl to /dev/usb/lp0 ... > Aug 5 15:42:44 ozan2009-pardus /lib/udev/hpljP1005: foo2zjs: ... > download successful. > Aug 5 15:42:50 ozan2009-pardus python: io/hpmud/musb.c 136: unable > get_string_descriptor -110: Connection timed out Presumably this is a conflict between the CUPS 'hp' backend (from HPLIP), trying to fetch the Device ID using libusb, and the foo2zjs firmware upload. I think it might be avoided in the next HPLIP release, which avoids needing device access during device discovery while still reporting accurate IEEE 1284 Device IDs. > So is the current 1.1.x branch feature complete for a complete > replacement of hal-cups-utils? I think it is, today, having reverted the D-Bus system service part. I hope to make a 1.1.11 release soon. > What other components should I update to replace hal-cups-utils with the > udev one. AFAIK: > > - Bump system-config-printer, configure it with --with-udev-rules, > - Obsolete hal-cups-utils, > - Tweak cups init script to retry the configuration. > > I once saw a device-id patch in HPLIP, is that an independent bugfix for > a stable device-id detection or was it needed for the udev-ish replacement? That is also required for correct operation with the new automatic print queue solution. I believe HPLIP 3.9.8 will behave correctly without needing to be patched. Tim. */ signature.asc Description: This is a digitally signed message part ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
