[sane-devel] Calling a script after USB scanner is plugged

Rainer Dorsch rdorsch at web.de
Thu Apr 24 19:46:06 UTC 2008


Johannes,

Am Donnerstag, 24. April 2008 schrieb Johannes Meixner:
> Hello,
>
> On Apr 23 22:53 Rainer Dorsch wrote:
> > Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
> > > Johannes Meixner <jsmeix at suse.de> wrote:
> > >
> > > Hi,
> > >
> > > >> umax1220u scripts are started in a sequence (i.e. not in parallel,
> > > >> when one is completed the next one starts).
> > >
> > > When troubleshooting udev rules, use udevmonitor to actually see
> > > what's happening in terms of udev events and their properties.
> >
> > That was a very good hint, thanks. A single scanimage -L causes these
> > events:
> >
> > UEVENT[1208979136.171525] remove   /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UEVENT[1208979136.171696] remove   /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UEVENT[1208979136.171702] remove   /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
> > UEVENT[1208979136.171707] add      /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UEVENT[1208979136.171712] add      /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UEVENT[1208979136.171717] add      /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
> > UDEV  [1208979136.172276] remove   /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UDEV  [1208979136.172803] remove   /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UDEV  [1208979136.173239] remove   /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
> > UDEV  [1208979136.174020] add      /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UDEV  [1208979136.174831] add      /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UDEV  [1208979136.175619] add      /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
>
> I wonder how "scanimage -L" causes any add or remove event at all.
> I cannot imagine that those add or remove events are the
> same add or remove events which happen when the device
> is plugged-in at the USB or plugged-off from the USB.

Judging from the udevmonitor output it seems they are at least very similar. 
Apparently the /class/usb_endpoint/usbdev1.6_ep00 is not included in the 
events of the scanimage call but it is included when I replug the device.

This is the output of udevmonitor when replugging the device (commented out 
the udev rule which calls the script with scanimage):

UEVENT[1209064961.290600] remove   /class/usb_endpoint/usbdev1.6_ep01 
(usb_endpoint)
UEVENT[1209064961.290627] remove   /class/usb_endpoint/usbdev1.6_ep82 
(usb_endpoint)
UEVENT[1209064961.290633] remove   /class/usb_endpoint/usbdev1.6_ep83 
(usb_endpoint)
UEVENT[1209064961.290638] 
remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UEVENT[1209064961.290643] remove   /class/usb_device/usbdev1.6 (usb_device)
UEVENT[1209064961.290648] remove   /class/usb_endpoint/usbdev1.6_ep00 
(usb_endpoint)
UEVENT[1209064961.290653] remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1 
(usb)
UDEV  [1209064961.291029] remove   /class/usb_endpoint/usbdev1.6_ep01 
(usb_endpoint)
UDEV  [1209064961.291540] remove   /class/usb_endpoint/usbdev1.6_ep82 
(usb_endpoint)
UDEV  [1209064961.291973] remove   /class/usb_endpoint/usbdev1.6_ep83 
(usb_endpoint)
UDEV  [1209064961.292349] 
remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UDEV  [1209064961.292882] remove   /class/usb_device/usbdev1.6 (usb_device)
UDEV  [1209064961.293363] remove   /class/usb_endpoint/usbdev1.6_ep00 
(usb_endpoint)
UEVENT[1209064965.393967] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1 
(usb)
UEVENT[1209064965.394013] add      /class/usb_endpoint/usbdev1.7_ep00 
(usb_endpoint)
UEVENT[1209064965.398030] 
add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UEVENT[1209064965.398042] add      /class/usb_endpoint/usbdev1.7_ep01 
(usb_endpoint)
UEVENT[1209064965.398048] add      /class/usb_endpoint/usbdev1.7_ep82 
(usb_endpoint)
UEVENT[1209064965.398053] add      /class/usb_endpoint/usbdev1.7_ep83 
(usb_endpoint)
UEVENT[1209064965.398058] add      /class/usb_device/usbdev1.7 (usb_device)
UDEV  [1209064965.399964] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1 
(usb)
UDEV  [1209064965.401533] add      /class/usb_endpoint/usbdev1.7_ep00 
(usb_endpoint)
UDEV  [1209064965.401976] 
add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UDEV  [1209064965.437713] add      /class/usb_endpoint/usbdev1.7_ep01 
(usb_endpoint)
UDEV  [1209064965.437730] add      /class/usb_endpoint/usbdev1.7_ep82 
(usb_endpoint)
UDEV  [1209064965.437736] add      /class/usb_endpoint/usbdev1.7_ep83 
(usb_endpoint)
UDEV  [1209064965.448441] add      /class/usb_device/usbdev1.7 (usb_device)

These are the events from a scanimage -L:

