LCDproc development and user support list

Text archives Help


[Lcdproc] LCD drivers for ARM EP930x series processors


Chronological Thread 
  • From: peter AT adpm.de (Peter Marschall)
  • Subject: [Lcdproc] LCD drivers for ARM EP930x series processors
  • Date: Sun Jul 16 12:52:02 2006

Hi,

On Wednesday, 12. July 2006 11:23, Matt Godbolt wrote:
> I'm looking to write a new driver for LCDproc for the Cirrus Logic ARM
> EP930x series of processors, with the LCD panel directly plugged into
> the DIO ports of the processor (for an example of this see Embedded
> ARM's pages e.g. http://www.embeddedarm.com/epc/ts7250-spec-d.html).
> I'm new to the LCDproc system, but I've already ported lcdmod
> (http://lcd-mod.sourceforge.net/) successfully.
>
> Before I go on and make a driver for LCDproc, I wanted to check a couple
> of things. Firstly that I'm not duplicating anybody's else's work - I
> couldn't find any mention of EP930x support anywhere, but it never hurts
> to check!
>
> Secondly, in order to read and write to the DIO ports of the processor,
> I need to do one of two things: Either run as root and memory map the
> hardware addresses and access them directly, or else use an OS-level
> driver and talk to that. Both have advantages - simplicity and all the
> code in one place for the former, and ability to run as non-root in the
> second. Based on your experiences, does anyone have any suggestions?
> Personally I'm tending towards the second solution at the moment; using
> the lcdmod-based driver I've already got working as a staging post and
> then having a 'direct to LCD' mode within it that I can then hook into
> an LCDproc driver (accessing /dev/lcd, as a non-root user).

There are currently a few other drivers as well that require running the LCDd
server as root. So, I guess, this does not hurt very much.

On the other hand, IMHO requiring a kernel module is sub-optimal as it
requires the user to either re-compile the module when a new kernel comes out
(maybe even pre-compiled from his distribution).
And in case of driver API changes in the kernel this forces the module to be
updated whenever such a change occurs.


> Having spent a little while looking into this, I'm very impressed with
> the existing LCDproc code: It looks very easy to modify!

When writing a driver please use the MAN trunk from CVS, not a - possibly
older - released version.
This makes it easier to integrate the driver in LCDproc's CVS.

Greetings
Peter
--
Peter Marschall
peter AT adpm.de




Archive powered by MHonArc 2.6.18.

Top of page