Created attachment 9800 Proposed patch Hi, In FreeBSD a bug has been reported with XFCE wrongly managing keyboard shortcuts [1]. The problem has been identified as xfce-shortcuts-grabber.c, when renewing grabbed keys on keyboard change wrongly ungrabbing the new key instead of the old one. A fellow FreeBSD committer sent a patch which teaches xfce-shortcuts-grabber.c to remember old keys and ungrab them correctly. His original submission (which is what we are using in our ports tree at present) can be viewed here [2] On his suggestion I slightly cleaned up his patch and am posting it here. I'd like to have it included in the official tree, and will listen for any suggestions to make it better. The patch uses a fixed buffer with size 8 for old keys, to keep the patch simple, avoiding the complications of memory allocation/deallocation. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244290 [2] https://reviews.freebsd.org/D24338
FYI, I searched XFCE bugzilla a bit earlier and I think it is possible some of these bugs may be related: https://bugzilla.xfce.org/show_bug.cgi?id=14226 https://bugzilla.xfce.org/show_bug.cgi?id=8533 https://bugzilla.xfce.org/show_bug.cgi?id=9721 https://bugzilla.xfce.org/show_bug.cgi?id=14859
I took advantage of the new gitlab setup and created a merge request for this issue: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/1
thanks for the patch and merge request! Do you have a simple way this behavior can be reproduced? (I so far never experienced problems with it - plus I'm not deeply familiar with the shortcuts-grabber code [same may hold true for all other active project members]) For how long have you been shipping this patch in FreeBSD?
(In reply to Simon Steinbeiss from comment #3) > thanks for the patch and merge request! > > Do you have a simple way this behavior can be reproduced? (I so far never > experienced problems with it - plus I'm not deeply familiar with the > shortcuts-grabber code [same may hold true for all other active project > members]) I have not been experiencing this bug myself and now running the patched code. Anyway the bug is described in the related FreeBSD ports bug report here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244290 especially comment 18 there. It is also explained in the code review for the patch here: https://reviews.freebsd.org/D24338 > > For how long have you been shipping this patch in FreeBSD? Comment 24 (automatically generated on commit) has a timestamp of Sun Apr 12 20:23:56 UTC 2020, so that's when I first committed it to the head branch of the ports tree. The commit was also merged to the "quarterly" branch shortly later at Sun Apr 12 20:47:19 UTC 2020, so by a few days at most after that all FreeBSD users updating their ports/packages are using the patched version.
I don't know what combination of factors was necessary to reproduce the issue, but I was one of the folks who encountered this in FreeBSD. The way I start XFCE is a little different from most Linux distributions with a DM nowadays; I login at console, then run startx. My xinitrc has a xmodmap invocation to set up Super_L as a Multi_key and F1 as Escape (I use vim). After that, xinitrc execs /usr/local/bin/startxfce4. The latter is no different from any other FreeBSD user, probably? Guido may be able to speak to that. I don't know if any of this is relevant and don't know much about X startup or X applications myself. My keyboard is a bog-standard 87-key (no numpad) US QWERTY keyboard, my $LANG is boring en_US.UTF-8. I don't know what causes the keycode mappings to change shortly after starting X, but that's probably essential to reproducing it. Thanks!
I also suffer from this problem. I can't use the up arrow key any more.. :( Not in the terminal, browser, text editor or any other application. Too bad..
(In reply to Melroy from comment #6) > I also suffer from this problem. I can't use the up arrow key any more.. :( > Not in the terminal, browser, text editor or any other application. Too bad.. Hi, Thanks for your report, could you please give some more information? Which operating system are you using? (FreeBSD or Linux?) Could you also describe how this problem started to appear? Are you able to try the patch I posted?
Hey Guido! I'm using Linux (Ubuntu 20) which is shipped with XFCE v4.14 by default. I'm maybe not able to solve it. But I', able to give you a full reproduction scenario by using a Docker! Check it out yourself if you are able to run docker images and install any Spice Client (like the remote-viewer command, install the virt-viewer package). 1. First pull the image: docker pull danger89/xfcevdi:2.0 2. Start the container: docker run --shm-size 2g -it -p 5900:5900 -p 8080:8080 -p 5959:5959 danger89/xfcevdi:2.0 3. Open connect via Spice client like: remote-viewer spice://localhost:5900 4. Enter the password, which is: "password" (very secure :P) 5. You are in! More info check-out: https://hub.docker.com/r/danger89/xfcevdi And sources: https://github.com/danger89/XFCEVDI Note: You have sudo rights within this docker container, you can install whatever you like. For example xed or something. You will notice that all arrows key work, except the up arrow key.
(In reply to Melroy from comment #8) > Hey Guido! > > I'm using Linux (Ubuntu 20) which is shipped with XFCE v4.14 by default. > > I'm maybe not able to solve it. But I', able to give you a full reproduction > scenario by using a Docker! > > Check it out yourself if you are able to run docker images and install any > Spice Client (like the remote-viewer command, install the virt-viewer > package). > > > 1. First pull the image: docker pull danger89/xfcevdi:2.0 > 2. Start the container: docker run --shm-size 2g -it -p 5900:5900 -p > 8080:8080 -p 5959:5959 danger89/xfcevdi:2.0 > 3. Open connect via Spice client like: remote-viewer spice://localhost:5900 > 4. Enter the password, which is: "password" (very secure :P) > 5. You are in! > > > More info check-out: > https://hub.docker.com/r/danger89/xfcevdi > > And sources: > https://github.com/danger89/XFCEVDI > > Note: You have sudo rights within this docker container, you can install > whatever you like. For example xed or something. You will notice that all > arrows key work, except the up arrow key. Ow yea, connecting to http://localhost:8080 and login enter the pass "password" again, will do as well. Which is a SPICE HTML5 client.
(In reply to Melroy from comment #8) > Note: You have sudo rights within this docker container, you can install > whatever you like. For example xed or something. That was maybe a stupid call, xed is Linux Mint -,-. However, with docker image danger89/XFCEVDI v3 you have Mousepad installed by default! docker pull danger89/xfcevdi:3.0
We promote the usage of schuellerf/xfce-test from dockerhub. It is based on Xephyr and allows you to start the session with startx as well. For more information on how to use xfce-test continue with the readme: https://github.com/schuellerf/xfce-test
(In reply to Simon Steinbeiss from comment #11) > We promote the usage of schuellerf/xfce-test from dockerhub. > > It is based on Xephyr and allows you to start the session with startx as > well. > > For more information on how to use xfce-test continue with the readme: > https://github.com/schuellerf/xfce-test Thanks for the link! Looks interesting. Yet Ubuntu 20 with my setup together with XFCE 4.14 should also work, and they ask for more details. So I got a reproduction scenario of this bug report, I hope?
Created attachment 9866 Key pressed overserved by xev When running the xev command, I pressed Down, Up, Left, Right arrow-keys. Looks like the up key isn't connect to a key event (nor press nor release), instead I see FocusOut and FocusIn with KeymapNotify events?
(In reply to Melroy from comment #13) > Created attachment 9866 > Key pressed overserved by xev > > When running the xev command, I pressed Down, Up, Left, Right arrow-keys. > Looks like the up key isn't connect to a key event (nor press nor release), > instead I see FocusOut and FocusIn with KeymapNotify events? observed* . I think something is wrong with the key binding in XFCE.
@Melroy: I'm not confident your problem is the same as the one that Guido and Conrad describe. In your case it seem to be about a dysfunctional "up" button, whereas in their case multiple keyboard shortcut mappings (potentially) change. @Guido/Conrad: Can you help to clarify? Ideally if you can reproduce your scenario with xfce-test that would really help a lot!
@Simon, the button that I had remapping issues with was also 'Up.' Unfortunately I cannot run xfce-test as Docker does not run on FreeBSD.
Hi @Simon, The bug is more generic than just breaking the Up arrow, but the Up arrow is the most noticable symptom. You can simulate the Up arrow situation that shows the cleanup problem by starting XFCE and running something like this: ``` # enable default XFCE keyboard shortcuts in Settings > Keyboard > Application Shortcuts > Reset to Defaults # set 'Up' to 'Print' like in the intial keymap for some people (for some reason) xmodmap -e "keysym Up = Print" # pressing Up should now launch xfce screen grabber # this is the wrong keymap! reset to something sane (not sure what triggers this correction for people with the problem, but it seems to happen automatically on first keypress) setxkbmap -model pc105 # or whatever your default was # pressing Up should no longer launch xfce screen grabber # but it also will not send Up to your terminal or any other application, because XFCE didn't ungrab it # that application will 'flash' as the root window takes focus, does nothing because the keypress matched no shortcuts, restores focus to your application ``` Doing the above with this patch: ``` # enable default XFCE keyboard shortcuts in Settings > Keyboard > Application Shortcuts > Reset to Defaults # set 'Up' to 'Print' like in the intial keymap for some people (for some reason) xmodmap -e "keysym Up = Print" # pressing Up should now launch xfce screen grabber # this is the wrong keymap! reset to something sane (not sure what triggers this correction for people with the problem, but it seems to happen automatically on first keypress) setxkbmap -model pc105 # or whatever your default was # pressing Up should no longer launch xfce screen grabber # Up correctly registers in your terminal and previous command is displayed or whatever your shell does with Up ``` Since it's fixed downstream on FreeBSD already with this patch, I spun up a Debian VM I have (Bullseye/sid, but should be replicable on more stable versions or your test container, too) and the behaviour is as above with xfce4 4.14. Hope this helps, let me know if I can do anything to give your more info.
(In reply to Simon Steinbeiss from comment #15) > @Melroy: I'm not confident your problem is the same as the one that Guido > and Conrad describe. In your case it seem to be about a dysfunctional "up" > button, whereas in their case multiple keyboard shortcut mappings > (potentially) change. > > @Guido/Conrad: Can you help to clarify? Ideally if you can reproduce your > scenario with xfce-test that would really help a lot! I'm also running FreeBSD, and cannot run docker images, I can perform tests in Virtualbox VMs easily, to run docker I'd need to install linux on a bare machine AFAIK. Anyway I see there are also linux users reporting the issue with steps to reproduce, which I think should help.
Many thanks Jethro for the steps to reproduce, definitely helpful (and many thanks guido for the detailed bug report, and pushing it back upstream :). Fwiw, i can reproduce the bug on OpenBSD with xfce 4.14 using xmodmap -e 'keysym Up = Print' - once in the 'broken situation', xev shows no KeyPress/KeyRelease for the remapped key. Trying to re-reset the shortcuts via xfce4-keyboard-settings doesnt 'fix' the situation, nor re resetting the x keymap via setxkbmap. on an (unrelated?) note, when resetting shortcuts, on stderr there are two glib error msgs: (xfce4-keyboard-settings:75089): GLib-GObject-CRITICAL **: 09:42:19.278: g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed (xfce4-keyboard-settings:75089): GLib-GObject-CRITICAL **: 09:42:19.289: g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed building libxfce4ui with your patch, restarting xfce4 session, remapping 'up' to print definitely shows screenshooter when hitting up, then resetting the xkeymap to the default ( setxkbmap gb -option -option compose:prsc here) definitely fixes the 'up' key behaviour. as for the patch itself, cant really comment on the code/logic, but why hardcoding to 8 ? is it 'an amount of keys one might remap' in X ? 'an amount of shortcuts one might setup in xfce4-keyboard-settings' ?
i dont really understand the following justification for 8 value in the freebsd patch: + * An arbitrary number of keys may generate the same keyval. Rather than add + * memory allocation to this path, I just constrained the unmapping behavior + * to 8 identically coded keys. It seems unlikely? But I am no xkeyboard + * expert. that means 'one will probably not remap more than 8 physical keys to the same keycode', right ? in that case, i think it makes sense somehow..
dunno if that can matter, but x server is 1.20.8 here, and xkbutils 1.0.4
(In reply to Landry Breuil from comment #20) > i dont really understand the following justification for 8 value in the > freebsd patch: > > + * An arbitrary number of keys may generate the same keyval. Rather than > add > + * memory allocation to this path, I just constrained the unmapping > behavior > + * to 8 identically coded keys. It seems unlikely? But I am no xkeyboard > + * expert. > > that means 'one will probably not remap more than 8 physical keys to the > same keycode', right ? in that case, i think it makes sense somehow.. cem@FreeBSD.org, who originally created the patch (I only did minor changes and submitted it) can correct me if I'm wrong. He knows better for sure. I understand that comment and the code the way you do. But if strictly required the patch can be modified with memory allocation for the buffer, it looks a little overkill though. I posted cem patch almost as is, but I am open to suggestions and requests to make it better.
(In reply to Landry Breuil from comment #20) > i dont really understand the following justification for 8 value in the > freebsd patch: > > that means 'one will probably not remap more than 8 physical keys to the > same keycode', right ? in that case, i think it makes sense somehow.. Yeah, it's just an arbitrary number. The GDK API looked like multiple keycodes could be mapped to a single keyval. I arbitrarily chose 8 as an unlikely high number of keycodes to be mapped to a keyval, but it is just a guess. I have little familiarity with GDK or X. It would be fine to refactor it to allocate the saved keycodes array dynamically, or to bump the number up.
I don't know exactly how but the arrow up key issue is present in (so it is reproducible by running that image): docker pull danger89/xfcevdi:3.0 While I fixed it (somehow) in version 4: docker pull danger89/xfcevdi:4.0 Yeah... sorry I don't know exactly that caused it.
(In reply to Melroy from comment #24) > I don't know exactly how but the arrow up key issue is present in (so it is > reproducible by running that image): > > docker pull danger89/xfcevdi:3.0 > > While I fixed it (somehow) in version 4: > > docker pull danger89/xfcevdi:4.0 > > Yeah... sorry I don't know exactly that caused it. sorry, but *BSD users dont have access to that 'docker' thing ;)
(In reply to Landry Breuil from comment #25) > sorry, but *BSD users dont have access to that 'docker' thing ;) You have Jails in *BSD :P? Nevertheless, I was wrong about that version 4 fixed it. My conclusion is now: often the arrow-up key doesn't work, but sometimes (1 out of 4 or so), the arrow up key does work! I can do this because spinning down and up a new docker container is rather fast, on a normal PC this test-case wouldn't be possible. Meaning this arrow up key issue isn't issue to reproduce since it's timing depended or something. Properly the bug isn't always triggered.
I have refactored the patch at [1] to use glib GArray interface to allow for a growing array of old keys. Could someone review this updated merge request? [1] https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/1
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/16. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev