[RFC] Common input device library

[Bill Spitzak]

Jasper St. Pierre wrote:
> It's because the keyboard is a surprisingly complicated tool with 
> multiple modes of operating, probably without you ever realizing it, and 
> clients need all of that power:
> 
>   If I'm typing text, the *labels* of the keys matter, and input methods 
> allow us to translate sequences of key presses and releases into a 
> Unicode character on the screen.
> 
>   We also have "chords", where holding down a certain key could affect 
> operation. For instance holding the "Shift" key causes the letters typed 
> to be capitalized. However, some users can't accurately hold down a 
> shift key, though, so we have accessibility support like latched keys 
> (press Shift, press "S"), and sticky keys (press Shift, press "S", then 
> press Shift again to turn it off).
> 
>   If I'm playing a game, the *locations* of the keys matter. Games use a 
> WASD scheme not because the letters "W", "A", "S", and "D" mean 
> anything, but because their location on a QWERTY keyboard make a 
> left-handed arrow key shape. On alternate keyboard layouts, we still 
> need them to make that arrow shape, and not give users a layout where 
> going forward means you have to reach half-way across the keyboard.
> 
>   We also have "key shortcuts", which combine both worlds: Ctrl+Z, 
> Ctrl+X, Ctrl+C, and Ctrl+V are all location-based, but Ctrl+F is word-based.
> 
> The typical approach, as done by Windows, OS X, and XKB (and now 
> Wayland) is to send the client an opaque integer that corresponds to "a 
> key", along with a map of how the keys are laid out, and then have the 
> client look up whatever information it needs.

This is not exactly true.

Windows + OS/X send a symbol that is much more like an X "keysym". There 
are no scan codes. The driver has removed the layout information. If a 
client wants key positions they must back-translate the keysym by using 
a different api to determine the hardware and what location on it 
produced each keysym.

And sticky keys and so on are done by the driver. The client can see the 
shift keys being pressed, and perhaps deduce from this the sticky key 
setting, but they don't have to, as the shift flags are set correctly on 
the key event.

All text should go through the input method. This would consume 
keystrokes and may use it's own surfaces (as Chinese input does), and 
occasionally spit out piece of UTF-8 that the client inserts into the 
typed text. The client never looks at key events for this. It looks like 
about 90% of the complexity of XKB is to produce symbols for European 
languages, including dead key compositing. This should all be scrapped 
so that clients are forced to use the input methods.

And you seem to be doing some bikeshedding, such as saying that Ctrl+Z 
is "location based". Yes, that is why the Ctrl+Z combination was chosen. 
However NOBODY types the lower-left key. They type the key with the 'Z' 
on it, or they use an api to change what letter the shortcut is and type 
that letter.