Keystroke flow in X.org

[Jim Gettys]

Peter Hutterer wrote:
> On Fri, Jun 12, 2009 at 05:21:53PM +1000, Timothy S. Nelson wrote:
>> On Fri, 12 Jun 2009, Timothy S. Nelson wrote:
>>
>>> 	So, here's my impression of how it works based on what you've just  
>>> said.
>> [snip]
>>
>> 	Yuck.  Let me do some more reworking.
>>
>> -	When a keystroke comes from the hardware, it gets picked up and sent
>> 	to the client (ie. application/program). -	The application program 
>> (calling on ???) translates it into a
>> 	character using the following process:
>> 	-	Translates from a key/scan code into a symbol using the xmodmap map
>> 	-	The translation table is generated from xkb/*.
>> 	-	The compose/locale stuff happens after the xmodmap translation table.
>>
>> 	Is that better?
> 
> yeah, close enough, except that in most cases xmodmap has little influence
> on anything. I can't remember the last time I used it when it wasn't to
> debug some weird setup from a bugreport. it's something like:
> 
> 1. server starts up, compiles XKB map for each keyboard device based on
>    xkeyboard-config's files using xkbcomp.
> 2. clients query server for the XKB map and store it or use it to spread
>    love and/or happiness.
> 3. key event comes in, driver adds 8 because, hey, why not. also, bonghits.

Because values 0-7 gets used for other purposes; it has to do with 
efforts to save bytes on the wire, and to fit events into 32 byte sizes 
And we (correctly) discovered there was no keyboard in the world with 
more than 248 keys, something still at least approximately true 20 years 
later.

Once upon a time, malloc and free were horribly slow (you can't possibly 
imagine how slow) on some platforms (e.g. VMS).  So there are a number 
of ugly hacks in the protocol encoding (and the Xlib interfaces) to 
avoid having to do malloc/free on every event, which would have been 
prohibitive.  And even on UNIX of the era, malloc/free was a memory pig 
(though later I learned that the Berkeley malloc allocator was 
particularly inefficient if your allocation was size 2^n...).
                     - Jim