After deleting all my ports and reinstalling of them (on 2/20/2020) no application when running in a xfce4 environment recognizes/sees the up arrow. All other arrow and cursor control keys work as expected. The up arrow keys works correctly on the console and in twm (default window manager for startx). Note the reason for the delete/reinstall was that I used hal as my I/O manager and as per /usr/port/UPDATES it is no longer supported and the only clean way I found to switch to libdevd was to do a complete delete and reinstall of *ALL* ports on the system.
(In reply to aryeh.friedman from comment #0) I have the same issue as in comment zero -- I rebuilt everything, had no up-arrow (but others DID work). Up-arrow works from a FreeBSD text console, and it works in TWM. I renamed my ~/.config directory out of the way and tried xfce4 once more; this didn't fix the problem. I removed arrow-key bindings in the Window Manager settings, stopped and restarted everything; no joy. There are now three users on this item, so this doesn't appear to be an isolated incident.
Also experiencing this issue. Temporary workaround: XFCE Settings > Keyboard > Application Shortcuts > Selecting the 'Print' shortcut for 'xfce-screenshooter' and removing that option (it is a default entry in XFCE) restores the up-arrow after restarting the session. But presumably PrtScn will now no longer take screenshots? With the default in place and the evdev keyboard input driver you get this PR behaviour where it registers it as some kind of input, but not up arrow (cursors, scroll bars etc seem to 'flash' as a focus change or something when you press the key, but 'up' never registers). Switching to libinput makes the up-arrow actually try to run xfce-screenshooter which gives me an error (because I don't have that installed) which led me to this workaround. Why evdev doesn't try to run shooter and give the error, but disabling that shortcut still fixes the problem, is a different question...
I should of updated the PR to show the temp solution that me and someone working together in -x11@ devised.. add the following line to your .xinitrc (or .xsession as the case may be): setxkbmap -model pc105 -layout us Only real draw back is there is a noticable delay after typing the first character in session and all additional ones
Hi, I noticed now this PR. comment #1 says it does not happen in twm, it means you have tried running "startx" from a terminal with all workarounds disabled? I'm asking to understand the setup. I personally am not experiencing this problem. the up arrow works fine for the use I do of it, which is mostly navigating history on shells and using vi in xfce4-terminal. Is this what is not working for you? BTW what is your hardware? are you using a laptop? If you run xev and press the up arrow in it what do you get? I'm getting these events, for reference: KeyPress event, serial 37, synthetic NO, window 0x6800001, root 0x28b, subw 0x0, time 4786538, (75,-13), root:(786,349), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x6800001, root 0x28b, subw 0x0, time 4786613, (75,-13), root:(786,349), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
(In reply to Guido Falsi from comment #4) xev is what gave us the clue to try the solution I mentioned in comment 3. Short answer is then events are not passed through to where xev can see them (something higher up eats them)
(In reply to aryeh.friedman from comment #5) Forgot it is a standard old cheap 105 key wired keyboard on a generic desktop (Logitech K120 which I have used for years and cost less then $15 [I ware keyboards out to fast for it to be worth investing in anything more expensive]).
For those who want to see the -x11@ thread where this was discussed/solved at great length see https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/024971.html
xev output, down arrow which works fine and is what you'd expect, followed by up arrow which fails: ====================================================================== # Down arrow, works OK KeyPress event, serial 37, synthetic NO, window 0x2a00001, root 0x51, subw 0x0, time 9668719, (-1695,451), root:(138,1326), state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x2a00001, root 0x51, subw 0x0, time 9668800, (-1695,451), root:(138,1326), state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False # Up arrow, doesn't work FocusOut event, serial 37, synthetic NO, window 0x2a00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 37, synthetic NO, window 0x2a00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 37, synthetic NO, window 0x0, keys: 37 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ====================================================================== If I disable the 'Print' shortcut above then I get the 'Up' KeyRelease event like in your xev output as expected. It affects everything in the XFCE session, terminal, firefox, text editors, menus. If I leave xfce and drop to a regular non-X console the up-arrow works fine, then I can run startxfce4 and the issue returns unless I remove that keyboard shortcut. This is a FreeBSD guest in VirtualBox running 13-CURRENT on a Windows 10 host with a Corsair K70 keyboard.
(In reply to Jethro Nederhof from comment #8) The fact that it is running in virtualbox on windows add a whole layer of things that could be interfering even before the FreeBSD kernel sees the input. While it is strange for it to work fine on twm, there could be some changes that affect xfce and not the rest of the system. I honestly have no clue here. Apart from this have you tried following the suggestion sin the mail thread posted in comment #7 ?
(In reply to Guido Falsi from comment #9) I don't think Virtualbox/Windows are the problem because outside of XFCE in the VM it works 100% as expected so the kernel sees it fine. It is only an issue after XFCE is launched and with that Keyboard Shortcut enabled. Outside XFCE it is fine, or with that shortcut disabled it is fine. I have no xorg config after 20-evdev-kbd.conf except 40-libinput.conf, and commenting them each out only gave me the earlier behaviour I mentioned where it properly tries to actually launch xfce-screenshooter. I haven't tried the solution from comment #3 because I don't have setxkbmap and don't want to install it for something that should "just work", (and does work if I disable that shortcut). So I guess for me the problem is a subset of this issue, and more like "up arrow triggers Print action in xfce4 instead of up-arrow"
(In reply to Jethro Nederhof from comment #10) Out of all the suggested solutions both here and in the mailing list thread the setxkbmap is the one that is: 1. The most universal (there have reports of other WM's doing the same thing as xfce4 and this is a one size fits all solution) 2. It is the one that "just works" and is the most transparent to the GUI/applications/user 3. It by far the simplest and most persistent I stand by comment I made in the mail thread that the entire thing is a CLUSTERF*CK but the simplest solution is to completely wipe and reinstall Xorg, XFCE4 and do the solution suggested (all others are true hacks).
(In reply to aryeh.friedman from comment #11) As I have already stated, I have no clue, so I'm not proposing solutions. What I was asking if you "tested" some changes whch had an effect for other people. I really don't understand you point about "just working". We would all like everything to "just work" and sometimes they do, some others they don't. In your case it does not "just work" and a solution is needed. Testing with xbkconf may not rate as a solution but could be a test to see how things work out. Apart from this if for any reason your setup maps keys differently than other systems xkbconf could be the only solution. The xev output shows the key giving a different result. One interesting test would be to test in xev with another window manager (twm for example) to see if the key is read correctly there by xev. I don't know the internals of xfce parts. I only upgraded the ports and try to keep them working. I don't know if there is something fiddling with the input and have no idea where to start to look for that. I'm trying to help you, but since I'm not experiencing this issue I can only ask you to perform some operation to give me a clue.
(In reply to Guido Falsi from comment #12) This was meant as a reply to comment #10
(In reply to Guido Falsi from comment #12) From my testing other WM's for the most part see xev correctly
(In reply to Guido Falsi from comment #12) Sorry all, I think I've come across more rudely than intended! I didn't mean to claim disabling the shortcut was the best solution or a fix for everyone, just mentioned that it worked for me to hopefully give more information to help find the core issue. Likewise that my hardware situation seemed different to aryeh's I thought was just additional information. Apologies if I was pushy or rude in trying to help. I can easily enable/disable the issue now so if I can help test any further solutions I'm happy to help.
After a quick look I'd say xfce is doing some default binding with the arrow keys. up and down ones at least. I have no idea which xfce component and which library function they may be calling to perform such mapping. Even grepping the sources is not going to help much, since I don't know what to grep and where. I'd suggest you file a bug report in the xfce bugzilla, describing the problem in simple terms. You should also state FreeBSD changed the Xorg default backend for input events. You should also state we are looking for some clue, maybe some XFCE developer with better knowledge of the code base can point us in the right direction.
(In reply to Jethro Nederhof from comment #15) No offense taken!
OK so I've dug into this a bit further and I think there is a relevant bug in XFCE. For port x11/libxfce4menu, in libxfce4kbd-private/xfce-shortcuts-grabber.c and the xfce_shortcuts_grabber_keys_changed function. This function is called whenever the X11 keymap is updated, it 'ungrabs' all the current shortcut keys, then loops through again and 'grabs' them again. Grabs are implemented against the keycode value provided by the keymap, but the problem is the removal ungrabs with the current updated value from the keymap (keys[i].keycode), rather than the old one. So the problem manifests as: XFCE loads with a keymap XFCE registers shortcuts that use keys in that keymap The keymap updates The changes in the keymap update involve keys used in shortcuts XFCE ungrabs the shortcuts using the 'new' keymap codes The 'old' keymap codes never get ungrabbed, but the new keycodes are grabbed So for me when XFCE starts, gdk_keymap_get_entires_for_keyval() tells XFCE that "keycode 111 (Up) maps to keyval 65377 (Print)" (for whatever reason), XFCE maps the shortcut to it, then shortly after the keymap updates and says that "actually keycode 107 (Print) maps to keyval 65377 (Print)" and XFCE then ungrabs keycode 107, then grabs it again, and the grab against 111 just stays there forever without being cleaned up. I don't know much about X programming, but guess 'up' itself fails since even when it matches the grab, the keyval doesn't match keyval 65377 (Print) so it never tries to launch the associated shortcut in xfce_shortcuts_grabber_event_filter(), then the 'flash' is the keypress event getting sent to the root_window and unfocusing/refocusing the child window which never receives the event due to XGrabKey's owner_events being false. The setxkbmap workaround works by racing XFCE and updating the keymap so it's correct the first time and nothing needs to be cleaned up, but the problem would arise again if the keymap got updated mid-session (though why this happens every session for me I haven't discovered).
(In reply to Jethro Nederhof from comment #18) What appears to have happened is the bug was found and patched and then somehow the patch got lost in an update (see email thread for details)
Also experiencing this :-(.
Probably related: PR 244339
Please try this patch. It seems to fix the issue, at least for me: https://reviews.freebsd.org/D24338 My test may be confounded by having deleted the Printscreen shortcut entirely, so additional testing welcome. Thanks all, and Jethro in particular for the deep diagnosis in comment #18, without which this would not be possible.
(In reply to Conrad Meyer from comment #22) Your patch is very welcome. I'll test it locally even if I have not seen this issue happen myself. I'll try to commit it once we get some positive feedback. Marking this for quarterly merge, and will also push this upstream.
A commit references this bug: Author: cem Date: Sun Apr 12 20:23:56 UTC 2020 New revision: 531554 URL: https://svnweb.freebsd.org/changeset/ports/531554 Log: x11/libxfce4menu: Fix leaked keygrabs when layout changes As diagnosed by Jethro Nederhof, xfce-shortcuts-grabber.c attempts to update grabbed key shortcuts when xkeyboard layout changes. Unfortunately, it had no memory of which keycodes it has actually grabbed. Instead, it attempted to ungrab the *new* keycode, which obviously doesn't actually ungrab those codes. This went unnoticed for some time, probably because nothing collided with important keys. Recently, a default PrintScreen shortcut was added to Xfce, which for whatever reason seems to collide with Up in initial layout. When the kbd layout changes, the shortcut ungrabs the *new* Printscreen keycode and then re-grabs the same keycode, leaving the Up keycode grabbed. Fix this by giving xfce-shortcuts-grabber some memory of which keycodes it has grabbed. When it grabs a key, it remembers the keycode it grabbed in the XfceKey object. When it ungrabs a key, it ungrabs the keycodes in the XfceKey object, rather than those for the new keyboard layout. PR: 244290 Reported by: Aryeh Friedman <aryeh.friedman AT gmail.com>, many others Approved by: madpilot Differential Revision: https://reviews.freebsd.org/D24338 Changes: head/x11/libxfce4menu/Makefile head/x11/libxfce4menu/files/ head/x11/libxfce4menu/files/patch-libxfce4kbd-private_xfce-shortcuts-grabber.c
Guido, would you take care of MFH, if needed? I am not familiar with it.
(In reply to Conrad Meyer from comment #25) Done, thanks again for your patch!
A commit references this bug: Author: madpilot Date: Sun Apr 12 20:47:19 UTC 2020 New revision: 531556 URL: https://svnweb.freebsd.org/changeset/ports/531556 Log: MFH: r531554 x11/libxfce4menu: Fix leaked keygrabs when layout changes As diagnosed by Jethro Nederhof, xfce-shortcuts-grabber.c attempts to update grabbed key shortcuts when xkeyboard layout changes. Unfortunately, it had no memory of which keycodes it has actually grabbed. Instead, it attempted to ungrab the *new* keycode, which obviously doesn't actually ungrab those codes. This went unnoticed for some time, probably because nothing collided with important keys. Recently, a default PrintScreen shortcut was added to Xfce, which for whatever reason seems to collide with Up in initial layout. When the kbd layout changes, the shortcut ungrabs the *new* Printscreen keycode and then re-grabs the same keycode, leaving the Up keycode grabbed. Fix this by giving xfce-shortcuts-grabber some memory of which keycodes it has grabbed. When it grabs a key, it remembers the keycode it grabbed in the XfceKey object. When it ungrabs a key, it ungrabs the keycodes in the XfceKey object, rather than those for the new keyboard layout. PR: 244290 Reported by: Aryeh Friedman <aryeh.friedman AT gmail.com>, many others Approved by: madpilot Differential Revision: https://reviews.freebsd.org/D24338 Approved by: portmgr (blanket, runtime fix) Changes: _U branches/2020Q2/ branches/2020Q2/x11/libxfce4menu/Makefile branches/2020Q2/x11/libxfce4menu/files/
Excellent!
Guido, did you get a chance to report or submit this upstream yet?
(In reply to Conrad Meyer from comment #29) Actaully no, I wanted to clean up the patch before, but did not have time to. I"m going to have a better look in the next few days.
No worries, just checking up. :)
Fantastic, thanks a lot Conrad & Guido for your work on this issue! Looking forward to seeing the fix in an upstream release soon.
Created attachment 214538 [details] Key pressed observed by xev Same kind of findings I saw before,. It looks like the 'up' arrow key is not recognized as key pressed / key released. See attachment.
Cleaned/reworked patch committed upstream two days ago. Good job all!
(In reply to Samy Mahmoudi from comment #34) > Cleaned/reworked patch committed upstream two days ago. Good job all! Actually that path has bugs, and, with suggestions from cem, I posted a new patch upstream: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/2
By trial and error I have noticed some things that might be interesting. Context: libxfce4menu-4.14.1_1 12.1-RELEASE-p5 amd64 FACT 1: Starting xfce4 from vt, the up arrow key is not correctly mapped (pressing the key makes the xfce4-terminal cursor blinks but does not show previous shell commands...) and my compiz desktop switcher (CTRL+ALT+AN_ARROW_KEY) does not trigger. FACT 2: When using SLiM autologin or lightdm autologin: same faulty behavior. FACT 3: - When manually setting my SLiM session to "Xfce Session" (by pressing F1 at the SLiM login screen): not problem at all after the start. - When using SLiM "default" session (which I have mapped to startxfce4 in my .xinitrc) by NOT pressing F1 at the SLiM login screen: no problem at all after the start. - When using the lightdm login screen: no problem at all after the start. FACT 4: Adding a setxkbmap command at the beginning of my .xinitrc works around the SLiM autologin but not the lightdm autologin. My understanding is that the underlying problem is not resolved, despite revision 531554, so I am quite comforted by comment 35. That's why I wrote comment 34, in the hope of testing your first reworked patch. FACTS 3 and 4 may just reveal variants of the same workaround. Moreover, these workarounds may not be sustainable during the whole session lifetime. Now I will rather test the rereworked patch ;-)
(In reply to Samy Mahmoudi from comment #36) blinks ---> blink
Reopening this bug. (In reply to Samy Mahmoudi from comment #36) First of all I'm not an expert about modern desktop practices and while I try to do my best to maintain XFCE ports I don't have a full grasp of all the freedesktop.org standards and tools, like consolekit and the like. I may be wrong but I can state the following: SLiM has been unmaintained for years and does not adhere to all the latest practices, so problems when using it and not applying workarounds can be expected. Also launching a modern desktop environment from console (or old display managers) can require special care. in detail: >FACT 1: Starting xfce4 from vt, the up arrow key is not correctly mapped (pressing the key makes the xfce4-terminal cursor blinks but does not show previous shell commands...) and my compiz desktop switcher (CTRL+ALT+AN_ARROW_KEY) does not trigger. Exactly how do you start xfce from console? In such case I think the correct command is: startxfce4 --with-ck-launch This wraps Xorg in consolekit which provides some needed services. Have you tried this? Also, being xfwm4 a compositing window manager I'm not sure if using also compiz at the same time is supported or they could conflict in certain situations. Regarding the other facts II admit I have no idea what is happening. I've never used autologin. What is the exact setxkbmap command you are running? Also, what locale have you setup in your environment? That could be affecting things. I'll followup with the patch to the ports that you can try, but it's a minor change that, most probably, is not going to affect what you are seeing.
Created attachment 215420 [details] Newer patch Attaching patch to the ports tree applying code proposed upstream to the port.
(In reply to Guido Falsi from comment #38) > I don't have a full grasp of all the freedesktop.org standards and tools, like consolekit and the like. I was struggling with ConsoleKit before landing to this PR... > Exactly how do you start xfce from console? I use a mere startx, together with my .xinitrc: #!/bin/sh # SLiM now starts Consolekit # Xfce now starts DBus # Temporary workaround # setxkbmap -model pc105 -layout fr,ru -option grp:alt_space_toggle,terminate:ctrl_alt_bksp DB="dbus-launch --exit-with-session" CK="ck-launch-session" case $1 in slim-autologin) # Separates SLiM autologin from vt launch. # Requires patching SLiM, or SLiM autologin default to *) below ! exec startxfce4 ;; default) # SLiM default session (To set a system-wide default session, override "default" in slim.conf). exec startxfce4 ;; startxfce4) exec startxfce4 ;; mate-session) exec ${DB} mate-session ;; lxde) exec ${DB} startlxde ;; kodi-standalone) exec kodi-standalone ;; *) # exec ${CK} ${DB} openbox-session exec startxfce4 --with-ck-launch ;; esac > In such case I think the correct command is: startxfce4 --with-ck-launch You are absolutely right, that is the way to start Xfce from the virtual consoles (and that is basically what is done when I run startx). > Also, being xfwm4 a compositing window manager I have heard about xfwm4 using Xpresent and being an OpenGL compositor in a mate pull request, inspiring mate guys ;-) > I'm not sure if using also compiz at the same time is supported or they could conflict in certain situations. I have replaced xfwm4 with compiz for years (by overriding xfce4-session.xml). So far so good! > What is the exact setxkbmap command you are running? setxkbmap -model pc105 -layout fr,ru -option grp:alt_space_toggle,terminate:ctrl_alt_bksp > Also, what locale have you setup in your environment? That could be affecting things. I have written a French login class in login.conf to have LANG=fr_FR.UTF-8 in my environment. I will investigate further on this particular aspect.
(In reply to Guido Falsi from comment #39) Tested! Unfortunately, the patch in its current form does not resolve the problem (at least in my case).
(In reply to Guido Falsi from comment #38) Neither does the absence of LANG in my environment (I created a new user account to also exclude potential problems coming from a previous configuration).
I just found out something interesting that may help to isolate my problems and separate them from this PR. Context: patch from comment 39 applied. If I refrain from starting xbindkeys, or if I start xbindkeys after compiz, the up arrow key malfunctions/blinks/flashes just once (the first time you use the key), then works as expected. CTRL+ALT+AN_ARROW_KEY still does not trigger desktop switchs (configured in compiz), but now I doubt that I can impute this to Xfce as desktop switching works in Xfce (CTRL+ALT+AN_ARROW_KEY) if compiz is not started. My problem may be due to the concurrency of Xfce, Compiz and Xbindkeys. Before something changed (update of xorg-server to 1.20.7 ?), that hazardous trio was doing OK as is. Now it needs workarounds: • Starting Xfce from SLiM works around both problems (once-only dysfunction of the up arrow key and CTRL+ALT+AN_ARROW_KEY in compiz), except with the SLiM autologin feature. • Putting a setxkbmap command in .xinitrc works around both problems in all scenarios (start from command-line, SLiM autologin and regular SLiM sessions) In conclusion, if I stick to Xfce (no xbindkeys, no compiz) the bug seems resolved, EXCEPT AT THE FIRST USE OF THE KEY. Can any of you (especially Melroy van den Berg) reproduce this once-only up arrow key dysfunction (when first using the key) in the following context: • no setxkbmap command in .xinitrc • no additional keyboard grabbers started (xbindleys, compiz, etc.) • regular 4.14.1_1 (then possibly with the patch of comment 39)
(In reply to Samy Mahmoudi from comment #43) Hey Samy, Yes, thanks for clarifying it's just the first keypress, you had me worried there! I can replicate this, and as far as I understand the bug, being broken on the first keypress is expected behaviour because the initial keymap is still incorrect, but first keypress triggers the update to the correct keymap. The patch from this PR only updates how XFCE handles the change of state from insane keymap to sane and makes it work appropriately instead of continuing with the insane state after the update. I suspect the issue not appearing with display managers is because the first keypress happens there and triggers the keymap update before XFCE loads, which makes it work correctly as in the initial workaround with setxkbmap (skipping this with autologin avoids this). So I think there's a different issue with xorg initially detecting the wrong keymap until first keypress, but it's unrelated to this issue and XFCE and probably should be a different PR. Compiz may just not handle the keymap updating? Not sure. Hope this helps!
(In reply to Jethro Nederhof from comment #44) > Yes, thanks for clarifying it's just the first keypress, you had me worried there! You're welcome. > I suspect the issue not appearing with display managers is because the first keypress happens there and triggers the keymap update before XFCE loads, which makes it work correctly as in the initial workaround with setxkbmap (skipping this with autologin avoids this). Your explanation makes sense and unifies the two workarounds (using setxkbmap/using a display manager). So I think there's a different issue with xorg initially detecting the wrong keymap until first keypress. > With all the mess that results from recent changes in Xorg, I can only agree :-) > Compiz may just not handle the keymap updating? Not sure. I could not do compiz-specific tests previously because x11-wm/ccsm has been removed from the ports tree due to Python 2 deprecation, and I did not want to lose time on resurrecting it because I was working on porting Compiz Reloaded. I have just finished porting Compiz Reloaded to FreeBSD (committed upstream in summer 2018 and in May/June 2020) so I was able to test a bit today: compiz triggers desktop switches on CTRL+ALT+AN_ARROW_KEY if and only if one of the workarounds is applied (using setxkbmap/using a display manager). I don't know what conclusion to draw but I will definitely wait for an Xorg fix before coming back to this, as my environment is now fully functional again. > Hope this helps! Yes it does, thank you Jethro.
(In reply to Samy Mahmoudi from comment #45) Correction (inversion): > So I think there's a different issue with xorg initially detecting the wrong keymap until first keypress. With all the mess that results from recent changes in Xorg, I can only agree :-)
A commit references this bug: Author: madpilot Date: Wed Jul 15 13:26:46 UTC 2020 New revision: 542258 URL: https://svnweb.freebsd.org/changeset/ports/542258 Log: Update patch to Fix leaked keygrabs when layout changes to code merged upstream. PR: 244290 Submitted by: Aryeh Friedman <aryeh.friedman AT gmail.com>, many others Obtained from: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/2 MFH: 2020Q3 Differential Revision: https://reviews.freebsd.org/D24995 Changes: head/x11/libxfce4menu/Makefile head/x11/libxfce4menu/files/patch-libxfce4kbd-private_xfce-shortcuts-grabber.c
I think the issue reported here has been fixed, and the change is now included in upstream repository, so it will be included in the next official release. Can this issue be closed and marked as fixed?
Yes :). Thanks for all your work on this, Guido. We can reopen easily enough if the issue is still observed.
A commit references this bug: Author: madpilot Date: Thu Jul 16 08:48:39 UTC 2020 New revision: 542340 URL: https://svnweb.freebsd.org/changeset/ports/542340 Log: MFH: r542258 Update patch to Fix leaked keygrabs when layout changes to code merged upstream. PR: 244290 Submitted by: Aryeh Friedman <aryeh.friedman AT gmail.com>, many others Obtained from: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/2 Differential Revision: https://reviews.freebsd.org/D24995 Approved by: portmgr (joneum) Changes: _U branches/2020Q3/ branches/2020Q3/x11/libxfce4menu/Makefile branches/2020Q3/x11/libxfce4menu/files/patch-libxfce4kbd-private_xfce-shortcuts-grabber.c
FWIW, I had this exact issue but not until upgrading to XFCE 4.16 The fix I found was to hit "Reset to Defaults" in XFCE Settings > Keyboard > Application Shortcuts
Hi . Making "XFCE Settings > Keyboard > Application Shortcuts" and for additional changing keyboard type from 105 keys to 104 to/and back - helps , but only for one current session. Up arrow / keyboard works no problem on console text mode , even under x11, using session 'freerdp' to windows host up arrow key is okey there . Also up-arrow key on the numeric keypad is working ( backup solution ) but it have different meaning with the shit key , and this one is physically apart from up/down left/right 4 keys used primary.
(In reply to Keith Beattie from comment #51) Clean install - had the same problem and your workaround fixed it. Thanks Keith!
Yeah, can confirm this was reintroduced to 4.16 upstream in https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/85d8d390f9f2265613da4291992523937a7a2519 If you don't mind building the port instead, you can un-delete the line at https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/85d8d390f9f2265613da4291992523937a7a2519#80f74afa9222af5979dad472e393792fb0194051_175_183 (in the port x11/libxfce4menu). This restores the patched 4.14 behaviour of "up" being broken until the first keypress, which updates the keymap and everything works OK after that. But you'll also probably re-introduce the performance issue that patch tries to solve if you're using a .Xmodmap file and experiencing that issue. Restoring the default shortcuts will also fix it as mentioned, (this ungrabs everything and regrabs the defaults) but in my experience you have to do it every session. That same patch also seems to have possible regressions in https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/33 so there'll hopefully be a fix soon that fixes both issues, or diagnosing that will find the root cause of this issue and we'll get it for free.
(In reply to Conrad Meyer from comment #49) > We can reopen easily enough if the issue is still observed. Apparently it is (both from the audit trail below and independent reports), reopening.
(In reply to Alexey Dokuchaev from comment #55) This seems like a new, related regression introduced in the 4.16 timeline.
I still have this issue now (12.2-RELEASE-p2, xfce-4.16). The PrintScreen workaround seems to work.
The workaround: use "arrow up" key on NumPad, then all OK.
(In reply to Jethro Nederhof from comment #54) In relation to this commit: https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/85d8d390f9f2265613da4291992523937a7a2519#80f74afa9222af5979dad472e393792fb0194051_175_183 user reports seem to indicate that adding back the ungrab line (code line 175) seems to really fix this issue. Is this the consensus? I could test adding back that line in our port and lobby upstream for such a change. As I already said I'm not experiencing this issue, so I can't test myself, but if such a commit would solve this issue for most users I'll be happy to do it.
(In reply to Guido Falsi from comment #59) Conversation with upstream [1] indicates that the ungrab line was removed mainly because in linux it caused a 30-40 seconds delay and high CPU usage when switching from vty to Xorg in regrabbing the keys. Could someone who has applied the change (adding back the ungrab) verify that this does not affect FreeBSD? We are a different OS than linux and our console is different, it's quite possible that the issue is not affecting us in the first place! [1] https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/85d8d390f9f2265613da4291992523937a7a2519
(In reply to Guido Falsi from comment #59) +1, let's add it back. I'm not experiencing the issue yet because I'm still on 4.14. (In reply to Guido Falsi from comment #60) Even if it caused a 30 second vty<->Xorg switch delay, that seems better to me than a broken up arrow. I don't switch vty<->Xorg often (or ever).
(In reply to Conrad Meyer from comment #61) > Even if it caused a 30 second vty<->Xorg switch delay, that seems better to > me than a broken up arrow. I don't switch vty<->Xorg often (or ever). Actually I do that very rarely too, and usually that's because Xorg is already misbehaving. I'll perform some local testing to make sure there is no evident regression, though, so allow me some time before committing this change.
(In reply to Guido Falsi from comment #62) I actually run two Xorg Xservers on the same PC, one for myself and another for the wife (both start from their respective startx), so that each of us could have his/her own session. The switching between Xservers is already problematic sometimes (the whole graphics subsystem may freeze and I have to kill the frozen Xservers via ssh from another host), I don't want it to become even more problematic.
Created attachment 221942 [details] add back xfce_shortcuts_grabber_ungrab_all call (In reply to Victor Sudakov from comment #63) I understand the problem you are facing, but it looks to me that your issue is more a problem with graphics drivers and Xorg itself than with XFCE. As I said it is quite possible out vty switching acts different than the linux one. It is a completely different code base. Unluckily without testing I cannot foresee how this is going to affect you. Could you simply test compiling a modified x11/libxfce4menu and check how it affects you? You can simply revert it after a quick test. I'm attaching a tentative patch to the port so anyone can test and report back.
(In reply to Guido Falsi from comment #64) I'm using the proposed patch on my machines, and I see no regressions. Switching to and from vtys works as usual, My key combinations work as expected. Plan to commit it after some more testing.
(In reply to Guido Falsi from comment #65) Awesome!
A commit references this bug: Author: madpilot Date: Fri Jan 29 08:03:41 UTC 2021 New revision: 563178 URL: https://svnweb.freebsd.org/changeset/ports/563178 Log: Add patch to libxfce4menu reverting part of upstream commit 85d8d390, adding back code to ungrab all keys before grabbing them again. The call has been removed upstream due to causing problems with tty switching on linux, but testing in FreeBSD show no such problems when switching to and from vty, and fix issues with keys not working properly in FreeBSD. PR: 244290 Submitted by: aryeh.friedman@gmail.com, Jethro Nederhof <jethro@jethron.id.au> (suggested patch) Reported by: many MFH: 2021Q1 Changes: head/x11/libxfce4menu/Makefile head/x11/libxfce4menu/files/ head/x11/libxfce4menu/files/patch-libxfce4kbd-private_xfce-shortcuts-grabber.c
A commit references this bug: Author: madpilot Date: Fri Jan 29 10:58:28 UTC 2021 New revision: 563193 URL: https://svnweb.freebsd.org/changeset/ports/563193 Log: MFH: r563178 Add patch to libxfce4menu reverting part of upstream commit 85d8d390, adding back code to ungrab all keys before grabbing them again. The call has been removed upstream due to causing problems with tty switching on linux, but testing in FreeBSD show no such problems when switching to and from vty, and fix issues with keys not working properly in FreeBSD. PR: 244290 Submitted by: aryeh.friedman@gmail.com, Jethro Nederhof <jethro@jethron.id.au> (suggested patch) Reported by: many Changes: _U branches/2021Q1/ branches/2021Q1/x11/libxfce4menu/Makefile branches/2021Q1/x11/libxfce4menu/files/
Added link to upstream merge request. Upstream is unwilling to accept this patch, and they provided a sensible reason Anyone with X11 programming experience has an idea where to look at to find a "proper" fix, one that works fine both in FreeBSD and linux.
Looks like I actually lost a message from upstream. Upstream developer states the patch at https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/27 could fix this. I'm going to create a patch to the port incorporating it. Someone experiencing the issue should test and report back then!
Created attachment 222475 [details] upstream patch This is a patch importing [1] from upstream to the port. It replaces my previous patch which added back the ungrab_all call. I'm running with it and everything looks fine. It would be really useful if someone who was experiencing this issue could test running this patch and confirms it really fixes the issue. [1] https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/27
Doesn't fix the issue for me. Same behavior as before the ugrab patch; up arrow doesn't work, resetting keyboard shortcuts to default makes it work again until you start a new X session. I might have messed up the patch apply or something, hopefully someone else can test & confirm. Thanks for sticking with this Guido, can appreciate it's frustrating trying to fix an issue you can't replicate.
In my case in FreeBSD 13.0-BETA1 and 13.0-BETA2, Xfce 4.16 the problem with the "arrow up" does not appear by default settings with US and RUS keyboard layout. Xfce 4.16 is installed from the "quarterly" packages repository. PCs: Acer Revo Box RN86, Acer Aspire XC-895, Logitech K120 Keyboards.
Not sure how to deal with this now. I have seen no negative effect from running with this patch. Only report I have is in comment #72 and indicates this patch is not fixing the actual issue. to Jethro Nederhof: Could you try again? I also uploaded the patched port directory here: https://people.freebsd.org/~madpilot/libxfce4menu.txz you could simply remove the previous port and unpack this in x11 to get an already patched one. This would remove doubt about incorrect patching. Please note that this patch does include again the xfce_shortcuts_grabber_ungrab_all call, but in a conditional, it should work though, as far as I know.
Upstream informed me a few minutes ago that a revised and improved version of this patch is going to be published in a few days, so any testing should be performed on that. So no hurry right now. ref.: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/27#note_25778
Created attachment 222886 [details] Upstream patch requiring testing Upstream proposed a new patch. I'm attaching it here as a patch to the port for testing. Please test it and report if it fixes the issue at hand for people experiencing it. I'm also making the port available as a tarball (please remove the old one before extracting this): https://people.freebsd.org/~madpilot/libxfce4menu.txz Thanks in advance!
Thanks Guido, I can confirm the patched port from your tarball fixes the issue and the up arrow continues to work as expected with these changes.
(In reply to Jethro Nederhof from comment #77) This is great news. I'm going to add this patch to the ports tree right away for wider testing and then report back upstream.
A commit references this bug: Author: madpilot Date: Tue Mar 2 11:01:41 UTC 2021 New revision: 566943 URL: https://svnweb.freebsd.org/changeset/ports/566943 Log: Import patch from upstream to fix key grabbing issues. This replaces previous homegroown patch. PR: 244290 Submitted by: aryeh.friedman@gmail.com Tested by: Jethro Nederhof <jethro@jethron.id.au> Obtained from: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/27 MFH After: 1 week MFH: 2021Q1 Changes: head/x11/libxfce4menu/Makefile head/x11/libxfce4menu/files/patch-libxfce4kbd-private_xfce-shortcuts-grabber.c head/x11/libxfce4menu/files/patch-shortcuts-grabber-fix-PR27
A commit references this bug: Author: madpilot Date: Thu Mar 11 09:06:00 UTC 2021 New revision: 568071 URL: https://svnweb.freebsd.org/changeset/ports/568071 Log: MFH: r566943 Import patch from upstream to fix key grabbing issues. This replaces previous homegroown patch. PR: 244290 Submitted by: aryeh.friedman@gmail.com Tested by: Jethro Nederhof <jethro@jethron.id.au> Obtained from: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/27 Changes: _U branches/2021Q1/ branches/2021Q1/x11/libxfce4menu/Makefile branches/2021Q1/x11/libxfce4menu/files/patch-libxfce4kbd-private_xfce-shortcuts-grabber.c branches/2021Q1/x11/libxfce4menu/files/patch-shortcuts-grabber-fix-PR27
The patch I committed has been merged upstream, and is merged to quarterly, so, hoping this is fixed for real now, I'm closing this bug report. Thanks to all for testing and feedback. Ref.: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/27