Hello,
Till Kamppeter [2009-07-14 18:54 +0200]:
> Is there no possibility for the Python program to write info back
> into the udev database/environment?
As I said, there is, if you use IMPORT instead of RUN. Then the
callout can print "VARIABLE=value" lines to stdout, which then get
imported.
H
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
> th
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 kern
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:
>
Hello,
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.
> Anyway, just pointing out that it makes it a complete waste of time fo
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
Tim Waugh wrote:
> 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
>
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 l
