[Lcdproc] Overloading the 'output' token

[Markus Dolze]

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?
>   
Hi,

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 
interface.

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 
different colors.

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
      server-wide?
    * Does it need to be restricted like backlight on/off/open by the
      server?

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 
discussion).

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,
Markus