[Lcdproc] Overloading the 'output' token
bsdfan at nurfuerspam.de
Mon Feb 16 07:33:20 UTC 2009
Ethan Dicks wrote:
> Hi, All,
> * Since the LK204-7T-1U already has nine formal GPOs and since 'output' passes
> * an "int" from the client through the server to the driver, one mechanism that
> * won't break the existing GPO model is to define some of the upper bits in a
> * signed 32-bit int to mean "set backlight color". It seems unlikely that any
> * LCD will implement more than 28 GPOs, so bits 28 and 29 can be used to select
> * four different results of the output command from the client:
> ... It is a complex enough issue that perhaps it
> warrants a Matrix Orbital "configurator" program where the user can
> answer simple questions about their display which results in a series
> of correct parameter settings in LCDd.conf. Something like this was
> proposed for Windows users since "editing .INI files" is alien to most
> of them anymore, but even Linux has filtered down from geeks-only to
> the point where some hand-holding might be in order.
> For now, though, the question I'm putting on the table is if it's
> better or worse to make the user set some LCDd.conf parameter like
> "HasMulticolorBacklight yes/no" to enable these new commands.
> Implementation is easy either way. It's about what is a greater or
> lesser burden to the end-user.
> Comments? Complaints? Acknowledgments?
there has been written a lot of text about his and I would like add even
more to get my thoughts written down.
I think of LCDproc as a software than can be useful to home users as
well as system integrators who want to add displays to there systems or
appliances. So we offer a wide range of displays support starting at
simple text-only output, keypad and LED support, up to fancy case
modding displays featuring colors, fan control, ...
The ouput port was probably intended to drive a LED bargraph attached to
the parallel port. As this, the output() function works with hardware
that is not part of the display. The same is true for output()
controlling GPIO pins of a display. If one uses output() the client does
need to know what happens if it talks to the driver using it (as the
hardware attached to the output port is out of scope for the driver).
One might think to reuse the output function to pass arbitrary command
to the display. However, there are some drawbacks: First the number of
bytes is limited and second it is only sent to the drivery every 1/8
second during an screen update cycle. But in a more general
implementation the client could be programmed to use the full range of
display commands. In this case LCDproc would perhaps not be necessary at
all. If we want to control display features, I like to have a defined
The big question I have is: Shall the backlight be client controllable?
If yes, we should take a more general approach by adding a new command
to the client language and design it in a way it may be used by all
drivers. That is, it shall support monochrome brightness as well as
But the implications of having the backlight client controllable are not
easy to deal with:
* Shall it behave like the current backlight on/off state?
* If yes, shall it be controllable per screen, per client and
* Does it need to be restricted like backlight on/off/open by the
If the backlight does not need to be client controllable, adding a
option to LCDd.conf is not bad. Additionally I would love to see a
server menu to control the colors like it is possible with the
brightness and contrast.
As for the discussion about the number of options: Yes, LCDd.conf does
have a lot of options, but that's not bad IMHO. On the other hand, I do
not want to shadow the myriad of options and functions lcdhype or
lcdsmartie have to LCDproc (regarding Windows users migrating to Linux
But as a first step, it would be nice if the config file is adapted by
configure to the drivers built. (That is, only include sections for
those drivers actually installed).
These are my thoughts,
More information about the LCDproc