Bug 244290 - x11-wm/xfce4 does not see up arrow after reinstall
Summary: x11-wm/xfce4 does not see up arrow after reinstall
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-xfce (Nobody)
URL: https://gitlab.xfce.org/xfce/libxfce4...
Keywords: patch
Depends on:
Blocks:
 
Reported: 2020-02-21 21:03 UTC by aryeh.friedman
Modified: 2021-03-12 00:08 UTC (History)
14 users (show)

See Also:
madpilot: maintainer-feedback+
madpilot: merge-quarterly+


Attachments
Key pressed observed by xev (158.29 KB, image/png)
2020-05-15 21:56 UTC, Melroy van den Berg
no flags Details
Newer patch (5.52 KB, patch)
2020-06-10 14:16 UTC, Guido Falsi
no flags Details | Diff
add back xfce_shortcuts_grabber_ungrab_all call (1.46 KB, patch)
2021-01-26 18:28 UTC, Guido Falsi
no flags Details | Diff
upstream patch (5.14 KB, patch)
2021-02-15 20:25 UTC, Guido Falsi
no flags Details | Diff
Upstream patch requiring testing (49.96 KB, patch)
2021-02-28 19:18 UTC, Guido Falsi
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description aryeh.friedman 2020-02-21 21:03:05 UTC
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.
Comment 1 M. Voorhis 2020-03-20 18:25:50 UTC
(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.
Comment 2 Jethro Nederhof 2020-03-21 08:34:40 UTC
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...
Comment 3 aryeh.friedman 2020-03-21 09:29:22 UTC
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
Comment 4 Guido Falsi freebsd_committer freebsd_triage 2020-03-21 10:24:54 UTC
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
Comment 5 aryeh.friedman 2020-03-21 10:28:45 UTC
(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)
Comment 6 aryeh.friedman 2020-03-21 10:31:32 UTC
(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]).
Comment 7 aryeh.friedman 2020-03-21 10:39:16 UTC
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
Comment 8 Jethro Nederhof 2020-03-21 10:59:11 UTC
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.
Comment 9 Guido Falsi freebsd_committer freebsd_triage 2020-03-21 11:08:00 UTC
(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 ?
Comment 10 Jethro Nederhof 2020-03-21 11:33:54 UTC
(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"
Comment 11 aryeh.friedman 2020-03-21 11:48:29 UTC
(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).
Comment 12 Guido Falsi freebsd_committer freebsd_triage 2020-03-21 11:54:26 UTC
(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.
Comment 13 Guido Falsi freebsd_committer freebsd_triage 2020-03-21 11:54:59 UTC
(In reply to Guido Falsi from comment #12)

This was meant as a reply to comment #10
Comment 14 aryeh.friedman 2020-03-21 11:58:31 UTC
(In reply to Guido Falsi from comment #12)
From my testing other WM's for the most part see xev correctly
Comment 15 Jethro Nederhof 2020-03-21 12:03:25 UTC
(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.
Comment 16 Guido Falsi freebsd_committer freebsd_triage 2020-03-21 12:09:15 UTC
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.
Comment 17 Guido Falsi freebsd_committer freebsd_triage 2020-03-21 12:09:39 UTC
(In reply to Jethro Nederhof from comment #15)

No offense taken!
Comment 18 Jethro Nederhof 2020-03-22 04:04:12 UTC
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).
Comment 19 aryeh.friedman 2020-03-22 09:36:15 UTC
(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)
Comment 20 Conrad Meyer freebsd_committer freebsd_triage 2020-04-08 14:18:07 UTC
Also experiencing this :-(.
Comment 21 Conrad Meyer freebsd_committer freebsd_triage 2020-04-08 14:34:20 UTC
Probably related: PR 244339
Comment 22 Conrad Meyer freebsd_committer freebsd_triage 2020-04-08 15:54:56 UTC
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.
Comment 23 Guido Falsi freebsd_committer freebsd_triage 2020-04-08 16:36:53 UTC
(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.
Comment 24 commit-hook freebsd_committer freebsd_triage 2020-04-12 20:24:02 UTC
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
Comment 25 Conrad Meyer freebsd_committer freebsd_triage 2020-04-12 20:32:32 UTC
Guido, would you take care of MFH, if needed?  I am not familiar with it.
Comment 26 Guido Falsi freebsd_committer freebsd_triage 2020-04-12 20:47:45 UTC
(In reply to Conrad Meyer from comment #25)

Done, thanks again for your patch!
Comment 27 commit-hook freebsd_committer freebsd_triage 2020-04-12 20:48:09 UTC
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/
Comment 28 Conrad Meyer freebsd_committer freebsd_triage 2020-04-12 20:52:56 UTC
Excellent!
Comment 29 Conrad Meyer freebsd_committer freebsd_triage 2020-04-24 01:58:44 UTC
Guido, did you get a chance to report or submit this upstream yet?
Comment 30 Guido Falsi freebsd_committer freebsd_triage 2020-04-24 10:59:50 UTC
(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.
Comment 31 Conrad Meyer freebsd_committer freebsd_triage 2020-04-24 16:17:23 UTC
No worries, just checking up. :)
Comment 32 Jethro Nederhof 2020-04-26 04:05:55 UTC
Fantastic, thanks a lot Conrad & Guido for your work on this issue! Looking forward to seeing the fix in an upstream release soon.
Comment 33 Melroy van den Berg 2020-05-15 21:56:49 UTC
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.
Comment 34 Samy Mahmoudi 2020-06-10 10:09:41 UTC
Cleaned/reworked patch committed upstream two days ago. Good job all!
Comment 35 Guido Falsi freebsd_committer freebsd_triage 2020-06-10 11:10:16 UTC
(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
Comment 36 Samy Mahmoudi 2020-06-10 13:34:44 UTC
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 ;-)
Comment 37 Samy Mahmoudi 2020-06-10 13:36:37 UTC
(In reply to Samy Mahmoudi from comment #36)
blinks ---> blink
Comment 38 Guido Falsi freebsd_committer freebsd_triage 2020-06-10 14:14:07 UTC
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.
Comment 39 Guido Falsi freebsd_committer freebsd_triage 2020-06-10 14:16:17 UTC
Created attachment 215420 [details]
Newer patch

Attaching patch to the ports tree applying code proposed upstream to the port.
Comment 40 Samy Mahmoudi 2020-06-10 21:18:28 UTC
(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.
Comment 41 Samy Mahmoudi 2020-06-13 00:26:14 UTC
(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).
Comment 42 Samy Mahmoudi 2020-06-13 00:46:32 UTC
(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).
Comment 43 Samy Mahmoudi 2020-06-15 10:39:46 UTC
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)
Comment 44 Jethro Nederhof 2020-06-15 11:03:37 UTC
(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!
Comment 45 Samy Mahmoudi 2020-06-26 17:13:27 UTC
(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.
Comment 46 Samy Mahmoudi 2020-06-26 17:14:57 UTC
(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 :-)
Comment 47 commit-hook freebsd_committer freebsd_triage 2020-07-15 13:27:49 UTC
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
Comment 48 Guido Falsi freebsd_committer freebsd_triage 2020-07-15 13:29:03 UTC
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?
Comment 49 Conrad Meyer freebsd_committer freebsd_triage 2020-07-15 14:21:24 UTC
Yes :). Thanks for all your work on this, Guido. We can reopen easily enough if the issue is still observed.
Comment 50 commit-hook freebsd_committer freebsd_triage 2020-07-16 08:49:41 UTC
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
Comment 51 Keith Beattie 2021-01-04 18:18:47 UTC
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
Comment 52 Piotr Sawicki 2021-01-14 11:34:52 UTC
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.
Comment 53 Gordon Hartley 2021-01-15 20:35:31 UTC
(In reply to Keith Beattie from comment #51)

Clean install - had the same problem and your workaround fixed it.

Thanks Keith!
Comment 54 Jethro Nederhof 2021-01-16 01:05:22 UTC
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.
Comment 55 Alexey Dokuchaev freebsd_committer freebsd_triage 2021-01-16 13:46:27 UTC
(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.
Comment 56 Conrad Meyer freebsd_committer freebsd_triage 2021-01-16 17:28:55 UTC
(In reply to Alexey Dokuchaev from comment #55)
This seems like a new, related regression introduced in the 4.16 timeline.
Comment 57 Victor Sudakov 2021-01-21 15:18:39 UTC
I still have this issue now (12.2-RELEASE-p2, xfce-4.16).

The PrintScreen workaround seems to work.
Comment 58 Dmitry Postolov 2021-01-25 19:01:01 UTC
The workaround: use "arrow up" key on NumPad, then all OK.
Comment 59 Guido Falsi freebsd_committer freebsd_triage 2021-01-26 09:59:20 UTC
(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.
Comment 60 Guido Falsi freebsd_committer freebsd_triage 2021-01-26 11:10:34 UTC
(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
Comment 61 Conrad Meyer freebsd_committer freebsd_triage 2021-01-26 15:05:25 UTC
(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).
Comment 62 Guido Falsi freebsd_committer freebsd_triage 2021-01-26 15:18:38 UTC
(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.
Comment 63 Victor Sudakov 2021-01-26 17:32:05 UTC
(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.
Comment 64 Guido Falsi freebsd_committer freebsd_triage 2021-01-26 18:28:52 UTC
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.
Comment 65 Guido Falsi freebsd_committer freebsd_triage 2021-01-27 12:07:54 UTC
(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.
Comment 66 Conrad Meyer freebsd_committer freebsd_triage 2021-01-27 16:06:25 UTC
(In reply to Guido Falsi from comment #65)
Awesome!
Comment 67 commit-hook freebsd_committer freebsd_triage 2021-01-29 08:04:32 UTC
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
Comment 68 commit-hook freebsd_committer freebsd_triage 2021-01-29 10:59:02 UTC
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/
Comment 69 Guido Falsi freebsd_committer freebsd_triage 2021-02-14 20:55:08 UTC
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.
Comment 70 Guido Falsi freebsd_committer freebsd_triage 2021-02-14 20:57:58 UTC
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!
Comment 71 Guido Falsi freebsd_committer freebsd_triage 2021-02-15 20:25:00 UTC
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
Comment 72 Jethro Nederhof 2021-02-16 10:30:54 UTC
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.
Comment 73 Dmitry Postolov 2021-02-16 12:24:02 UTC
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.
Comment 74 Guido Falsi freebsd_committer freebsd_triage 2021-02-20 15:08:06 UTC
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.
Comment 75 Guido Falsi freebsd_committer freebsd_triage 2021-02-20 15:30:04 UTC
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
Comment 76 Guido Falsi freebsd_committer freebsd_triage 2021-02-28 19:18:25 UTC
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!
Comment 77 Jethro Nederhof 2021-03-02 10:25:02 UTC
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.
Comment 78 Guido Falsi freebsd_committer freebsd_triage 2021-03-02 10:57:21 UTC
(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.
Comment 79 commit-hook freebsd_committer freebsd_triage 2021-03-02 11:01:46 UTC
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
Comment 80 commit-hook freebsd_committer freebsd_triage 2021-03-11 09:06:37 UTC
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
Comment 81 Guido Falsi freebsd_committer freebsd_triage 2021-03-12 00:08:44 UTC
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