[lcdproc] keypresses (was: "named pipe" is different from
/dev/lcdkernel code. :-)])
Tue, 27 Mar 2001 12:18:05 +0100 (BST)
On Mon, 26 Mar 2001, William W. Ferrell wrote:
> --- email@example.com's mailer spewed these beefy chunks ---
> > On Thu, 22 Mar 2001, William W. Ferrell wrote:
> > > 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.
> > I think the best would be that the client requests a "key" in a specific
> > mode. Modes could be:
> > - exclusive:
> > the key will be bound _only_ to this client and delivered
> > regardless if the screen is displayed or not
> > - screen exclusive:
> > the key press is only delivered to the client if one of (?) the
> > client screens is in front.
> > - shared:
> > it's exclusive but the key can be bound to more than one client
> This is good, except I don't see a functional difference between
> screen-exclusive and shared.
If I use screen-exlusive nobody else can register this key all exclusive.
Ok, I try to explan this with an example:
I've written a menu app which would use one key as exclusive (as
popup) und register all other needed keys as screen-exclusive. So the app
is sure these key does not clash with other apps which use this keys in
I've also an app which logs all keypresses (not action else) which would
register all keys as shared (so the keys are available for all other
> And I still want the server to have one key to itself (unless we build a
> separate "server config menus" client, then I suppose the server doesn't
Yes, right. But you can configure this key an if the client requests this
key (for exclusive or screen-exclusive) an error is returned.
> need any keys of its own ... the client could just steal a key with the
> "exclusive" mode, or we could add a "menu key" mode, allowing others to
> write their own menu stuff if they decide ours sucks :)
They (the users) can disable the internal menu (via config file) so the
key is not occupied by the LCDd and the MenuApp can register it.
You can also have two menus (one activated by one key and the other by
> > This raises three questions:
> > - to which instance should the key bound (client or screen ...)
> Keys should probably always bind to a screen. I can't really think of
> any special circumstances that negate this; if a screen gets assigned an
> exclusive key (as in an MP3 player's controls), that key always gets
> sent to the owner of that screen (ends up in the client's lap).
Yes right. The question raised because 0.4 bind the key to the client.
> I wouldn't mind also seeing other special server-exclusive keys, like
> "next screen" and "previous screen".
I also not.
> > - will the server inform the client which key's are available
> Sure, don't see why not.
It have to be implemented ? :)
> > - could be a "key" also a button combination
> It *can* be, if the hardware supports it. Most displays don't deal with
> simultaneous keypresses too well, although I understand Matrix Orbital's
> newest displays just take XT keyboards(!) and fully implement that
Ok, so it's must be possible to use strings/arrays as id (like button 1
and 2 -> add key "12")
> > mode screen exclusive ?
> > It makes no sense to get these keys if the screen is not in front.
> Except for things like an MP3 player. In fact, it'd be useful for
> something like that to both be able to have its own reserved keys that
> always work (even in menus) and be able to override what's currently on
Yes, as explained these are exclusive.
But you have to remember that you will loose one button for all other
clients. If you have only three buttons than you can only drive _one_
Andre' Breiler | Tel: +44 1737 839532
BBC Internet Services | Email: firstname.lastname@example.org
Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Mail me. Don't phone if possible. And use a Subject line.
To unsubscribe from this list send a blank message to