Crtl+Alt+M not working in Xorg for flwm & flwm_topside with french keyboard

[nick65go]

I have tested that Ctrl+Alt+M (aka maxim window) works OK with flmw (window manager) for each of Xvesa, Xfbdev and Xorg in pristine form.
I have loaded just kmap in onboot.lst. All good until here.

but because kmap=azerty/fr in bootcode is specific just to Xvesa and Xfbdev, I then used setxkbmap fr in aterm to have french keyboard in Xorg also.
Then tested all the keys from keyboard that the mapping is correct, by using apps like editor, aterm and firefox.

Now all the shortcuts work OK in flwm, like CTRL+ALT+ t/s/v/h/arrows/pageup-down  in flwm. except Crt+Alt+M
I tested ALL the possible combination of crt+alt+keys.

I have the same problem in both core32 and corepure64 with Xorg when I set the keymap fr;
it does not matter if is setup with setxkbmap fr or by using /etc/X11/xorg.cong.d/10-evdev.conf like

# open a terminal and type the following: setxkbmap fr
# My keyboard is in /etc/X11/xorg.conf.d/10-edvev.conf
Section "InputClass"
   Identifier "myKeyboard"
   MatchIsKeyboard "on"
   MatchDevicePath "/dev/input/event3"
   Driver "evdev"
   Option "XkbLayout" "fr"
   #Option "XkbVariant" "latin9"
   Option "XkbModel" "inspiron"
   Option "XkbOptions" "terminate:ctrl_alt_bksp"
   #Option "XkbRules" "xorg"
EndSection

I can manage to use in two steps, like crt+alt+V (vertical) then crtl+alt+H (horizontal) to have the final result as crt+alt+M (maximise), but is a little annoying

extra info for the two switched keys:
with setxkbmap us: key1{ m M}   key2 { ,  ?}
with setxkbmap fr:   key1{ ;   : }   key2 {m M}
it is reversible process, "setxkbmap us" restore the good flwm behaviour and bad Xorg map

bad news: it had the same misbehavior for flwm_topside and crt+alt+M in both core32 and core64pure

[nick65go]

Problem is not solved, yet. Reading the huge Xorg documentation is so time consuming...
But at least I write here some progress (for remembering/log when I do a tinycore search on forum for a solution).

When X server starts, XKB (its keyboard module) reads all needed data from text files (these are the 'database' of the XKB configuration). Strictly speaking most of these files XKB doesn't read itself. It calls xkbcomp to translate these files to a binary form that XKB can understand.

The XKB configuration database consists of 5 components: keycodes, types, compat, symbols, geometry
All these components corespond to subdirectories in directory {XROOT}/lib/X11/xkb
On Linux systems, the evdev rules are most commonly used; I checked with: setxkbmap -query -v 10

"Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc104
layout:     fr
Trying to build keymap using the following components:
keycodes:   evdev+aliases(azerty)
types:      complete
compat:     complete
symbols:    pc+fr+inet(evdev)
geometry:   pc(pc104)
rules:      evdev
model:      pc104
layout:     fr"

So, 'Rules' defines a function (in mathematical meaning) which arguments are 'Model', 'Layout', 'Variant' and 'Options'. <-- see Xorg.conf
And the return value is a vector of components: keycodes, types, compat, symbols and geometry (aka a full keymap).
The Rules files also are placed in the {XKBROOT}/rules directory.

Scancodes (from keyboard controller) are first mapped to keycodes, which are then mapped to keysyms (by XKB) depending on used keyboard layout; Keys without a scancode are not recognized by the kernel;

-A scancode is the lowest identification number for a key, it is the value that a keyboard sends to a computer.
- A keycode is the second level of identification for a key, a keycode corresponds to a function.
- A keysym is the third level of identification for a key, it corresponds to a symbol. It may depend on whether the Shift key or another modifier key was also pressed

I do not think I have a problem with the scan-codes or with the key-symbols (geometry is ignored anyway), because:
The keycodes used by Xorg are reported by a utility called xev; (Note: the keycodes are different for Linux console and Xorg)
- after setxkeybmap us, the prog "xev" shows: keycode 58, keysym 0x6d m, and keysym 0x4d M;
and ctrl+alt+; maximised the window (flwm knows the combination). of course on my french keyboard the key is labeled as [, ?] not [m M] as on a US keyboard
- now, after setxkeybmap fr, the prog "xev" shows: keycode 58, keysym 0x2c comma, and keysym 0x3f question;
So flwm is not using hardcoded keycode 58, otherwise it should worked; hm, next..
keycode 47, keysym 0x6d m, and keysym 0x4d M;

So, the problem should be with the mapping inside the types or compat files.
To get current configuration, I run: xkbcomp $DISPLAY output.xkb
(To upload the data back to the server, run: xkbcomp input.xkb $DISPLAY )
The bits in the state field of keycode (xev shows them) have pre-defined names: Shift, Lock, Control, Mod1, Mod2, Mod3, Mod4 and Mod5, lowest to highest.

Now, back to study; Any help is welcome...

[nick65go]

Updates & Summary until  now:
1. Raw scancode (numeric value, keyboard controller generated, can be 6 bytes long) are assigned to keycode number (like 58)
    This help make keyboard independent of manufacture company maker.
2. Each keycode number is associated to a sane (protocol predifined) symbolic keycode
     (like 58 -> <AC10>, and optional aliassed <AC10> -> <LatM>)
3. Each keycode symbol (ex <AC10>) could have MAX 4 groups of characters
     See group is like a national set of charachers: greek, latic, arabic);
     Not all keycodes have the same number of groups! (ex: Enter key has just one group)
4. For each keycode symbol row in a matrix (ex <AC10> and group1=greek) could be MAX 8 SYMBOLIC modifiers!
    So theoretical one keycode (<AC10> alias <LatM>)can have 4x8 symbols (like; m, M, etc)

The "nice" part is that the 8 SYMBOLIC modifiers are hard coded like: shift, lock, caps, Mod1 - Mod5; <-- for old appls not XKB aware
 The REAL key-buttons (like SHIFT, CAPS, ALT, Win, FN, etc) are grouped in user created VIRTUAL modifiers.
    (like CTRL+ALT=virt1, or ALT+FN=virt2)
 And these virtual modifiers are assigned to SYMBOLIC modifiers. (like virt1 -> Mod2, virt2 -> Mod4)
source at: http://www.charvolant.org/~doug/xkb/html/node3.html

TBC

[curaga]

- you need to change kbd before starting flwm, no use in testing the other case
- why not hook up the flwm source? Some printfs in there should help you get to the bottom of this faster.

[nick65go]

curaga, thanks for the tips. I am not a programmer, but I will do my best for to undestand the source code of flwm.