Re: [sane-devel] Calling a script after USB scanner is plugged
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@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@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
Reply to: