Windows + Y shortcut doesn't work

changed the description

I can confirm that the shortcut Super + Y is not properly loaded on a fresh boot + auto login.

Debugging the code shows that libxfce4ui tries to bind keycode 29 which is the J key (Colemak keyboard layout). On the physical keyboard it shares the position with the Y key (US layout).

Hi. I am unable to reproduce this issue. Super+Y appears to work correctly after binding it to an application shortcut and after a machine reboot.

Can you please send a description of the steps for reproducing this issue?
Is it reproducible with the English(US) layout?
Is it reproducible after you run setxkbmap without any arguments?

$ localectl status
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us-acentos
      X11 Layout: us
       X11 Model: pc105
     X11 Variant: colemak

The Colemak keyboard layout is set via xfce4-keyboard-settings (Layout: English (US), Variant: English (Colemak)).

I only noticed the bug when doing a fresh boot which skips the LightDM login screen (auto login). Running setxkbmap without any arguments does not seem to have any effect.

Note that, Super + J is being consumed, so it does not generate a J character in a terminal window or text editor, but no action is associated with that shortcut.

Reverting 85d8d390 fixes the problem.

@atomsymbol: Mind testing this along with the changes in your commit?

moved from xfce4-settings#253 (moved)

added 1. Regression label

@lastonestanding I don't understand how it has been arrived at the conclusion that reverting 85d8d390 fixes the issue. With Colemak set as the 1st keyboard layout in the list of layouts in XFCE settings, Super+Y does not work (and Super+O works instead) irrespective of whether 85d8d390 alone is reverted or not reverted.

Do you mean exactly the following command:

git checkout 85d8d390f9f2265613da4291992523937a7a2519~1 -- xfce-shortcuts-grabber.c

or some other command?

Moving Coleman to the 2nd position in the list of layouts makes Super+Y trigger the action, moving it back to 1st position makes Super+O trigger the action. In both cases, typing y in a terminal window prints y.

I tested with git master -> bug present, then I reverted the mentioned commit -> bug gone.

The steps to reproduce the bug are mentioned in my comment above. My guess is that there is some timing issue which is now exposed by libxfce4ui and its recent change to "avoid redundant key re-grabbing".

My guess is that there is some timing issue ...

There is no signal being received by xfce_shortcuts_grabber_keys_changed() when the keyboard layout changes.

closed

Solved it the following way: I hadn't the issue when I started xfce4-session within an own .xinitrc (having a setxkbmap command to set the keyboard layout) via startx. I had the issue only when I started Xfce via startxfce4. So I close this. Thanks for your comments.

The report is still valid and we need to fix the issue in libxfce4ui and/or xfce4-settings.

I registered to report this bug with Windows + "+" not working in a new session until reassignment. I'm pretty sure it is the same bug.

Edit: on a german keyboard Edit2: also Super + "#"

reopened

Here (Xfce4 16.0 on Slackware64-current) it's the same error with German keyboard layout and Ctrl+Shift+2 which translates to

property name="<Primary><Shift>quotedbl"

The shortcuts works as long as I don't close the session. Signing off and starting Xfce4 again (with startx) and the shortcut is nonfunctional.

It works with its neighbours flawlessly though, so both the following shortcuts work even after signing off and in again.

property name="<Primary><Shift>section"

property name="<Primary><Shift>exclam"

I am working on a patch for this issue. So far, I have determined that the problematic piece of code might be:

XkbGroupForCoreState (xevent->xkey.state)

Watching for XkbStateNotify events and getting state.group from there appears to be the correct way of obtaining the group.

Question: After selecting per-window layout management (instead of globally) in xfce4-xkb-plugin, in my patched libxfce4ui the shortcut matched by xfsettingsd depends on the keyboard layout of the current window. Is that OK? (In my opinion, it is OK.)

Question: After selecting per-window layout management (instead of globally) in xfce4-xkb-plugin, in my patched libxfce4ui the shortcut matched by xfsettingsd depends on the keyboard layout of the current window. Is that OK? (In my opinion, it is OK.)

There were some typos in my question. Sorry about that.

mentioned in merge request !27 (merged)

Please test the following merge request: !27 (merged)

For me the issue is unfortunately the same even with the patch applied (only testet with Ctrl+Shift+doublequote).

For me the issue is unfortunately the same even with the patch applied (only tested with Ctrl+Shift+doublequote).

Do you happen to have German layout set as the first keyboard layout in keyboard layout list in Xfce keyboard settings? If so, please run the following test:

Logout from Xfce and then start Xfce
Open a terminal window
Press Shift+2 on the keyboard. This prints @ in the terminal, but it should print a double-quote because the layout displayed by xfce4-xkb-plugin is "DE" after Xfce starts.