UEVENT[1209064997.544063] remove   /class/usb_endpoint/usbdev1.7_ep01 
(usb_endpoint)
UEVENT[1209064997.544262] remove   /class/usb_endpoint/usbdev1.7_ep82 
(usb_endpoint)
UEVENT[1209064997.544301] remove   /class/usb_endpoint/usbdev1.7_ep83 
(usb_endpoint)
UEVENT[1209064997.544337] add      /class/usb_endpoint/usbdev1.7_ep01 
(usb_endpoint)
UEVENT[1209064997.544372] add      /class/usb_endpoint/usbdev1.7_ep82 
(usb_endpoint)
UEVENT[1209064997.544407] add      /class/usb_endpoint/usbdev1.7_ep83 
(usb_endpoint)
UDEV  [1209064997.544770] remove   /class/usb_endpoint/usbdev1.7_ep01 
(usb_endpoint)
UDEV  [1209064997.545279] remove   /class/usb_endpoint/usbdev1.7_ep82 
(usb_endpoint)
UDEV  [1209064997.545703] remove   /class/usb_endpoint/usbdev1.7_ep83 
(usb_endpoint)
UDEV  [1209064997.546444] add      /class/usb_endpoint/usbdev1.7_ep01 
(usb_endpoint)
UDEV  [1209064997.547276] add      /class/usb_endpoint/usbdev1.7_ep82 
(usb_endpoint)
UDEV  [1209064997.547997] add      /class/usb_endpoint/usbdev1.7_ep83 
(usb_endpoint)


> Do you know what those different usb_endpoints are?
> Perhaps the different USB interfaces for the one USB device?

I have no idea, sorry.

> I wonder how one could specify a udev rule which matches
> to the one "add" event for the one USB device instead of
> whatever bulk of "add" events for whatever stuff which
> is related to the one USB device.

That is a good point.

ENV{DEVPATH}=="/class/usb_endpoint/usbdev1.6_ep00", SYSFS{idVendor}=="1606", 
SYSFS{idProduct}=="0010", MODE="0664", GROUP="scanner", NAME="umax%n", 
RUN+="/usr/local/bin/umax1220\

has the problem that it does not match the usb device (1.6 in this example).

ENV{DEVNAME}=="/dev/umax00", SYSFS{idVendor}=="1606", 
SYSFS{idProduct}=="0010", MODE="0664", GROUP="scanner", NAME="umax%n", 
RUN+="/usr/local/bin/umax1220u start", ENV{lamp_off}\
="yes"

did not work, although the umax00 corresponds to the device id ep00. Not sure 
if that is not yet know in the rules file.

Having in the umax1220u script a condition

if  echo $DEVPATH |grep ep00 > /dev/null ; then

works well and I like this a little better than the lock file hack.

To make it robust for future udev releases: Is there any estimate if DEVNAME 
or DEVPATH is less likely to change in future udev releases?

> > > > ACTION!="add", GOTO="end"
> > > > SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
> > > > LABEL="end"
> > >
> > > Be careful with the labels you use. Always use a unique label name, or
> > > you're asking for troubles. (been there, done that, accidentally
> > > rendered a number of systems unbootable due to that ...)
>
> Many thanks for this enlightening info!
> Impressive: A thoroughly thought out fail-safe design!
>
> Actually - just because of a queasy feeling - I used
> ACTION!="add", GOTO="sane_backends_autoconfig_rules_end"
>
> Of course "man udev" does not mention that all labels
> in all udev rules files must be unique.
>
> I can only guess that what udev actually does is to
> concatenate all udev rules files into one single set
> of rules and then it is not surprising when arbitrary
> nonsense happens depending on which individual udev rules
> files exist on a particular system which depends on which
> individual software packages are installed on this system.
>
> Very nice to debug!
> Very easy to help others!
> Makes all users very happy of course - or so they say.
>
> > I tried that before after I saw the z60_libsane.rules
> >
> > ACTION!="add", GOTO="post_lamp_off"
> > SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
> > GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
> > ENV{lamp_off}="yes"
> > LABEL="post_lamp_off"
> >
> > But given the events, it is obvious not surprising that this is not
> > working.
> >
> > > > Welcome in the hell of udev, HAL and whatever else sophisticated
> > > > stuff which is required to make users happy or so they say...
> > >
> > > <aol />
> >
> > I added now in my script a file system lock:
> >
> > if [ ! -e /tmp/umax1220u-plugged ]; then
> >
> >   touch /tmp/umax1220u-plugged
> >
> > Is anybody aware of a more elegant solution for this problem?
>
> You cannot have "udev" and "elegant" at the same time
> and you cannot have "HAL" and "elegant" at the same time.
>
> Just do whatever dirty hack fits at the moment for you
> and be prepared that next version is sufficiently different
> so that your stuff does no longer work.

I confirm that this area broke at least two times for me :-(

Rainer

> Then just do whatever other dirty hack and so on ad nauseam
> which makes you happy of course or so they say...
>
>
> Kind Regards
> Johannes Meixner



-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch at web.de
jabber: rdorsch at jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/



More information about the sane-devel mailing list