Re: [sane-devel] Calling a script after USB scanner is plugged
On Wed, Apr 23, 2008 at 10:53:48PM +0200, 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)
Our device's udev rules file uses:
#
#
BUS!=usb, ACTION!=add, GOTO=xpp_usb_add_end
KERNEL==*_ep*, GOTO=xpp_usb_add_end
KERNEL==[0-9]*, GOTO=xpp_usb_add_end
# the actual rules go in here
LABEL=xpp_usb_add_end
#
#
ACTION!=add, GOTO=end
SYSFS{idVendor}==04b8, SYSFS{idProduct}==010b, RUN+=...
LABEL=end
BTW: any idea when is Debian going to move from SYSFS to ATTR ?
My Lenny box does not seem to support ATTR right now.
--
Tzafrir Cohen | [EMAIL PROTECTED] | VIM is
http://tzafrir.org.il || a Mutt's
[EMAIL PROTECTED] || best
ICQ# 16849754 || friend
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
Am Samstag, 26. April 2008 schrieb Julien BLACHE: Rainer Dorsch [EMAIL PROTECTED] wrote: Hi, The script works now reasonably robust (for now) when I plug the USB scanner. My problem is though, that the script does not get called when I boot the system and the scanner is plugged already during bootup. Why is this? Chances are the coldplugging happens from the initrd and your script isn't available in the initrd. So check that. How would I check if coldplugging happens from the initrd? And would that explain that /etc/init.d/udev restart no effect? Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
Rainer Dorsch [EMAIL PROTECTED] wrote: Hi, Chances are the coldplugging happens from the initrd and your script isn't available in the initrd. So check that. How would I check if coldplugging happens from the initrd? Well anyway it should be redone once the root FS is mounted and the /dev/tmpfs is mounted, so it's not an issue. And would that explain that /etc/init.d/udev restart no effect? Nope, that should always work, provided the effect of the udev restart hasn't changed while I wasn't looking :) JB. -- Julien BLACHE http://www.jblache.org [EMAIL PROTECTED] GPG KeyID 0xF5D65169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
Am Donnerstag, 24. April 2008 schrieb Julien BLACHE:
Johannes Meixner [EMAIL PROTECTED] wrote:
Hi,
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!
udev is an incredible piece of crap, but the good news is that this
piece of crap is mostly stable those days. Which is a big step forward
already.
(and I'll refrain from saying anything at all about the genius who
invented udev. I'll just mention that he's also the author of stable
API is a nonsense.)
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.
You got it.
Very nice to debug!
deWHAT?
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.
Is anybody aware of a more elegant solution for this problem?
You need to copy a bit more than that from. See the top of the file,
there's more to it than that, also the way to identify a USB device
event changed starting with 2.6.22 and the rules are
backward-compatible in this respect too.
You cannot have udev and elegant at the same time
Actually, you can, but you need a bit of udev/uevent knowledge and
some time on your hands.
and you cannot have HAL and elegant at the same time.
It's all HALegant, pff.
Welcome to udev-land, Johannes!
The script works now reasonably robust (for now) when I plug the USB scanner.
My problem is though, that the script does not get called when I boot the
system and the scanner is plugged already during bootup. Why is this?
I call the script using
blackbox:~# cat /etc/udev/rules.d/z_local.rules
ACTION==add, SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, MODE=0664,
GROUP=scanner, NAME=umax%n, RUN+=/usr/local/bin/umax1220u start,
ENV{lamp_off}=yes
blackbox:~#
/etc/init.d/udev restart does not call the script either.
Any ideas what I am missing are welcome...
Thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
Rainer Dorsch [EMAIL PROTECTED] wrote: Hi, The script works now reasonably robust (for now) when I plug the USB scanner. My problem is though, that the script does not get called when I boot the system and the scanner is plugged already during bootup. Why is this? Chances are the coldplugging happens from the initrd and your script isn't available in the initrd. So check that. Otherwise, I see no reason why the script would not be executed. JB. -- Julien BLACHE http://www.jblache.org [EMAIL PROTECTED] GPG KeyID 0xF5D65169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
Hello, On Apr 24 22:45 Julien BLACHE wrote (shortened): udev is an incredible piece of crap, but the good news is that this piece of crap is mostly stable those days. Which is a big step forward already. (and I'll refrain from saying anything at all about the genius who invented udev. I'll just mention that he's also the author of stable API is a nonsense.) There he makes it very clear that The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. But this is in stark contrast to the interface of udev (i.e. the syntax and keywords how to specify udev rules) for applications (e.g. SANE) which provide udev rules and for a normal user udev is completely unusable. It seems one must talk to udev in terms of internal kernel values (e.g. internal kernel event names and so on) instead of a more abstract and therefore more stable higher level language. Actually I am not interested in any internal kernel stuff. I just like to tell udev: When a USB device with ID 0x1a2b:0x3c4d appears and when it is not already configured, then run my setup program and if my setup program exits successfully, remember the device and that it is already configured (even after a reboot). Of course it cannot work when only my setup program remembers which devices it has already configured because the user might have used another setup program before (or did the setup manually). Therefore the information whether or not it is already configured must be kept at a unique central place. Of course this requires persistent storage to keep the device state even after a reboot and I just need this for a well working plug-and-play user experience but I guess the kernel people do not want to do this for whatever internal kernel reason but again I am actually not interested in any internal kernel stuff. Here I am an end-user and I just want to have it work. 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]
Re: [sane-devel] Calling a script after USB scanner is plugged
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...
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.
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]
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 [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. 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/pci:00/: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/pci:00/: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/pci:00/: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/pci:00/:00:1a.0/usb1/1-1 (usb) UEVENT[1209064965.394013] add /class/usb_endpoint/usbdev1.7_ep00 (usb_endpoint) UEVENT[1209064965.398030] add /devices/pci:00/: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/pci:00/:00:1a.0/usb1/1-1 (usb) UDEV [1209064965.401533] add /class/usb_endpoint/usbdev1.7_ep00 (usb_endpoint) UDEV [1209064965.401976] add /devices/pci:00/: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
Re: [sane-devel] Calling a script after USB scanner is plugged
Johannes Meixner [EMAIL PROTECTED] wrote:
Hi,
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!
udev is an incredible piece of crap, but the good news is that this
piece of crap is mostly stable those days. Which is a big step forward
already.
(and I'll refrain from saying anything at all about the genius who
invented udev. I'll just mention that he's also the author of stable
API is a nonsense.)
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.
You got it.
Very nice to debug!
deWHAT?
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.
Is anybody aware of a more elegant solution for this problem?
You need to copy a bit more than that from. See the top of the file,
there's more to it than that, also the way to identify a USB device
event changed starting with 2.6.22 and the rules are
backward-compatible in this respect too.
You cannot have udev and elegant at the same time
Actually, you can, but you need a bit of udev/uevent knowledge and
some time on your hands.
and you cannot have HAL and elegant at the same time.
It's all HALegant, pff.
Welcome to udev-land, Johannes!
JB.
--
Julien BLACHE http://www.jblache.org
[EMAIL PROTECTED] GPG KeyID 0xF5D65169
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
Hello,
On Apr 22 22:18 Rainer Dorsch wrote (shortened):
I want to call a script after I plugged my USB scanner. I use udev for this
by
adding a rule
...
SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, MODE=0664,
GROUP=scanner, NAME=umax%n, RUN+=/usr/local/bin/umax1220u start,
...
When I plug my scanner with this config, it seems an infinite number of
umax1220u scripts are started in a sequence (i.e. not in parallel, when one
is completed the next one starts).
It seems you need a test if ACTION!=add, i.e. a rule like
ACTION!=add, GOTO=end
SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, ... RUN+=...
LABEL=end
I had a similar issue but I got it run only about 5 times
with a rule like
ACTION!=add, GOTO=end
SYSFS{idVendor}==04b8, SYSFS{idProduct}==010b, RUN+=...
LABEL=end
Fortunately in my case what is run is idempotent so that
it doesn't matter when it is run about 5 times.
I don't know the root cause, I guess it is the usual udev crap.
Welcome in the hell of udev, HAL and whatever else sophisticated
stuff which is required to make users happy 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]
Re: [sane-devel] Calling a script after USB scanner is plugged
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.
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 ...)
Welcome in the hell of udev, HAL and whatever else sophisticated
stuff which is required to make users happy or so they say...
aol /
JB.
--
Julien BLACHE http://www.jblache.org
[EMAIL PROTECTED] GPG KeyID 0xF5D65169
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [sane-devel] Calling a script after USB scanner is plugged
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)
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 ...)
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?
Thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
