#12075 NORM 13.1.0: Keyboard layouts not applied in 13.1.0 os1

[Zarro Boogs per Child]

#12075: Keyboard layouts not applied in 13.1.0 os1
---------------------------------------+------------------------------------
           Reporter:  greenfeld        |       Owner:  dsd          
               Type:  defect           |      Status:  assigned     
           Priority:  normal           |   Milestone:  13.1.0       
          Component:  x window system  |     Version:  not specified
         Resolution:                   |    Keywords:               
        Next_action:  review           |    Verified:  0            
Deployment_affected:                   |   Blockedby:               
           Blocking:                   |  
---------------------------------------+------------------------------------
Changes (by dsd):

 * cc: pgf (added)
  * next_action:  diagnose => review


Comment:

 When GTK+ receives a key event it uses XGetKeyboardMapping() to figure out
 how to map a keycode into a keysym - which is effectively the application
 of the keymap. I presume other UI toolkits are similar.

 I haven't traced this right down to the roots, but I've gone far enough to
 draw a confident conclusion:

 ProcGetKeyboardMapping() calls PickKeyboard(client) in order to base its
 work on.

 PickKeyboard() finds the mouse pointer for the client window and then
 tries to find the master keyboard that it is linked with.  In this
 situation we always find the virtual core pointer as the pointer, and the
 virtual core keyboard as the keyboard (with or without kbdshim).

 However, what does get exposed in this codepath is that the kbdshim uinput
 input device is regarded as a slave of the virtual core pointer. And I
 guess the code that sees that we want to apply a key map is written to
 avoid applying a key map to a pointer device.

 Modifying kbdshim to expose separate uinput devices for keyboard/mouse has
 the intended effect: the kbdshim mouse becomes a slave of the core
 pointer, the kbdshim keyboard becomes a slave of the core keyboard, and
 udev-driven keyboard mappings take effect (solving this bug) - they must
 now be filtering correctly down to the core keyboard device.

 Attaching a patch for kbdshim which is needed to fix this (in addition to
 the olpc-session and udev changes mentioned above).

-- 
Ticket URL: <http://dev.laptop.org/ticket/12075#comment:4>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system