parallel port setup in this brave new udev world?

Michael Wiktowy mwiktowy at gmx.net
Mon Oct 4 15:19:26 UTC 2004


>Date: Mon, 04 Oct 2004 11:19:18 +0200
>From: Harald Hoyer <harald at redhat.com>
>Subject: Re: parallel port setup in this brave new udev world?
>To: For testers of Fedora Core development releases
>	<fedora-test-list at redhat.com>
>Message-ID: <41611596.5010102 at 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




More information about the test mailing list