On Tue, Sep 17, 2019 at 5:54 PM Nick Couchman <[email protected]> wrote:
> On Tue, Sep 17, 2019 at 3:30 AM Lesley Persyn <[email protected]> > wrote: > >> Hi all, >> >> With US keyboard systems no problem. But with "Belgium Dutch keyboard" >> (point, not french) still an issue. (if i don't select a keyboard and set >> the remote server to US then it works fine but this should work seamlessly >> and i need the keymap) >> >> What are the best practices to create a .keymap file? How to read out the >> keyboard keys? >> >> I can do it myself but cannot find where to start. (i don't see any logic >> with the 0x29,... mappings) >> > > So, first big disclaimer that I've never actually written a keymap before, > so I'm kind of venturing out here on a limb and telling you what I *think* > should work. > > To answer your first question, how to read out the keyboard keys, get the > "xev" program on a Linux system and launch it, and then press the keys - > you'll see output like this: > > KeyPress event, serial 37, synthetic NO, window 0x6000001, > root 0xd3, subw 0x0, time 610952169, (94,73), root:(688,379), > state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES, > XLookupString gives 1 bytes: (31) "1" > XmbLookupString gives 1 bytes: (31) "1" > XFilterEvent returns: False > > KeyRelease event, serial 37, synthetic NO, window 0x6000001, > root 0xd3, subw 0x0, time 610952264, (94,73), root:(688,379), > state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES, > XLookupString gives 1 bytes: (31) "1" > XFilterEvent returns: False > > This shows a key press and key release for the "1" key, which is keysym > 0x31. The en_us_qwerty.keymap file has this line: > > map -shift 0x29 0x02..0x0D ~ "`1234567890-=" > > So, based on my read of this, and experimentation with xev, my guess is > that the 0x29 is somehow the base of all of those keys on that line, and > the "0x02..0x0D" is the range of values that are added or masked onto that > base to get the actual value. However, this theory is not working out on > my keyboard - things are slightly off - so I may be getting that wrong. > Someone else can probably help on that, or maybe it'll at least set you in > the right direction. > I can clarify a bit on the format of the .keymap files. I'll be using the German keymap as an example, but all RDP keymaps for Guacamole follow this format. There are 5 types of lines that you will find: 1. A comment (any line starting with "#"): https://github.com/apache/guacamole-server/blob/b181026e589d396b498de56747ab8a489b34647b/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L25 2. The name of the keymap that the current keymap should inherit from (most will say "base" here, a reference to the "base.keymap" file). This line starts with "parent" and allows keymaps to avoid repeating common key definitions. https://github.com/apache/guacamole-server/blob/b181026e589d396b498de56747ab8a489b34647b/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L20 3. The name of the keymap. This line starts with "name" and dictates what the value of the "server-layout" connection parameter will need to be set to. This value also dictates what other keymaps will specify for "parent" if they wish to inherit from your keymap. https://github.com/apache/guacamole-server/blob/b181026e589d396b498de56747ab8a489b34647b/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L21 4. The name of the FreeRDP keyboard layout constant for the keyboard layout that your keymap defines. The value specified here will be sent to the RDP server during session negotiation. These are dictated by Windows / the RDP protocol, and the FreeRDP library defines some constants for these. This line starts with "freerdp". https://github.com/apache/guacamole-server/blob/b181026e589d396b498de56747ab8a489b34647b/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L22 5. A Windows scancode <--> X11 keysym mapping. These lines are the more complex lines which start with "map": https://github.com/apache/guacamole-server/blob/b181026e589d396b498de56747ab8a489b34647b/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L31 The important thing to keep in mind with the scancode/keysym mapping is the inherent difference between scancodes and keysyms - the whole reason these keymaps exist at all. Guacamole uses X11 keysyms for key events as these are independent of keyboard layout and define key identity. The keysym for an uppercase "A" is always the same, regardless of where that key is located, whether Shift or AltGr are held down, etc. Windows scancodes, on the other hand, deal more with key location. While a keysym may mean "A", a scancode has meaning more like "the second key from the left in the second row". They have no meaning on their own until the keyboard layout is known, and even then may depend on whether certain modifier keys are active. With the above in mind, each "map" line tells Guacamole how exactly to produce the effect of a particular key through sending Windows scancodes. Since the keyboard layout of the client machine will not necessarily match that of the server, these instructions include whether some modifiers are required for those keys to map as listed, and whether some modifiers must NOT be active for those keys to map as listed. The format of each "map" line is as follows: map [OPTIONAL MODIFIER REQUIREMENTS] [SCANCODE LIST] ~ [KEYSYMS] Dissecting the line I linked to above: map -altgr -shift 0x56 0x2C..0x35 ~ "<yxcvbnm,.-" this line says that the following keysyms map to the following scancodes: "<": 0x56 "y": 0x2C "x": 0x2D "c": 0x2E "v": 0x2F "b": 0x30 "n": 0x31 "m": 0x32 ",": 0x33 ".": 0x34 "-": 0x45 and that the "altgr" and "shift" modifiers must NOT be active (Guacamole will automatically send the key events and scancodes to release these keys prior to sending the required scancodes to press any of the above). The two dots between "0x2C" and "0x35" are just a shorthand notation supported by the keymap files which avoid needing to list each scancode, as scancodes of adjacent keys tend to be one apart. The "<yxcvbnm,.-" format is also a convenience provided by the keymap format. X11 keysyms are numeric by nature, but there is also a direct mapping from Unicode to keysyms. If the keysym you are mapping has an associated Unicode character, representing the key using that character in the keymap is more readable. You will see numeric values specified for keys which are not printable, such as "Ctrl" within the base keymap, or dead keys: https://github.com/apache/guacamole-server/blob/b181026e589d396b498de56747ab8a489b34647b/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L60 - Mike
