Input hotplug issue : Handling the first key from new device

[Peter Hutterer]

On Fri, Feb 20, 2009 at 08:09:22PM -0800, Henry Zhao wrote:
> In a system with multiple input keyboard devices, mapping table switch  
> takes place when server receives the first keystroke from a new device.  
> At that time the server does the followig (in that sequence):
>
> * updating mapping tables to the new device
> * sending MappingNotify to clients
> * Processing the key event
>
> On receiving MappingNotify, a client usually does a new grab in  
> accordance with the new mapping table. However, server creates a grab  
> for it AFTER it processed the key event, therefore the key event is  
> incorrectly delivered. In my testing case, the client grabs a keysym only 
> defined in the new device. When the first key that happens to correspond  
> to that keysym is hit from the new device, the client does a grab, but  
> the grab is not there when server processes the event, so the client  
> misses it (although the client is able to correctly catch subsequent keys 
> from the new device).
>
> I tried something, including deferring processing key event for several  
> dispatch loops, or having driver send a dummy keycode (with an extra  
> select) for mapping table updates only, but all in vein.
>
> Is it an architectural issue ?  Any solutions ?

this race condition exists in older servers too. if client A changes the
keyboard mapping, a key event may occur before client B has updated its grabs.
This is more obvious now as it will always happen, but it's nothing new.

There isn't much we can do other than switch the server to keysym grabs rather
than keycode grabs, but we're a few moons away from that and IIRC there's some
nasty details that need to be well-tested. patches appreciated of course.

Cheers,
  Peter