Date: Mon, 04 Oct 2004 11:19:18 +0200
From: Harald Hoyer <harald(a)redhat.com>
Subject: Re: parallel port setup in this brave new udev world?
To: For testers of Fedora Core development releases
<fedora-test-list(a)redhat.com>
Message-ID: <41611596.5010102(a)redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Michael Wiktowy wrote:
>I have a parallel port scanner that has traditionally been pointed
>at /dev/parport0 (call me a savage if you want ... but it hasn't died
>yet so I haven't bought a newfangled usb one)
>
>However, that device is nowhere to be found so I cannot use the udev
>permissions file to set the permissions on the device so that regular
>users can use xsane (and avoid the scolding for using xsane as root)
>
>Oddly enough, root can run xsane fine eventhough there is no device for
>it to find ...
>
>Three questions that I hope someone can enlighten me on:
>
>1) Is there a missing
>KERNEL="parport*", NAME="%n", SYMLINK="parport%e"
>line in the rules file for udev?
>
>
This is nonsense and would create:
/dev/0
/dev/parport -> /dev/0
/dev/1
/dev/parport1 -> /dev/1
If there is no rule, udev takes the kernel name... just load the ppdev module
Thanks for your help. I just mimiced that rule out of the existing
rules file without a real understanding
of how it formulates things. I was just surprised not to find any
parport rules in there.
I will try loading the ppdev module explicitly.
>2) Why is it that root can find the parport device fine eventhough
it
>does not seem to exist? i.e. the scanner is detected and runs fine while
>regular users can't find the scanner.
>
>
$ ll /dev/parport0
crw-rw---- 1 root lp 99, 0 4. Okt 11:16 /dev/parport0
$ ll /dev/lp0
crw-rw---- 1 root lp 6, 0 1. Okt 16:18 /dev/lp0
Maybe it accesses the scanner through /dev/lp0. Normal users do not have permissions for
that file.
I had made my user account a member of the lp group anticipating this
... didn't work. I have no /dev/parport*
... I do have a few /dev/par* though.
I just wanted to find a way that my parport device would persist between
reboots. Maybe the modprobe ppdev
will do the trick.
>3) How does one cause udevd to reread and reapply the
rules/permissions
>in the etc files other than rebooting? "service udevd restart",
"udevd",
>"udevstart" all give me no joy.
>
>
/sbin/udevstart _should_ do the job.
It wasn't. Tonight, I will reconfirm that permission changes are not
being applied with a second
udevstart while udevd is already running (and that I am going about it
the right way),
and enter it into bugzilla if it is not already there.
Thanks.
/Mike