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

farblos commented 1 year ago

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 commented 1 year ago

Hi @farblos

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

farblos commented 1 year ago

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:

Start Fvwm, open at least 3 windows
M-Tab to open window list, then M-S-Tab => cycles backward in window list
Release all keys
Scroll Lock => group 2 active
M-Tab to open window list, then M-S-Tab: => cycles forward in window list
Release all keys
Scroll Lock => group 1 active
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 commented 1 year ago

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

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 commented 1 year ago

Hi @farblos

Send a PR for this, please.

farblos commented 1 year ago

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

farblos commented 1 year ago

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.

fvwmorg / fvwm3