Keyboard input

[Mike Paquette]

On Dec 13, 2010, at 4:47 PM, Daniel wrote:

> Any thoughts on keyboard input?

I recently completed work on a novel window system not too different from Wayland.  We ran across a number of potentially desirable features and behaviors regarding keyboard input.

* Keyboard mapping/translation

We found it handy to have the keyboard mapping done in the server.  An initial mapping table was loaded at startup, based on the user's preferred language and the type of keyboard present.   At login time, the user's preferences were consulted, and an optional mapping table could be loaded that overrides the startup table.  Some folks wanted the ability to use a different mapping just within their application, so we added the ability to associate a mapping just with one stream of events, to a specific application.


* Hot keys

Hot keys, or keystroke combinations set to preform a specific system management task rather than generate key events, can be set.   These hot keys are typically used to manage display brightness, sound volume/mute, or activate specialized functions such as soft disk eject, or activating a display overlay.    A hot key is typically a function key, or a key in the main array of keys combined with modifier keys, such as Control-Alt-Delete.   We grouped the hot keys into system-level non-overridable and non-disableable keys, user interface controls that could be disabled or overridden, and application level keys that could be disabled or overridden.   There's a bunch of fiddly refinements to these that I can go into if anyone is interested.  (Full screen apps disabling almost all hotkeys automatically, for example.)  Hot key events are routed to specific applications registered with the hot key.

We implemented a registry mechanism that handed out hot keys first come, first served, which also checked for silly things such as registering 'a' as a hot key, no modifiers, and handled collisions between hot key requests, including the system reserved keys.



* Key Thief

This is the behavior where an application grabs the keyboard focus for a while, then hands it back.   We wound up actually implementing a stack of Key Thiefs.  (Why is a fascinating UI design question inappropriate for this list.)  When a key thief grabs keyboard focus, the former focus holder gets an event telling him that he has lost the keyboard focus, so UI can be updated if needed.  When a key thief releases focus (procedurally, or by ceasing to run) focus is returned to the prior holder with a notifying event so UI can be updated if needed. 

It may be desirable for a key thief to have the option of disabling most hot keys.


* Secure Input Mode

Secure input mode is done for security hardening.   While an app is using secure input, keystrokes cannot be monitored or 'sniffed' by other applications.  Key thiefs are held off.   We actually propagated this state to the kernel, where additional code blocked off input monitoring facilities.   The intent is to make key loggers harder to write, and more obvious when installed ("Why do I have to patch the kernel and X Server to install a flying pigs screensaver?").



I'll probably think of some other items over the next day or two.

Oh, I'm new here, so I should probably introduce myself.  I'm a retired software engineer specializing in window systems.  I did an early port of X10r4 to the PIXAR Image Computer, worked on a Display Postscript based server, and designed and  implemented a lightweight window server for a major series of products, which composited multiple buffers drawn with whatever tools the app chose to the display, using OpenGL to accelerate the drawing when available.    I deliberately took a couple of years off from any software work since retiring, as a way to rest and recharge.

The other day, I noticed this Wayland beast, and thought I might be able to contribute.   (Currently at Step 0: Build a LINUX box, read code, build code...)   If there are questions about how other systems did something, I can help with that for now, and offer better solutions that I've thought of post-retirement.   Once I'm up to speed I can probably make more substantial contributions.

http://www.linkedin.com/in/michaelpaquette

	Mike Paquette