LCDproc development and user support list

Text archives Help

[Lcdproc] Aopen EA65

Chronological Thread 
  • From: kent2 AT (Kent Williams)
  • Subject: [Lcdproc] Aopen EA65
  • Date: Sun Jan 2 23:25:01 2005

> > Here is my first attempt at a drivers for the vfd on the Aopen EA65
> > shuttle style PC.
> > (
> >
> > Basically I've just modified the Cfontz driver.
> If you want to get your patches into the current code please make
> only to the v0.5 branch (aka HEAD). There is not supposed to be
> development in 0.4 anymore.

No probs - I though that I was using 0.5, I'll fix this up. :)

> Most things in there work about the same anyway. Read the documents
> the info on writing drivers and check out how some simple drivers do
> things (like text or curses drivers)
> Brightness goes from 0 to 1000 in v0.5 and there's a separate get and
> function.

Ok. I'll fix this up.

> > The other problem is that the IR receiver and display share the same
> > serial port and that whilst running this driver with LCD proc, the
> > response of lirc becomes rather poor.
> But they do function both? That is promising. Maybe it does not yet do
> incremental updating to reduce the load on the port. Can anyone tell
> this has been implemented in the v0.5 CFontz driver ?

Yep, they both function, just with LCDd running, lirc misses some button
presses. Incremental updating does not appear to be implemented (at
least in the driver itself) - each time the flush function is called, it
updates the display.

> > Another thing I've also noticed is that output and backlight
> > appear to be called very time the display changes even if the state
> the
> > output and backlight don't. Is this the intended behaviour?
> Erm, well it is like this and it has never been changed... How do you
> mean "intended" ;)

Well, at least with the EA65, you only need to send the backlight and
output commands to the display when they change. For the EA65, this is
an extra 5 bytes per feature. Just at first guess I would have thought
that these function would only be called when the client changes them.
The only reason I brought this up is linked to what you mentioned above
about the incremental updating - if we weren't sending these (usually)
extra 10 bytes down the serial port every update, lirc might be a bit
more responsive. I guess that I could simply fix this up for this


Archive powered by MHonArc 2.6.18.

Top of page