<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: <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> </blockquote> /Xi/exevents.c ll. 197 <blockquote type="cite">/** * 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. */</blockquote> "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) <blockquote type="cite">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.</blockquote> p. 37 <blockquote type="cite">QueryKeymap # keys: LISTofCARD8 This request returns a bit vector for the logical state of the keyboard. [...] </blockquote> HTH, Michael </body> </html>