Bug 244290

Summary: x11-wm/xfce4 does not see up arrow after reinstall
Product: Ports & Packages Reporter: aryeh.friedman
Component: Individual Port(s)Assignee: freebsd-xfce (Nobody) <xfce>
Status: In Progress ---    
Severity: Affects Only Me CC: aryeh.friedman, cem, emaste, iz-rpi03, jethro, madpilot, mvoorhis, samy.mahmoudi
Priority: --- Keywords: patch
Version: LatestFlags: madpilot: maintainer-feedback+
madpilot: merge-quarterly+
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Key pressed observed by xev
none
Newer patch none

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 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 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 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 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 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 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 2020-04-08 14:18:07 UTC
Also experiencing this :-(.
Comment 21 Conrad Meyer freebsd_committer 2020-04-08 14:34:20 UTC
Probably related: PR 244339
Comment 22 Conrad Meyer freebsd_committer 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 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 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 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 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 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 2020-04-12 20:52:56 UTC
Excellent!
Comment 29 Conrad Meyer freebsd_committer 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 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 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 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 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 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 :-)