X Core Protocol Scheme

Michael Titke michael.tiedtke at o2online.de
Mon Dec 14 03:56:12 PST 2015


On 14/12/2015 01:04, Ilya Anfimov wrote:
> On Sun, Dec 13, 2015 at 10:19:59AM +0100, Michael Titke wrote:
>
> Good day!
>
> [skipped]
>
>> When we add the keymap events to the event mask of the window (bit-or
>> cw-keyboard cw-keymap) (BTW it's nice the core specifications containts Lisp
>> like hexidecimal numbers which allows for copy & paste: (define cw-keymap
>> (number->byte-string-4 #x00004000))) we only receive void keymap events but
>> they really do appear for every suppressed enter notification:
>>
>> VSI SCA/X: unhandled event: #"11 0 0 0  16 0 0 0  0 0 0 0  0 0 0 0 0 0 0 0
>> 0 0 0 0  0 0 0 0  0 0 0 0"
>> VSI SCA/X: unhandled event: #"11 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
>> 0 0 0 0  0 0 0 0  0 0 0 0"
>   This  is exactly the behaviour specified in the X11 protocol de-
> scription.
>   Look at KeymapNotify event description (which  you  request  via
> #x00004000 event mask).
>
>   btw,  it  is  not  void  events: first one, in current linux PC,
> should indicate that the Return key is pressed.
>
>   And it is not related to keymaps. There is  MappingNotify  event
> for keymaps, and you cannot request it as it is always reported.
>   (And it is relatively rare event for most  setups,  and  may  be
> even  never will come to your app, however this does not mean you
> can ignore it)
>
>

/Xi/exevents.c ll. 197
> /**
>  * Copy the device->key into master->key and send a mapping notify to the
>  * clients if appropriate.
>  * master->key needs to be allocated by the caller.
>  *
>  * Device is the slave device. If it is attached to a master device, 
> we may
>  * need to send a mapping notify to the client because it causes the MD
>  * to change state.
>  *
>  * Mapping notify needs to be sent in the following cases:
>  *      - different slave device on same master
>  *      - different master
>  *
>  * XXX: They way how the code is we also send a map notify if the 
> slave device
>  * stays the same, but the master changes. This isn't really necessary 
> though.
>  *
>  * XXX: this gives you funny behaviour with the ClientPointer. *When a**
> ** * MappingNotify is sent to the client, the client usually responds 
> with a**
> ** * GetKeyboardMapping. This will retrieve the ClientPointer's keyboard**
> ** * mapping, regardless of which keyboard sent* the last mapping 
> notify request.
>  * So depending on the CP setting, your keyboard may change layout in each
>  * app...
>  *
>  * This code is basically the old SwitchCoreKeyboard.
>  */



"When a MappingNotify [OpCode 34] is sent to the client, the client 
usually responds with a GetKeyboardMapping." <-  It's these phrases that 
would make the protocol.

The mapping notification (34) arrives and is reported by my experimental 
setup (when I switch keyboard layouts) but it didn't get any answer for 
a GetKeyboardMapping request which might be due to shortcomings here or 
there.

Now the following extracts describe another keyboard map which describes 
the state of the keys (pressed or not) where my intention and the above 
comment was about retrieving the mapping between key codes and symbols 
(GetKeyboardMapping) where the actual state of the keys (QueryKeymap) 
isn't relevant.


p.79 (Operation Code 11)
> KeymapNotify
> KeymapNotify
> keys: LISTofCARD8
> The value is a bit vector as described in QueryKeymap. This event is 
> reported to clients selecting
> KeymapState on a window and is generated immediately after every 
> EnterNotify and FocusIn.


p. 37
> QueryKeymap
> #
> keys: LISTofCARD8
> This request returns a bit vector for the logical state of the 
> keyboard. [...]

HTH,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20151214/c0e88d31/attachment.html>


More information about the xorg mailing list