I'm writing a little tool 'lcd4linux' (http://lcd4linux.sourceforge.net)
which allows to display data on liquid crystal displays connected to the
The whole bit-shifting is done in userspace with outb()'s, until I found
the ppdev stuff. I implemented ppdev access into lcd4linux, and this
works really great! Now I can even use my PCI parallel port card, which
wasn't possible using outb's.
But there are a few things I don't fully understand.... maybe someone
here can give me some hints?
First, I found that the ioctl(PPEXCL) didn't work. I discovered that the
reason is lp.o, which seems to have the port open, too. It works if I
load lp.o with the parameter 'parport=1,none'. If I don't have exclusive
access to the port, can this lead to problems?
Another thing I really don't understand is the autoloading of
parport_pc.o. If I do a 'modprobe ppdev', it loads parport.o and
ppdev.o, but not parport_pc.o (I'm using devfs, and I have an entry
'alias /dev/parport* ppdev'). I should name parport_pc.o somewhere, but
where and how? The strange thing here is, if I 'modprobe lp', it _does_
autoload parport_pc.o, but I don't know why. I found no dependancy to
parport_pc, neither at the vatrious modules.conf, nor in the
modules.dep. How the hell does lp know to load parport_pc????
Testing this stuff is really annoying because I cannt unload lp.o. Even
if nobody uses a parallel port (lpd ist not running), I get the
lp 5456 1
parport_pc 23072 1
Somebody is using the lp module, but who? How can I find out? Because of
the usage count not being zero, I cannot unload the modules (and try
other parameters). Any hints?
I'm running 2.4.2 on i386
The last question is a bit different: I need small delays (about 40
microseconds) while shifting the bits out. I suppose every userland
application that prorams the parallel port with ppdev has this issue.
How do I get such small delays in userland?
I found several ways:
a) busy waiting on a (calibrated) delay loop
b) busy waiting on gettimeofday()
c) busy waiting on rdtsc
d) nanosleep() with SCHED_RR
I don't like a) because of the needed calibration.
I don't like b) because of the large number of system calls
I don't like c) because it's non-portable and not available on older
I don't like d) because of the danger running at SCHED_RR
Maybe ppdev should provide an interface to the kernel udelay() function?
Thanks in advance,
-- netWorks Vox: +43 316 692396 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: email@example.com
-- To unsubscribe, send mail to: firstname.lastname@example.org -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 02:51:14 EST