Another test:

Logout from Xfce and then start Xfce
Switch from DE layout to another layout (such as: EN)
Switch from EN back to DE
Press Ctrl+Shift+2 on the keyboard. I expect that this will (correctly) trigger the action associated with Ctrl+Shift+doublequote on your machine, assuming you have applied the patch from !27 (merged).

Yes, German keyboard, set via a rule in /etc/X11/xorg.d. I didn't touch the keyboard settings in Xfce4 in another way before besides assigning shortcuts. The first test gives me a " (double-quote) in the terminal. The second test is not successful though - I still get my Ctrl+Shift+doublequote shortcut doing nothing :-(

The second test is not successful though - I still get my Ctrl+Shift+doublequote shortcut doing nothing :-(

Because it seems you aren't using Xfce to switch the layout, which Linux command are you using to perform a layout switch such as DE->EN or EN->DE?

I would change /etc/X11/xorg.conf.d/90-keyboard-layout-evdev.conf to read Section "InputClass" Identifier "keyboard-all" MatchIsKeyboard "on" MatchDevicePath "/dev/input/event*" Driver "evdev" Option "XkbLayout" "de" #Option "XkbVariant" "" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection But when I added Danish keyobard layout in Xfce, removed the German keyboard and restarted Xfce I had (in a terminal) the Danish layout. Doing the same change again to switch back to German layout restored the old behaviour, unfortunately with my shortcut not picked up by Xfce.

I nearly never have to change the layout. In the past I used a plugin for Xfce (to switch to Danish) but I don't have much use for that the last year. After a new setup I didn't install the plugin. Do I need the plugin so that the patch can work its magic? :-)

If there is something different I should try (like changing the xorg setting to English and back to German) just drop a line.

I installed the xfce4-xkb-plugin 0.8.2, added it to the panel and changed my /etc/X11/xorg.conf.d/90-keyboard-layout-evdev.conf (Option "XkbLayout" "de,en,dk"), then finally restarted Xfce. I changed the Xfce keyboard settings to respect the system keyboard settings and to be on the safe side I logged out and in again.

The change was surprising. The shortcut didn't work, but so did the xkb plugin. I could switch to "en" layout, but not to "de" or "dk". I guess I should maybe file a bug report there, depending on what solution this thread may result in. scratching head

Next thing I will try is to create a new user and see if it's a Xfce configuration problem on my side.

It's the same for a new user with no existing Xfce configuration.

In summary, according to the discussion and tests so far, there appear to be at least 3 more-or-less separate keyboard layout issues:

xfsettingsd isn't receiving Xfce's keyboard layout change signals (fix: !27 (merged))
After Xfce start: xfsettingsd, or maybe xfconfd, isn't setting keyboard layout according to the 1st item in Xfce's keyboard layout list
Xfce does not know how to properly handle keyboard layouts setup by apps/tools outside of Xfce, including keyboard layouts specified in /etc/X11

The fix works for me (see my test case above). Pressing the mentioned keyboard shortcut now runs the assigned command.

I tried one more time because I noticed I had made an error. The xorg setting "de,en,dk" should read "de,en_US,dk". With that change the panel plugin can change between the three keyboard layouts. The shortcut is still not working though, no matter what I do or if I quit Xfce and start it again.

Hi,

Just reporting that the issue doesn't seem to be resolved with !27 (merged) : several shortcuts fail on a new login, until set again.

In my case, I've got the following in xorg.conf.

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "fr,fr"
        Option "XkbVariant" "bepo,azerty"
	Option "XKbOptions" "shift:both_capslock,ctrl:nocaps,grp:ctrls_toggle,terminate:ctrl_alt_bksp"
EndSection

I'd be happy to provide whatever details might help.

Hi. Can you be more specific so that I can reproduce your conditions on my machine?

Some examples of shortcuts that do not work on a new login
What does "until set again" mean?
- Remove-then-add the shortcut in the "Application shortcuts" tab in Xfce keyboard settings?
Do you have a $HOME/.Xmodmap file?
Which Linux distribution are you using (so that I can install it in VirtualBox)?

I use arch linux. Shortcuts that fail include Windows + b, Windows + o, Windows + é, Windows + e. Some do work, such as Windows + j.

Yes, setting them again means setting another key in "Application shortcuts", then switching back to the original key binding.

I start xfce4 with exec startxfce4, and I don't have a .Xmodmap file.

I'll try turning what knobs I can find, see if it changes anything.

