LCDproc development and user support list

Text archives Help

[Lcdproc] hd44780 driver and keypresses

Chronological Thread 
  • From: reenoo AT (Rene Wagner)
  • Subject: [Lcdproc] hd44780 driver and keypresses
  • Date: Fri Mar 29 17:38:02 2002

> > That's correct. Otherwise you can't distinguish between screens ;)
> > do you want that S=screen parameter? I mean, since that command is
> > documented yet, we can IMHO change it. AND it's rather simple to
> > change that ;)
> Oh I meant to indicate what the S was for in the "key S K" string. S
> is the screen. No S=screen parameter. The protocol does currently not
> look like that.

I HAVE understood that ;)

> > > I don't think this screen_add_key command is very well thought
> > > through. Maybe we should remove it. I think we should at least not
> > > advertise it in th documentation.
> >
> > Don't you think it becomes useful with the change you suggested
> > applied?
> No it's not useful when we have key reservations. Look, there are two
> ways why a key can be send to a client:
> 1. If it's a shared key, it's for the screen that is in front. That
> is told with "listen S".

OK, so you simply let the client distinguish between the keys
according the last listen S it has received.

> 2. If it's an exclusively reserved key, the client has a special
> action for it. What screen the key is for is of no importance,
> because an exclusively reserved key can only be given away _once_.


> So I think we should silently remove screen_add_key (or at least not
> support it anymore).

Agreed. It's not neccessary as the client CAN distinguish between
keys according to the active screen (listen S) and it makes
things more difficult than neccessary.

I'll make that code a comment in client_functions.c
And I'll modify input.c
Anything else?



Experience is what you get when you didn't get what you wanted.

Archive powered by MHonArc 2.6.18.

Top of page