[lcdproc] "named pipe" is different from /dev/lcdkernel code. :-)]

William W. Ferrell wwf@frontierdev.com
Thu, 22 Mar 2001 16:13:47 -0700

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--- joris@robijn.net's mailer spewed these beefy chunks ---
> > Hehehehehe. Windows seems designed not to handle much of anything in a
> > nice way. You do, however, bring up another potential target OS. I must
> > admit, though, to having absolutely *no* way to actually install OS/2 on
> > any of my boxen (don't have the install media anywhere).
> I have not worked with it the last 4 years either, but I still have v3=20
> or v4 laying around here somewhere.

Oh cool! Solves that problem, then :)

> > You mean something like:
> >=20
> > - LCDd runs on the 'doze box
> > - Display driver runs as its own process, listening on a network port=
> > - LCDd connects to said port and does its thing
> Yes that looks like it. I only think the driver should connect to LCDd,=
> so you can dynamically change the attached displays and keyboards (nice=
> for GIF creating etc., see earlier mails with other subject).=20
> LCDd can then have the quiet chalanging task to multiplex all these=20
> connections, manage the framebuffer or some other content-buffer and=20
> handling keypresses (and passing them to lcdproc-processes if needed).=20
> Aint that cool, ay ?

Well, actually ... :)

(See my previous mail expressing openly my current confusion and
indecision; sorry for making all of you witness my thought processes :)

This *does* seem to be a good way to go, the more I think about it.

I don't think the process would be all that challenging.

We've got the "framebuffer" concept, which represents (in LCDd) a
single, physical display. A framebuffer for an alphanumeric is ((x*y) +
(number-of-supported-cust-chars*(cust_x*cust_y)) + 2 bytes give or take
a few bytes (the last two bytes are for contrast and backlight state).

LCDd handles dynamically generating the various custom characters
(either as defined by a client or by the bar graph or heartbeat

Next is the "client" -- a completely independant program that has
nothing to do with LCDd except that it can connect to it and speak its
language. It interrogates LCDd to get a description of the screen(s)
available and its/their capabilities, then defines one or more "screens"
(another concept mentioned in a sec :) with each containing one or more
"widgets" (another one, below :) that represent whatever data the client
wants to display on a screen.

Then the "screen" -- a virtual canvas owned by the client; the client
paints a real display onto the canvas using "widgets".

The "widget" is a text label, bar graph, numeric value, string, graphic,
or whatever, with attributes defining position, size, and content.

Next is the "driver," that actually talks to the physical display. The
driver gets handed the actual framebuffer generated by LCDd, or the
delta (changes) between the previous and current framebuffer if that's
more efficient. Then the driver decides how to most efficiently draw to
the display.

Finally is the "input" concept, and I suspect this will be a bit hairy.
An input is a keystroke or button press that comes in from a driver.
LCDd has to decide where to send that input.

Sorry to rehash the obvious to everyone -- but it would help us to
clearly define all these terms as we go forward.

The hardest part will be rendering a collection of widgets onto a screen
canvas then transforming it into the LCDd "standard" framebuffer.
Deciding which device the framebuffer gets sent to will be relatively
easy compared to rendering the framebuffer:

1) Clients will be able to specify (or at least request) a particular
   display. If it's a spec, it goes there, period. If it's a request,
   it at least "influences" LCDd's choice.

2) If multiply sized displays are attached (i.e. a 20x4 and a 20x2) and
   the framebuffer is a 20x4, the choice is obvious. If it's 20x2, and
   there's another 20x2, then there's a choice:
   a) if there's no other 20x2 framebuffers ready for display, just send
      the current framebuffer to the 20x2 display (or queue it for that

   b) if there *are* other 20x2 framebuffers ready, and the 20x4 isn't
      doing anything (or has a short queue), put the two
      highest-priority (or longest-waiting) framebuffers together on the
      20x4, one on top of the other.

Choosing where input goes is also gonna be difficult, unless we decide
not to completely automate that and instead let the user specify which
keystrokes go where.

Or perhaps just reserve a "menu" key that pops up the menu system (the
server's menu system, not the clients'), that then "takes over" the
other keys until the server's menu system releases them (when it exits
or times out), then let the other clients fight over what's left :)

Another alternative for all that stuff is to have a separate
"configuration" client that LCDd can be configured to trust for
configuration stuff. Then there wouldn't *be* a server menu at all
unless you purposefully loaded the configuration client. It would gain
more privileges (i.e. it could override LCDd's decisions about what
screens to show, since it would need to display menus whenever the user
wanted it) then leave other menus to the other clients.

There'd still need to be a "menu" key though that the config client
could intercept.

*sigh* At least we're getting the driver part worked out :)

William W. Ferrell, Senior System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202   1.303.223.0564

Public key available:
  gpg --keyserver certserver.pgp.com --recv-key 7478FC7A

Don't plan any hasty moves.  You'll be evicted soon anyway.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Content-Type: text/plain; charset=

To unsubscribe from this list send a blank message to