Hello,
On Apr 23 22:53 Rainer Dorsch wrote:
> Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
> > Johannes Meixner <[EMAIL PROTECTED]> 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.
Do you know what those different usb_endpoints are?
Perhaps the different USB interfaces for the one USB device?
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.
> > > 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...
> >
> >
>
> 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.
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
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
