LCDproc development and user support list

Text archives Help

[Lcdproc] adding support for off-shelf ARM board?

Chronological Thread 
  • From: liberty AT (Liberty Young)
  • Subject: [Lcdproc] adding support for off-shelf ARM board?
  • Date: Sun Sep 19 02:15:02 2004

I have no qualms about sending in patches that are GPL. That's the
nature of GPL work and Open Source work. I don't want to get into a
debate on GPL vs. Open Source vs. Free Software...suffice to say,
anything we send will be community friendly.

Our x86 boards only need a small patch to 0.4.x..I'll dig it up on
Monday and submit it. The x86 boards just required a special bit on our
hardware to be set, then the lcd device is accessed as if it was
connected to a parallel port.

I haven't coded up a patch for our ARM board yet. This is the one that
should be interesting. I should have something done by the end of this
week. It will require root privileges, as it accesses the lcd device via
mem-mapped areas. Also, I'll have to simulate the bus cycles by hand
(setting certain DIO pins as outputs and inputs when appropriate, then
setting the DIO pins that correspond to RS, EN, and RW correctly when
reading/writing to the lcd display). Icky, true, but that's the way it
has to be done. :)

No special wiring on our part, just funky memory-mapped magic.

On Sat, 2004-09-18 at 07:02, David GLAUDE wrote:
> I see no reason philosophical why we would refuse integrated.
> But...
> LCDproc is not Open Source, but Free Software.
> Your patch has to be GPL.
> Your patch should preferably be available for both 0.5 (the futur) and
> 0.4.5 (the past).
> Your patch should integrate well with the existing HD44780 and all the
> existing sub-driver to deal with various and too many wiring already
> available.
> The long term goal is to get rid of all those hardcoded wiring specifics
> and have something configurable without recompilation... so one day or
> another we might want to break it with your help.
> Hopefully, LCDproc evolution is rather slow, 0.4.5 is rather stable and
> there to stay as it is (almost) for ever. So the possible "catch up"
> game is unlikely.
> However the variety of hardware supported by LCDproc make it hard to
> test every piece of hardware at every upgrade. We will rely on you our
> your customer to verify we did not break anything. Normally, this kind
> of break do not take place frequently because we avoid to touch driver
> space or API between driver and core (but we did it in 0.5 compare to
> 0.4.x and it forced us to code in the dark some driver).
> It would be rather interesting to see you patch (if not too long post it
> here) and to get an explanation on how it is diferent... is it related
> to special IO (not parrallel port) or to a special wiring? Does access
> to that DIO require root or other priviledge? Is the "priviledge
> separation" (getting rid of root priviledge in our case) done diferently
> than for parallel port?
> Also your feedback on running lcdproc (client or server) on arm will be
> very interesting too.
> David GLAUDE
> Liberty Young wrote:
> > I work for an embedded company ( that makes single
> > board computers. All of our products, both x86 and ARM based, have
> > special DIO pins to control a hitachi HD44780 alpha-numeric display.
> >
> > I absolutely love LCD proc, and often refer our customers to your
> > project for their LCD display needs. Would you reject any patches sent
> > by me to this list to get support for LCD displays on our single board
> > computers?
> >
> > We'd rather not play the Open Source "catch up" game where we have our
> > own patches against your software for our products; you upgrade your
> > software, it breaks our private patches, rinse, repeat.
> > We'd rather focus our customers (and any efforts on our part) on your
> > project, and not on rolling forward old private patches.

Archive powered by MHonArc 2.6.18.

Top of page