[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: X Core Protocol Scheme
From: Michael Titke <michael.tiedtke () o2online ! de>
Date: 2015-12-14 11:56:12
Message-ID: 566EAE5C.50507 () o2online ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 14/12/2015 01:04, Ilya Anfimov wrote:<br>
<blockquote cite="mid:20151214000422.GA66740@azor.tzirechnoy.ru"
type="cite">
<pre wrap="">On Sun, Dec 13, 2015 at 10:19:59AM +0100, Michael Titke wrote:
Good day!
[skipped]
</pre>
<blockquote type="cite">
<pre wrap="">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"
</pre>
</blockquote>
<pre wrap="">
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)
</pre>
<br>
</blockquote>
<br>
/Xi/exevents.c ll. 197<br>
<blockquote type="cite">/**<br>
* Copy the device->key into master->key and send a mapping
notify to the<br>
* clients if appropriate.<br>
* master->key needs to be allocated by the caller.<br>
*<br>
* Device is the slave device. If it is attached to a master
device, we may<br>
* need to send a mapping notify to the client because it causes
the MD<br>
* to change state.<br>
*<br>
* Mapping notify needs to be sent in the following cases:<br>
* - different slave device on same master<br>
* - different master<br>
*<br>
* XXX: They way how the code is we also send a map notify if the
slave device<br>
* stays the same, but the master changes. This isn't really
necessary though.<br>
*<br>
* XXX: this gives you funny behaviour with the ClientPointer. <b>When
a</b><b><br>
</b><b>
* MappingNotify is sent to the client, the client usually
responds with a</b><b><br>
</b><b>
* GetKeyboardMapping. This will retrieve the ClientPointer's
keyboard</b><b><br>
</b><b>
* mapping, regardless of which keyboard sent</b> the last
mapping notify request.<br>
* So depending on the CP setting, your keyboard may change layout
in each<br>
* app...<br>
*<br>
* This code is basically the old SwitchCoreKeyboard.<br>
*/</blockquote>
<br>
<br>
<br>
"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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
p.79 (Operation Code 11)<br>
<blockquote type="cite">KeymapNotify<br>
KeymapNotify<br>
keys: LISTofCARD8<br>
The value is a bit vector as described in QueryKeymap. This event
is reported to clients selecting<br>
KeymapState on a window and is generated immediately after every
EnterNotify and FocusIn.</blockquote>
<br>
<br>
p. 37<br>
<blockquote type="cite">QueryKeymap<br>
#<br>
keys: LISTofCARD8<br>
This request returns a bit vector for the logical state of the
keyboard. [...]<br>
</blockquote>
<br>
HTH,<br>
Michael<br>
</body>
</html>
[Attachment #6 (text/plain)]
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic