M-S-Tab for menu navigation moves menu selection forward when in 2nd XKB group

[farblos]

Thanks for reporting your bug here! The following template will help with
giving as much information as possible so that it's easier to diagnose and
fix.

Upfront Information

Please provide the following information by running the command and providing
the output.

• Fvwm3 version (run: fvwm3 --version)

[fvwm3]$ ./fvwm/fvwm3 -version
fvwm3 1.0.7 (1.0.6a-17-g01908e29)
with support for:  XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

fvwm3 comes with NO WARRANTY, to the extent permitted by law. You may
redistribute copies of fvwm under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

• Linux distribution or BSD name/version

[fvwm3]$ cat /etc/debian_version 
11.7

• Platform (run: uname -sp)

[fvwm3]$ uname -sp
Linux unknown

Expected Behaviour

Menu navigation in the window list with M-S-Tab moves menu selection backward regardless of selected keyboard group.

Actual Behaviour

It moves menu selection forward in 2nd keyboard group, and backward in 1st keyboard group.

Enabling logging

Seemingly no relevant logging generated ...

Steps to Reproduce

• How can the problem be reproduced?

Use the following keyboard configuration in /etc/default/keyboard (might be different configuration file on other distros):

XKBMODEL="pc105"
XKBLAYOUT="us,de"
XKBVARIANT=",nodeadkeys"
XKBOPTIONS="grp:sclk_toggle,grp_led:scroll"

BACKSPACE="guess"

Use the following fvwm config (note that due to development version ConfigFvwmDefaults is not active):

AddToFunc StartFunction
+ I ModulePath ${HOME}/work/fvwm3/modules/FvwmMFL
+ I Module FvwmMFL

AddToFunc InitFunction
+ I Exec xterm

Style * NoIcon

Key Tab A M WindowList Root c c SelectOnRelease Alt_L

AddToFunc WindowListFunc
+ I Iconify off
+ I FlipFocus
+ I Raise
+ I WarpToWindow !raise 5p 5p

Silent Key Tab          M A MenuMoveCursor +1
Silent Key Tab          M SM MenuMoveCursor -1

Key F1 A MS Exec xterm

Then try navigating with M-S-Tab in the window list in both keyboard groups us and de.

• Does the problem also happen with Fvwm2?

Not tested.

Does Fvwm3 crash?

No.

Extra Information

The choice of the keyboard group seems to affect only the M-S-Tab binding in menus, not any others. For example, M-S-F1 as defined in the config pops up an XTerm regardless of the current keyboard group.

Setting IgnoreModifiers does not help.

I could try debugging this issue, but for that I'd appreciate any pointers where to start.

[ThomasAdam]

Hi @farblos

Are you switching the keyboard layout between US ans DE at any point as part of this test?

[farblos]

Are you switching the keyboard layout between US ans DE at any point as part of this test?

@ThomasAdam Sorry, forgot to mention that.

Yes, I switch - using the configured toggle Scroll Lock (grp:sclk_toggle).

So more precisely the test case goes like this:

1. Start Fvwm, open at least 3 windows
2. M-Tab to open window list, then M-S-Tab => cycles backward in window list
3. Release all keys
4. Scroll Lock => group 2 active
5. M-Tab to open window list, then M-S-Tab: => cycles forward in window list
6. Release all keys
7. Scroll Lock => group 1 active
8. Repeat at step 2

Plus this does not depend on the language but on the groups: If I make DE group 1 and US group 2, the exact same test case applies.

[farblos]

I modified function _menu_binding_is_key to dump binding modifiers and xkey event state as follows:

        fvwm_debug(__func__,
	   "modifier: %d (%d), state: %d (%d)",
	   b->Modifier, MaskUsedModifiers(b->Modifier),
	   event->xkey.state, MaskUsedModifiers(event->xkey.state));

This results in the following output when a keyboard group (aka. layout) different from the default one is active and when Alt-Tabbing:

[1690037041.095430] _menu_binding_is_key: modifier: 8 (8), state: 8200 (8200)

where 8200 = 0b10000000001000.

Section Xkb State to Core Protocol State Transformation of the "The X Keyboard Extension: Library Specification" says:

Normally, the Xkb-aware server reports keyboard state in the state member of events
such as a KeyPress event and ButtonPress event, encoded as follows:

bits	meaning
15	0
13-14	Group index
8-12	Pointer Buttons
0-7	Modifiers

Accordingly, when I modify MaskUsedModifiers to hide bits 13 and 14 in addition to the unused modifiers:

unsigned int MaskUsedModifiers(unsigned int in_modifiers)
{
	return in_modifiers & ~mods_unused & ~0b11000000000000;
}

the modifiers start to work in the non-default keyboard group as well. IMO the keyboard group could be savely ignored among the modifiers as far as Fvwm is concerned.

I could provide a PR if solving this is not much more difficult than that ...

[ThomasAdam]

Hi @farblos

Send a PR for this, please.

[farblos]

Working on it. In parallel I try to get more information on these mysterious bits in this post on the Xorg ML.

[farblos]

To my question

Is there anything better than just masking out bits 13 and 14 in
event->xkey.state as I have proposed as solution for that issue?
Is there some constant that represents these two bits?

Po Lu replied:

No, the solution is to remove those two bits. This has no negative
consequences, but make sure the bits are restored before the event's
modifier mask is provided to a keycode or keysym translation function.

Since keycode and keysym translation functions are not relevant in this particular use case (comparing modifier bits), I'll keep things simple and will indeed just remove these bits in function MaskUsedModifiers. PR to follow soon.