dinput2

[Scott Ritchie]

On 05/21/2010 06:16 AM, Paul "TBBle" Hampson wrote:
> (Resending, on-list. Thanks, Gmail, apologies to Scott >_<)
> 
> On 21 May 2010 14:29, Scott Ritchie <scott at open-vote.org> wrote:
>> By the way, you're not the only one who wants this.  At the Ubuntu
>> Developer Summit we talked about the need for ripping the keyboard code
>> out of X entirely (and instead having it sit somewhere in the plumbing
>> lair).
> 
>> I'll admit I'm not too familiar with the details about why this is a
>> good idea, but I believe it had something to do with keyboard layout
>> issues for International users, especially in East Asia.
> 
> Is there any particular documentation of this discussion or intention?
> I'm interested in the area, but I'm not clear on what's actually being
> discussed, change-wise.
> 

We didn't create a wiki page yet, but here are some copy/pasted Gobby
notes taken during the session:

-----
Current Situation:
BIOS keyboard driver from boot to X
 - kernel replaces that with input drivers (can remap etc)
   - same drivers that X uses
 - atkbd translates scancodes to keycodes, X translates to key sequences
 - X starts up, uses /dev/input devices
 - on console currently have no way of differentiating keyboard

current X implementations: XKB (European) and XIM (Asian) compete with
eachother
 - If you have a key on your keyboard to switch between US mode and
"input mode" that can input other keys then we don't handle this well
 - A keyboard layout other than US English will leave you screwed if
you're on an asian language
   - X sees keycodes rather than scancodes here
 - On X key swapping is done with the unique identifiers rather than
scan codes
   - but the intermediate layer with unique key ids is not exposed
   - input method engine does not see intermediate layer
     - we need to know underlying layer as well
   - Thai problem: keyboard with a key to switch between US English and
Thai layout
     - We have no indicator for what layout you're in, so Thai users
tend to use only 0-9 for passwords because those characters are
consistant between these two layouts
 - xkb doesn't support mapping one key to multiple unicode codepoints
(such as for keys that actually generate two unicode characters)

Solution: rip out the mess in X, put everything in IBUS instead.
 - User Session IBus daemon running, X talks to it
 - xkeyboardconfig would need to be merged into IBUS
 - X would be happy to remove keyboard stuff so they can focus on Video
instead
   - need someone to focus on the new bugs introduced by this change
 - Long term we will probably always have a display server (kernel will
take video responsibility, remove VT layer)
 - udev keyboard config magic should be moved out (into device tree or
uinput)
 - talk to xkeyboardconfig upstream and may be willing to help maintain it
 - Send Arne and Chris to X Conference and plead to the audience for
someone to do this
   - Arne to gather help and get the facts right and prepare presentation
     - Chris to help Arne
     - Scott James Remnant to clarify how plumbing gets keycodes to X

-----
If you have any questions you can ask ArneGoetje on Freenode (or mail
him, here's his launchpad page: https://launchpad.net/~arnegoetje)

This is the kind of thing that should exist as a wiki page somewhere, so
feel free to get started on one.  I hope that helps, I'm not too
knowledgeable on the subject myself.

Thanks,
Scott Ritchie