Keyboard input

Stefanos A. stapostol at
Tue Dec 14 02:20:35 PST 2010

2010/12/14 Mike Paquette <paquette.mj at>

> 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.
One small question to get the hang of this. I use the awesome colemak
keyboard layout ( which has a top row that reads "qwfpg"
instead of "qwerty". Yesterday, I installed Starcraft 2 and was amazed to
see that it recognized this and remapped its hotkeys to fit my keyboard
layout automatically. For instance, the "e" (qwerty) hotkey was mapped to
"f" (colemak) which it has the same physical location on the keyboard. Had
it remained at "e" (colemak) I'd have to press "k" (qwerty) which, needless
to say, would be much less usable.

I was genuinely surprised by this, as it's the first (and only!) application
that managed to recognize and adopt to my keyboard layout. Previously, I had
to either setup hotkeys manually (time-consuming) or switch between
colemak/qwerty when chatting/playing (annoying and error-prone).

My question is, how could this be implemented using your keyboard mapping

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

Sounds like a refined version of X11 passive grabs. What happens when an
application requests a hotkey that is already registered at UI level? (Fail
or override?)

The fullscreen-mode-disables-hotkeys touch is great!


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

Can a thief propagate the stolen events back to the receiving event queues?
Is it possible to receive keyboard events without input focus? (I'm thinking
of the following scenario: multi-window application that uses a dedicated
input thread to coordinate input for all windows).

> * 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 like this very much. Very much indeed!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list