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

[William W. Ferrell]

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

--- andreb@rd.bbc.co.uk's mailer spewed these beefy chunks ---
> On Thu, 22 Mar 2001, William W. Ferrell wrote:
>=20
> > 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.
>=20
> 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.

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
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 :)

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

This also lets a client manipulate its own display order or cycle
through the screens it presents.

I wouldn't mind also seeing other special server-exclusive keys, like
"next screen" and "previous screen".

>  - will the server inform the client which key's are available

Sure, don't see why not.

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

Heh. Imagine dealing with scancodes :)

> > 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.
>=20
> It should be configurable on client basis.
> =20
> > 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
>=20
> This key should be konfigurable by the user and the mode would be
> exclusive.

Fair enough, or perhaps bind it to the "menu" type I mentioned above.

> > 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 :)
>=20
> 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
the display (even temporarily) to show what effect pushing the button
had.

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

Q:	Why do WASPs play golf ?
A:	So they can dress like pimps.

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

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

iEYEARECAAYFAjq/Y1oACgkQgAeqhXR4/HrVxwCfQdYRToOSKyov0OOAIp/i/1Jk
s/IAoICp8HPays075s4zlGVgsdommfeA
=LTyb
-----END PGP SIGNATURE-----


--HuscSE0D68UGttcd
Content-Type: text/plain; charset=


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net
--HuscSE0D68UGttcd--