LCDproc development and user support list

Text archives Help


[Lcdproc] new LCDproc-0.5 "meta"-driver soon


Chronological Thread 
  • From: lucianm AT users.sourceforge.net (Lucian Muresan)
  • Subject: [Lcdproc] new LCDproc-0.5 "meta"-driver soon
  • Date: Tue Jan 25 17:13:02 2005

Hi,

I'm almost close to finishing a new driver for LCDproc-0.5, which will
add support for several graphical LCDs and VFDs in text mode. I haven't
checked which of them are already supported natively by LCDproc, but,
anyway, there are new ones, too.
Until now, I just implemented the basic stuff, more or less to prove
myself that it works (and it does), but now I have some
implementation/design questions to sort out with you LCDproc guys before
I continue, so be warned this will be a long message, but I hope I'll
have some discussion whith you on this topic, so I'll try to give you an
overview first.

Let me describe a little what's this all about and what I did so far:

The driver is using a package written in C++ (and of course I had to
write a C wrapper for using it in LCDproc), which is not yet released by
it's maintainer, but basicly it's a refactoring of the graphlcd plugin
for VDR, see http://www.powarman.de/vdr_graphlcd.htm (the animated GIF
is cool to look at).
The maintainer of this VDR plugin already split it up in libglcddrivers
and a libglcdgraphics (so this will probably be the upcoming
graphlcd-base-0.1.2 that I'm actually using), and the VDR plugin itself
in which we are not interested at this point.
Libglcddrivers implements the hardware support for the displays listed
on that homepage plus Noritake800 series displays I already wrote and
Andreas already included in the pre-release, and libglcdgraphics
implements basic bitmap drawing and bitmap font handling (the fonts used
up to now are in an own format emerged from earlier versions of the
VDR-plugin, but I already experimented whith using FreeType2 in the
graphics library, to load any scalable font and prepare it for usage in
the graphics library).

Now let me go into a little deeper details and maybe we can sort out
some implementation issues here:
The C wrapper I wrote is actually just a specialized to LCDproc one,
It's a library containing just one class implementing a generic LCDproc
driver using libglcddrivers and libglcdgraphics and the exported wrapper
functions. Then, the new "glcdlib" driver I added in LCDproc-0.5 uses
this wrapper library, it only passes the name of the graphlcd driver it
wants to use, and the font it should load and in which size, this
resulting in the LCDproc display size in characters (I still have to
finish some issues with the font having to be a fixed-width one for
usage in LCDproc, and of course the special "icons" LCDproc needs, but
that's not really a problem).
Does it make sense to release this specialized wrapper library as a
separate package, or include it in a subdirectory in
...lcdproc/server/drivers/glcdlib whith a Makefile of its own
instructing the compiler to compile C++ here and then link all together
in the glcdlib driver module? Or maybe this isn'nt even possible, or
wanted? Either way, I'd need help on how to create this Makefile if it's
to be included in LCDproc, and how to write the library auto-detection
code in ....server/drivers/Makefile.am (either for my glcdlibwrapper
library only, or for libglcdrivers & libglcdgraphics & maybe even for
FreeType2). I already have the feeling that you'd prefer to have the
wrapper library as a separate module for which to check, and let the
wrapper library itself to check if it has all the dependencies satisfied
(it's also easy to use it without FreeType2 support).
Libglcdrivers uses a configuration file of it's own, where all the
different supported graphical LCDs and VFDs are configured, so in
/etc/LCDd.conf at the [glcdlib] module section only needs to provide the
name of the driver it wants to use from libglcddrivers, and the font and
it's size if using FreeType2. Concerning this, are there any "standard"
LCDproc display sizes (in fixed width characters) I should enforce in my
driver, depending on the available pixel resolutions of these displays?


So pelase let me hear your questions, advices, concearns and ideas!

Greatings,
Lucian

P.S. Licensing will be GPL





Archive powered by MHonArc 2.6.18.

Top of page