LCD Display am Parallelport einer Sparcstation4

Jan-Benedict Glaw jbglaw at lug-owl.de
Thu Mar 17 11:45:10 CET 2005


On Thu, 2005-03-17 11:18:02 +0100, Peter Friedrich <business at peter-warb.com>
wrote in message <4239595A.000005.01676 at DEVELL>:
> >Sparc-spezifisches gibt es da nichts mehr, das abstrahiert die ppdev-API
> >fr Dich. Die zentrale Frage ist nur, ob Dein Display denn kompatibel zu
> >dem des Autors ist... Schlimmer ist aber noch, da ich gerade mit
> >mittelgroem Entsetzen feststelle, da  lcdproc inb()/outb() benutzt..
> Was ist eigentlich mit parport_pc und bpp ?
> Zuerst hatte ich mit diesen beiden gelieb?ugelt. Wenn ich die Listings
> richtig interpretiert habe, so stellen sie mir Funktionalit?ten wie Kontroll
> Status und Datenregister zur verf?gung, ?hnlich wie auf einem Intelrechner.
> Oder habe ich da was falsch verstanden?



    +----------+  +-------+  +---------+
    | ppdev.ko |  | lp.ko |  | plip.ko |
    +----+-----+  +---+---+  +----+----+
         |            |           |
    +----+----+...+---+-----------+----+
    |            parport.ko            |
    +---+--------+...+----------+------+
        |                       |
    +---+-----------+  +-------------------+
    | parport_pc.ko |  | parport_sunbpp.ko |
    +---------------+  +-------------------+

So sieht das im Prinzip aus. In der "Mitte" ist das zentrale
Parport-Modul, das es Hardware- und Client-Treibern ermöglicht, sich zu
registrieren. Auf der Hardware-Seite sind Treiber, die für
unterschiedliche Hardware Treiber zur Verfügung stellen (PC, Sparc,
Amiga, PA-RISC, PCMCIA, ...).  Auf der anderen Seite sind mehrere
Client-Treiber, die Treiber für anschließbare Geräte implementieren.
Einige sind zweckgebungen (Drucker, PLIP, IDE-an-Parport, ...), einer
nicht (ppdev).

Auf dem Rechner, an dem Du ein Parport-Display anschließen willst, muß
also das Modul in der Mitte geladen sein, sowie (mindestens) ein
Hardware-Treiber. Von hier aus könnte man nun einen
Kernel-Client-Treiber speziell für ein Display schreiben, aber das
erscheint recht zweckfrei. Da sieht es einfacher aus, vom Userspace aus
die Kontrolle über eine (Hardware-)Parport zu übernehmen und mittels
ppdev die einzelnen Leitungen anzusteuern. (Das sollte man auch recht
schnell in lcdproc eingehackt bekommen, damit die von ihrem inb()/outb()
'runterkommen).

Wenn Du da ein Display hast, das noch nicht weiter unterstützt ist,
würde ich raten, das in lcdproc mit einzugliedern. Das scheint für diese
kleinen Displays _die_ Schnittstelle unter Linux zu sein, und die BSDs
werden so langsam da wohl auch supported...

MfG, JBG
PS: us-ascii und 7bit-encoding ist ja okay, aber dann dürfen keine
Umlaute drin sein...

-- 
Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20050317/4a6b3953/attachment.sig>


More information about the Linux mailing list