I confirm that I am able to reproduce Windows+e not working after startxfce4 with BÉPO layout in Arch Linux + !27 (merged).

BTW: I don't know how to type < in BÉPO on a physically US keyboard. I am able to type « or 2 only.

I have determined the cause of the problem. It will take some time to prepare a patch that meets the performance target. (It would be somewhat easier to implement it in C++ - in C it is more complicated.)

Changing the layout and back from Xfce keyboard settings make most bindings work, but breaks Windows + q, which is set to Close Window in Window Manager. Some other bindings in Window Manager are unaffected.

Some other weird behaviour, probably an unrelated bug, : Windows + < fails, unless quickly preceded by Windows + ". I use those to change workspaces.

I built your branch using the libxfce4ui-git package from aur where I set source=("git+https://gitlab.xfce.org/atomsymbol/libxfce4ui.git#branch=shortcuts")

@atomsymbol

I've tested your new branch. I seem to be hitting some weird interaction with the xfwm4 package.

xfwm4 4.14.0 :: everything works fine.
xfwm4 4.16.1-1 :: key bindings fail still. And Windows + Q fails also (it worked before. It is set to close window from the window manager settings).

To compare, with libxfce4ui 4.16.0-1 (from the arch repository)

xfwm4 4.14.0 :: key bindings fail
xfwm4 4.16.1-1 :: key bindings fail + one additional issue (*)

(*) is the weird issue I described with Windows + < to switch workspaces. On this issue, what I wrote Windows + < should instead be Windows + « on the default BÉPO layout (I've manually edited /usr/share/X11/xkb/symbols/fr to swap < and «), so on the default BÉPO layout, the issue might be that the Windows + « binding fails unless quickly preceded by Windows + ". Both bindings are set in window manager settings.

Unless I'm doing something wrong, this may indicate an issue with xfwm4. In fact, the issue (*) originally appeared with an xfwm4 update, which is why I've kept the version 4.14 around.

@sebmiq Can you please add -DDEBUG_TRACE to libxfce4ui CFLAGS and post a complete xfsettingsd log for a failed key binding?

xfsettingsd --no-daemon --replace |& tee xfsettingsd.log

@sebmiq A feature that was removed when going from 4.14 to 4.16 is support for multiple screens in the libxfce4ui code. However, I haven't encountered any issue while shortly testing multiple displays (Xubuntu 4.16 in Virtualbox).

I do not use multiple displays.

I am not sure that I set the CFLAGS correctly. I have only added export CFLAGS="-DDEBUG_TRACE" to the pkgbuild.

Running XFSETTINGSD_DEBUG=1 xfsettingsd --no-daemon --replace make most bindings work again, so I cannot log a failed key binding. Sometimes the bindings from the window manager do not work. Sometimes everything works.

When everything works, it reports the following (keycodes 58 and 11 are q and « (<),which are my problematic window manager bindings).

(xfsettingsd:30507): libxfce4kbd-private-WARNING **: 15:50:18.334: Failed to grab keycode 58
(xfsettingsd:30507): libxfce4kbd-private-WARNING **: 15:50:18.340: Failed to grab keycode 11
(xfsettingsd:30507): libxfce4kbd-private-WARNING **: 15:50:18.367: Failed to grab keycode 11
(xfsettingsd:30507): libxfce4kbd-private-WARNING **: 15:50:18.368: Failed to grab keycode 58

When the bindings from wm do not work it reports lines such as the following (keycodes 24, 27 are some of my bindings, they do work nonetheless)

(xfsettingsd:31391): libxfce4kbd-private-WARNING **: 15:52:00.076: Failed to grab keycode 27
(xfsettingsd:31391): libxfce4kbd-private-WARNING **: 15:52:00.079: Failed to grab keycode 24

Here are debug logs : https://pastebin.com/Gu5qDVHt

@sebmiq Merge request !27 (merged) has been updated with patch "Filter grabbing by key group". It is probable that <Super>b was preventing <Super>q from working because B and Q are physically the same key on the keyboard in US and BÉPO layouts.

The latest patch fixes my issues with Windows + q and Windows + <.

At this point, manually restarting xfsettingsd makes all my bindings work. xfsettingsd no longers complains about keycodes 58 and 11. It does randomly complain about others though which correspond to my Windows + b/é/o bindings that still do not work on a fresh login.

closed with commit b50af342

closed with commit 0d4e6ad6

closed with commit d4445323

Thank you!

mentioned in issue xfconf#22 (closed)

mentioned in issue xfce4-settings#317 (closed)

mentioned in issue xfce4-settings#349 (closed)

Windows + Y shortcut doesn't work

Designs

Child items ...

Activity