Graphics on graphical displays (was Re: [Lcdproc] Hi - and a question)

[Ethan Dicks]

On 1/11/07, Jason Ball <jason@ball.net> wrote:
>
> Hi all,

Hi, Jason,

> Well I'm fairly new to LCDProc, and now keenly waiting on delivery of a VFD
> for my HTPC project.
>
> I have a Noritake ITRon GU280x16G-7806 on route.

Looks pretty slick.  I haven't had the pleasure of playing with a graphic VFD,
only text-mode VFDs (20x4, 20x2...)

> This is a graphical VFD which supports a number of text modes and of
> course graphics.  Having read the details on the glcdlib I'm fairly confident
> getting this to work they way I want will be reasonably straight forward.

Sounds like you've done your homework so far.

> One question.. Is there any support in LCDProc to handle 'windows' on
> graphical LCD/VFD's ?  I ask as the 7000 series can support multiple windows
> on the display.  I would like to 'partition' the display to provide a
> graphic indicating the mode the HTPC is in ( i.e. DVD), a window for some
> 'now playing' type data, and a window for a visualiser or other content.
> The mix of windows, fonts etc would be configurable.

Having played a bit with a t6963-based LCD, I think you will find that
LCDproc/glcdlib pretty much takes over your display.  Any windowing
would have to be managed by the LCDd daemon, since it keeps an
internal representation of the contents of the LCD/VFD bitmap,
and LCDproc is oriented towards displaying successive screens
than simutaneously displayed windows (especially since its history
is with 20x4 textual LCDs which don't lend themselves to information
crowding well).

Perhaps you could work with a different low-level driver that would
handle your windowing, then write a new LCDd "driver" interface
like the glue logic between glcdlib and LCDproc - then your running
LCDd daemon would _think_ it owns a patch of screen and change
the renderings, but your new low-level driver would _really_ be
managing the pixels.

LCDproc is really optimized for ([8, 16, 20, 40] x [1, 2, 4]) character
displays rather than graphical displays - it can handle graphical
displays, but it does it in character-sized increments.

If we _are_ considering some migrations to more graphical-friendly
modes, I'd like to see a mode where one could set the rendered
text area on the graphical LCD to an arbitrary size, then be
able to at least put up icon-like graphics in the non-text area.

Imagine this example... you have a graphical panel that normally
would render, say, 20x6 characters onto.  Tell LCDd in the conf
file that you _really_ want to render 16x6 or give it a narrower-
than-normal width in pixels or whatever... then, perhaps, "left"
or "right" to scoot the text all the way to one edge or the other.
So now you have text rendering on part of your panel, but with
an unused square patch on one edge - with some new API,
let LCDd or even the clients shoot an image to that square
patch like an identifying icon - it could be from the server to
give you european-traffic-sign-like warnings and errors, or just
a large version of a browser's "faveicon" to show which client
is running, or perhaps an analog clock, if the client would be
allow to scribble on the icon area arbitrarily, or even a set
of compiled-in or loaded-at-LCDd-start-time icons for today's
weather.

If something like this has been discussed before and hashed
to death, my apologies.  When it comes to graphical displays,
I'm not sure what has and hasn't been talked about.  I was
just thinking of a way to easily add some simple graphics
where those things are allowed.  Heck, I can even imagine
a reduced functionality subset for textual LCD where you
don't get to scribble bitmaps, but you could do arbitrary ASCII
graphics (imagine taking a 20x4 down to 16x4 and giving a
4x4 block of the screen over to this function).

Does this sound like an idea worth further discussion?

-ethan