M-S-Tab for menu navigation moves menu selection forward when in 2nd XKB group about fvwm3 HOT 6 CLOSED

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

from fvwm3.

Hi @farblos

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

from fvwm3.

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.

from fvwm3.

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 ...

from fvwm3.

Hi @farblos

Send a PR for this, please.

from fvwm3.

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.

from fvwm3.