Shortcuts Ignored After Upgrade
Closed this issue · 136 comments
Expected Behavior
After upgrading lxqt shortcut keys are expected to work as before
Current Behavior
Upgrading lxqt, in particular lxqt-globalkeys (0.17.0-1 -> 1.0.0-1), shortcut keys ceased working. Further, configuration tool "Global Actions Manager" is empty/does not list shortcuts although file $HOME/.config/lxqt/globalkeyshortcuts.conf still exists and has proper content. Adding new shortcuts in config tool is also not working because all buttons are disabled. globalkeyshortcuts.conf has rw entitlements for user, group and others.
Possible Solution
Running out of ideas...
Steps to Reproduce (for bugs)
- User shortcut keys as before upgrade
- No action is taking place
Context
Trying to start apps as configured in globalkeyshosrtcuts.conf
System Information
- Distribution & Version: ArchLinux
- Kernel: 5.15.7-arch1-1 #1 SMP PREEMPT Wed, 08 Dec 2021 14:33:16 +0000 x86_64 GNU/Linux
- Qt Version:
- liblxqt Version: 1.0.0-1
- lxqt-build-tools Version:
- Package version:
Not reproducible.
Make sure you've upgraded to 1.0.0 properly, not partially. If you think a piece of info is missing, please add it.
I have a similar or maybe the same issue both on manjaro and arch, after an update, but not one from lxqt.
- At login a message is displayed saying "lxqt-panel: could not register shortcut for XF86.eject" or else like XF86-volume* ecc.
- it doesn't depend on WM in use
- in "Session settings" global shortcut module is not running
- when starting the module everything works, no error message, until next login.
- in manjaro VM it doesn't happen, so related to some setting probably
after an update, but not one from lxqt.
What do you mean by "not one from lxqt"?
An update from arch I suppose, because I didn't change anything, it's the "family" pc, did just updating, will check more now.
Until now I was guessing it's only me and my settings somehow.
On my debian laptop I installed also manjaro some day ago, and using the same home directory this issue showed up.
I have done a full system update, including everything of lxqt. Not sure what else to do.
Confirming stefonarch's finding: In Session Settings, Global Keyboards Shortcuts is ticket (enabled) but not running. Starting manually fixes the issue temporarily, i.e. during the session. Will address downstream at arch linux.
An update from arch I suppose
Strange! I have Manjaro Testing, update it regularly (an update came last night) and reboot it after updates. lxqt-globalkeys starts fine.
Is it possible that the problem is in Arch's package of lxqt-globalkeys (also used by Manjaro)? I use my own LXQt packages.
I rebooted Manjaro right now, after checking upgrades and finding none. lxqt-globalkeys started without problem.
We should find what causes this for you. Re-opening until it's found....
In the meantime I was testing on my arch machine.
- it's not reproducible always
- it happens more often at boot, restart session mostly works
- I've my own packages from git like tsujan
- on a fresh account I couldn't reproduce it, but maybe it would need only more trials
Settings for removable device plugin:
- show a menu
- do nothing
Volume plugin:
- alsa, the rest isn't relevant IMO
$ cat .config/lxqt/globalkeyshortcuts.conf
....
[XF86AudioRaiseVolume.67]
Comment=Aumenta il volume
Enabled=true
path=/panel/volume/up
[XF86AudioRaiseVolume.68]
Comment=Aumenta il volume
Enabled=true
path=/panel/volume2/up
[XF86Eject.69]
Comment=Eject removable media
Enabled=true
path=/panel/mount/eject
[XF86Eject.70]
Comment=Eject removable media
Enabled=true
path=/panel/mount2/eject
BTW cool that we can save notifications now :)
If I remember well I also tried once renaming globalkeyshortcuts.conf on manjaro, with no effect.
[2021-12-09T18:24:43+0100] [ALPM] upgraded qt5-base (5.15.2+kde+r257-1 -> 5.15.2+kde+r263-1)
EDIT: recompiled panel and globalshortcuts, similar errors with XF86*
The only difference I can see is ALSA instead of PulseAudio.
Anyway, your problem is not that lxqt-globalkeys doesn't start; it's about auto-starting. If you had a coredump inside /var/lib/systemd/coredump, we'd be able to investigate it. With no crash, I have no clue.
@stefonarch
This may be totally unrelated but could you retry by reversing https://github.com/lxqt/lxqt-globalkeys/pull/228/files? I never found time to read it.
I can confirm and reproduce this bug on Arch and Endeavour OS with LXQT, but not on Manjaro LXQT. (!?)
journalctl -b | grep -i global
lxqt-globalkeysd[957]: The X11 connection broke: No error (code 0)
lxqt-globalkeysd[957]: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
Showdesktop, xF86eject,Xf86Audioraisevolume cannot be registered error in Notifications
Shortcut keys (Global Actions Manager key bindings empty) , In Session settings Global keyboard shortcuts is not running,
but can be started manually.
First boot always results in this, reboot solves the issue .
It can be reproduced in a Virtulabox VM as well with fresh Arch install (2021 december iso) with LXQT.
Maybe related to collision with Openbox shortcut settings ?
~/.config/openbox/rc.xml
If LXDE is also installed
lxde-rc.xml is created, but no lxqt related config files like on Manjaro.
lxqt-globalkeysd[957]: The X11 connection broke: No error (code 0)
At least that explains why the daemon can't start. Now the question is why the X11 connection breaks on Arch.
Which display manager do you use on Arch and which is used on Manjaro LXQt?
I have this issue on Archlinux. It happenes since few days, last system update: yesterday. Manual start of global keys daemon solves it for one session.
Window manager: OpenBox
Please tell which window manager and display manager (aka. login manager) you use.
Do you all use Openbox as WM? What happens if you change it? Do you use LightDM, SDDM, or... for the display manager?
I couldn't reproduce the problem after 5 reboots. My display manager is SDDM. As for WM, I use sometimes KWin, sometimes compiz-reloaded. I don't have Openbox and my Manjaro Testing is up-to-date.
BTW, by chance, I saw that imlib2 was updated to 1.7.5-1. It's needed by Openbox. So, if all of you use Openbox, there may be an explanation.
Some answers from me:
- happens both with xfwm4 and openbox
- happens both with sddm and consolelogin+startx
I see this in manjaro:
lxqt-globalkeysd
[Notice] Started
[Notice] X11 error: type: 0, serial: 533, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Notice] X11 error: type: 0, serial: 535, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Notice] X11 error: type: 0, serial: 537, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Notice] X11 error: type: 0, serial: 539, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Warning] Cannot grab shortcut 'Shift+Alt+Tab'
[Notice] X11 error: type: 0, serial: 545, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Notice] X11 error: type: 0, serial: 547, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Notice] X11 error: type: 0, serial: 549, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Notice] X11 error: type: 0, serial: 551, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 1703
[Warning] Cannot grab shortcut 'Alt+Tab'
@stefonarch
I don't think those warning are related to this issue. It's possible that 'Shift+Alt+Tab' and 'Alt+Tab' are already consumed by another app (e.g., WM) in your case.
The problem that's described here is that lxqt-globalkeysd doesn't auto-start, probably because X11 breaks at some point (I said "probably" because only #247 (comment) shows it).
EDIT:
"Cannot grab shortcut...." is a message produced by lxqt-globalkeys when it can't grab a shortcut.
alt+tab doesn't matter IMO.
In manjaro Vbox I don't have this issue (yet?) and no X11 errors. Upgrading now.
Ok, I've nailed down something probably: In manjaro VM it never happened also after update, but it started doing it when adding a second panel on the left or right.
but it started doing it when adding a second panel on the left or right.
I have two panels :P
EDIT:
sudo pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Starting full system upgrade...
....
there is nothing to do
A shot in the dark:
@stefonarch
I searched the Internet for "The X11 connection broke: No error (code 0)" and, somewhere (I don't know where) I saw QT_AUTO_SCREEN_SCALE_FACTOR. Then I remembered a recent report about QT_AUTO_SCREEN_SCALE_FACTOR in Arch (lxqt/lxqt-config#401 (comment)).
Set QT_AUTO_SCREEN_SCALE_FACTOR to 0 (and, probably, QT_SCALE_FACTOR to 1.0) and see if it makes any difference.
The problem is that it is random, atm I cannot reproduce it at all anymore in manjaro VM. So this with the panels was coincident probably. Manjaro testing is more ahead, but still behind arch?
Manjaro testing is more ahead, but still behind arch?
It may not be related to that. If we assume that X11 breaks, it may be related to the graphic driver and an update that triggers the problem with it. We're still in the dark.
Did you test QT_AUTO_SCREEN_SCALE_FACTOR?
All cases of "The X11 connection broke: No error (code 0)" that I found on the Internet were about Qt. So, I searched in Qt's source and found it in src/plugins/platforms/xcb/qxcbconnection_basic.cpp → ioErrorHandler(), which is used in QXcbBasicConnection(). Hence my suggestion about QT_AUTO_SCREEN_SCALE_FACTOR.
Did you test
QT_AUTO_SCREEN_SCALE_FACTOR?
Yes, on my laptop where the bug is less random, and it still happens.
Weird enough the notifications about XF86* don't appear anymore, the icon about saved notifications appears late on the panel.
OK. For now, I've run out of ideas. If it happens here, I'll use pacman's cache to downgrade suspicious packages and test.
lxqt-globalkeysd[957]: The X11 connection broke: No error (code 0)
At least that explains why the daemon can't start. Now the question is why the X11 connection breaks on Arch.
Which display manager do you use on Arch and which is used on Manjaro LXQt?
SDDM is installed by default , but tried LightDM in Endeavour/Arch as well, no difference.
BTW, by chance, I saw that
imlib2was updated to 1.7.5-1. It's needed by Openbox. So, if all of you use Openbox, there may be an explanation.
You can easily reproduce the error in a VM running Endeavour / Arch LXQT , SDDM and Openbox is default.
Gonna try other WMs to see if I it makes any difference.
Tested with xfwm instead of openbox, no difference in Arch. First boot after power on it fails to start up, after reboot no error, it starts up fine.
In Manjaro stable it's OK, cannot reproduce even with 2 panels.
You can easily reproduce the error in a VM running...
Yes. But, because there's no trace of it here, if it happens, I might be able to find the package(s) responsible for it.
Up-to-date ArchlinuxARM running on Raspberrypi 4. I have stumbled upon this problem for the first time today (if I recall correctly, shortcut keys worked fine up until now following my last upgrade, which included LxQT 1.0).
I can confirm that QT_AUTO_SCREEN_SCALE_FACTOR=0 lxqt-globalkeysd works, whereas lxqt-globalkeysd results in The X11 connection broke: No error (code 0).
Edit: Running on Openbox, with LightDM as my display manager.
I tested QT_AUTO_SCREEN_SCALE_FACTOR=0 in /etc/environment and it looks working while having it in session settings > advaced there was no effect.
OK. If it's random, we'll need more time. Please add a comment if it happens with QT_AUTO_SCREEN_SCALE_FACTOR=0 in /etc/environment or command-line.
Nothing, maybe less but it still happens.
Googling the error [Notice] X11 error: type: 0, serial: 475, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 338
https://forums.debian.net/viewtopic.php?t=146875&start=15
lxqt/lxqt#1032 (comment)
Not tested with kwin yet, using xfwm4 atm.
Nothing, maybe less but it still happens.
Then, we can rule out QT_AUTO_SCREEN_SCALE_FACTOR, although setting it to 0 is good for Qt5 and it's deprecated with Qt6.
Googling the error [Notice] X11 error:....
Qt devs don't care about our log files. All of those warnings are useless, if not misleading. I've prevented Qt from babbling by adding this to ~/.config/QtProject/qtlogging.ini:
[Rules]
*.warning=false
EDIT:
As for https://forums.debian.net/viewtopic.php?t=146875&start=15, having so much garbage in log files can slow down I/O on slow HDDs. In addition to the above, one can link ~/.local/share/sddm/xorg-session.log (or another file with another display manager) to /dev/null and set MaxLevelStore, MaxLevelSyslog and MaxLevelKMsg to warning in /etc/systemd/journald.conf.
I can confirm the bug schijo described. Here are my test results:
~/.xprofileexport QT_AUTO_SCREEN_SCALE_FACTOR=0 export QT_SCALE_FACTOR=1.0- no change
/etc/environment
QT_AUTO_SCREEN_SCALE_FACTOR=0- no change
/etc/environmentQT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1.0lxqt-config-globalkeyshortcutsshowing up again
- Shutdown and restart machine
- bug persists
- Reboot
lxqt-config-globalkeyshortcutsshowing up again
Well, not quite a proper workaround...
Archlinux
LXQt version 1.0.0
Qt version 5.15.2
Well, not quite a proper workaround...
No. @stefonarch's observations also show that the removal of Qt scaling isn't effective. After all, it doesn't seem to be set in Arch by default.
We don't know the cause yet.
Shutdown and restart machine
- bug persists
Reboot
lxqt-config-globalkeyshortcutsshowing up again
Exactly the same. Also editing /etc/environment causes a hang on shutdown here.
kwin makes no difference too.
I noticed that it needs often to be restarted twice or even more in the GUI. So I disactivated the globalkeys module and enabled this dirty workaround.
/etc/xdg/autostart/lxqt-globalkeyshortcuts-fallback.desktop :
[Desktop Entry]
Type=Application
Exec=/usr/local/bin/globalkeyscheck
OnlyShowIn=LXQt;
X-LXQt-Module=true
Name=Globalkeys fallback
/usr/local/bin/globalkeyscheck :
#!/bin/bash
while :; do
sleep 5
if [[ -z $(ps -C lxqt-globalkeys -opid=) ]]; then
/usr/bin/lxqt-globalkeysd
fi
done
I can also confirm and reproduce this bug. After some investigation of pacman logs I can positively say that this is caused by recent libx11 update (1.7.2 -> 1.7.3 (1.7.3.1)).
The lxqt-globalkeys daemon stops crashing after downgrading to the old version:
https://archive.archlinux.org/repos/2021/12/01/extra/os/x86_64/libx11-1.7.2-1-x86_64.pkg.tar.zst
Since I am not a programmer, I cannot tell if this is a LXQt or Qt bug. Can somebody analyze libx11 changes (there's not much of them in recent release) and tell how this can affect lxqt-globalkeys? Or, maybe, you can figure out what is wrong and send a bug report to Qt/KDE?
Can confirm that sudo downgrade libx11 to 1.7.2 solves.
Thanks!
@avallach2000
Your comment was very informative. Thanks!
The lxqt-globalkeys daemon stops crashing...
If it really crashes, there should be a coredump. Please attach the backtrace if there's any.
BTW, although I can't reproduce the problem that's discussed here, after libx11 1.7.3.1-1, I started to see artifacts in Falkon — and only in Falkon. They are rare but, previously, Falkon never showed artifacts.
lxqt-globalkeysd does not actually crash, it just exits normally with exit code 1. And it doesn't happen all the time. Sometimes daemon starts and stay running (maybe some race condition?).
I built a debug version, but because there's no actual crash this is the best I can do:
(gdb) break exit
Function "exit" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (exit) pending.
(gdb) run
Starting program: /usr/bin/lxqt-globalkeysd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff2c64640 (LWP 23364)]
[New Thread 0x7ffff1419640 (LWP 23365)]
[New Thread 0x7ffff0c18640 (LWP 23366)]
The X11 connection broke: No error (code 0)
X connection to :0 broken (explicit kill or server shutdown).
[Switching to Thread 0x7ffff0c18640 (LWP 23366)]
Thread 4 "Core" hit Breakpoint 1, 0x00007ffff6dad630 in exit () from /usr/lib/libc.so.6
(gdb) backtrace
#0 0x00007ffff6dad630 in exit () at /usr/lib/libc.so.6
#1 0x00007ffff7e9c8f2 in _XDefaultIOError () at /usr/lib/libX11.so.6
#2 0x00007ffff7e9cbff in _XIOError () at /usr/lib/libX11.so.6
#3 0x00007ffff7e8b609 in XPeekEvent () at /usr/lib/libX11.so.6
#4 0x0000555555568ad1 in Core::runEventLoop(unsigned long) (this=0x7fffffffdd90, rootWindow=414)
at /usr/src/debug/lxqt-globalkeys-1.0.0/daemon/core.cpp:1032
#5 0x000055555556a06b in Core::run() (this=0x7fffffffdd90) at /usr/src/debug/lxqt-globalkeys-1.0.0/daemon/core.cpp:1003
#6 0x00007ffff723b02f in () at /usr/lib/libQt5Core.so.5
#7 0x00007ffff65ab259 in start_thread () at /usr/lib/libpthread.so.0
#8 0x00007ffff6e6c5e3 in clone () at /usr/lib/libc.so.6
Hope it helps.
Hope it helps.
As far as I understand it, _XIOError terminates the app with the exit code 1; hence, no crash. I may be wrong but I don't think we can do anything about it; it's a new bug in X11. I hope X11 devs know about it; otherwise, someone with enough knowledge of X11 should report it.
I also think that the graphics driver may have a role. I have Intel and sometimes use modesetting (with KWin), sometimes the Intel driver + DRI2 (with compiz-reloaded)
I see it both with intel and AMD.
@tsujan
Many thanks for your explanation.
About reproducibility. I have this issue on two Intel PCs (Apollo Lake and Coffee Lake) and inside a Virtualbox VM. (all three - recent Arch Linux with no particular GPU driver configuration, just using default settings - kms as far as I know).
Also, I managed to reproduce this issue even in Lubuntu 21.10 live session. As it turned out, all you need is to compile libx11 >= 1.7.3, install it and re-login. If somebody wants to try it out, here's the recipe:
- Get Lubuntu 21.10 ISO-image: http://cdimage.ubuntu.com/lubuntu/releases/21.10/release/
- Setup a Virtualbox or VMware VM (I've tried both) with at least 3(!) gigs of RAM
- Boot VM to ISO
- Run the following script (I know it's barbaric):
#!/bin/sh
set -e
sudo apt update
sudo apt install -y build-essential pkg-config libxcb1-dev x11proto-dev xtrans-dev
wget https://www.x.org/releases/individual/lib/libX11-1.7.3.1.tar.xz
tar xvf libX11-1.7.3.1.tar.xz
cd libX11-1.7.3.1/
./configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu
make -j$(nproc)
sudo make install
loginctl terminate-user $(whoami) # logoff
- Press Return in login prompt (live session has empty password)
- You'll see some lxqt-panel notifications about shortcuts that cannot be registered. And this not a conflict with window manager, because
pgrep lxqt-globalkeysdreturns nothing. - If lxqt-globalkeysd was started normally, open terminal and do
pkill lxqt-globalkeysd ; lxqt-globalkeysda couple of times. The X11 error should appear at least once out of five or so.
@avallach2000
I don't want to bother you with more tests but, only if you find the time, could you reverse this commit and test again: https://github.com/freedesktop/xorg-libX11/commit/93a050c3ad2d2264d3880db3791387b1a9bf2e9e
@tsujan
I've tried your suggestion - you're right, this particular commit causes our issue.
Also, here is slightly more informative backtrace from libx11 w/ debug symbols:
#0 0x00007ffff6db8630 in exit () at /usr/lib/libc.so.6
#1 0x00007ffff7ea8086 in _XDefaultIOError (dpy=0x7fffe8004a10) at XlibInt.c:1317
#2 0x00007ffff7ea8393 in _XIOError (dpy=dpy@entry=0x7fffe8004a10) at XlibInt.c:1548
#3 0x00007ffff7ea5afd in _XReadEvents (dpy=dpy@entry=0x7fffe8004a10) at xcb_io.c:487
#4 0x00007ffff7e96a69 in XPeekEvent (dpy=0x7fffe8004a10, event=0x7ffff1790bd0) at PeekEvent.c:46
#5 0x0000555555568d01 in Core::runEventLoop(unsigned long) (this=0x7fffffffde80, rootWindow=379) at /usr/src/debug/lxqt-globalkeys-1.0.0/daemon/core.cpp:1032
#6 0x000055555556a2db in Core::run() (this=0x7fffffffde80) at /usr/src/debug/lxqt-globalkeys-1.0.0/daemon/core.cpp:1003
#7 0x00007ffff724602f in () at /usr/lib/libQt5Core.so.5
#8 0x00007ffff65b6259 in start_thread () at /usr/lib/libpthread.so.0
#9 0x00007ffff6e775e3 in clone () at /usr/lib/libc.so.6
@avallach2000, Thank you very much!
Now, the question is: How can we work around this new problem, especially in a backward compatible way?
@tsujan what do u think of making lxqt-session try to restart modules once or twice when they fail?
lxqt-session try to restart modules once or twice when they fail?
It already does — 5 times — but, in this case, it can't do anything. The app is terminated by X11 (for those who can reproduce the problem).
Let's hope this issue is temporary. I didn't find any problem in lxqt-globalkeys → core.cpp. We need XPeekEvent and the way it's used in core.cpp seems valid to me.
Let's hope this issue is temporary.
I'm sorry but I have to disagree. After running ltrace, it looks like race condition occurs when threads lock/unlock access to xorg ?socket?. Please, can you inspect attached ltrace logs, maybe you'll figure out what is wrong in there.
truly impressed on the effort put into this issue which I thought to be unique to me. thx vm and sorry, I cannot be of help
@avallach2000 @tsujan Glad to hear I'm out of the game because of late refactoring efforts… :)
However I actually noticed the behaviour just yesterday (from a user's viewpoint -> shortcuts "all gone"). Restarting the daemon from session settings recovers cleanly. Since I started cleaning up this badly written piece of code I know races can occur. In worst case I had several situations ending up with a deleted config. When developing on this make sure you have a backup config. At this point I like to suggest merging fully functional #233 as a primer. In it's current form this greatly helps with debugging the code. Unfortunately I don't have any time to continue the work. But yeah: The thread is really shitty and I bet we can replace it with a simple timer instead of "sleeping" in an endless loop…
EDIT: Sorry by "fully functional" I mean "the code doesn't break anything". The planned "feature" still isn't working (therefore the "draft" status).
@tsujan @avallach2000 Unfortunately the backtrace doesn't resolve to the exact location. Had a look into PeekEvent.c leading to _XReadEvents -> https://github.com/freedesktop/xorg-libX11/blob/93a050c3ad2d2264d3880db3791387b1a9bf2e9e/src/xcb_io.c#L487
From two possible locations this is very likely the one leading to the race condition (-> _XDefaultIOError). Contrary to basically any other X11 call we do not lock our mutex for both XPeekEvent and XNextEvent.
@antis81, yes, I came to the same conclusion about that location.
If you have a patch, I think @avallach2000 and @stefonarch could test it — I can't because I don't see the issue here, after ~10 cold boots and several reboots.
Good to see that you're looking into it.
One of the issues here is core.cpp#L442.
Something like this may help in the short run:
QApplication app;
Core c;
QMetaObject::invokeMethod(&c, "start", Qt::QueuedConnection); // async call (that's why QThread::start() is a slot)
//…
return app.exec(); // run QEventLoopFirst: I realize that the folder "daemon" had gone here, no idea why and when. Did a fresh git clone and compile.
EDIT: looks like git checkout -b testing - existed and had no "daemon" folder.
Second: how exactly apply this patch to core.cpp?
@tsujan Can you please confirm our "X event pipe" is not initialized correctly? You may want to have a look into QThread code. Since QThread::start implicitly calls QThread::run the pipe is "randomly" initialized at the point when XPeekEvent is called. This is definitely one of our issues here. Moving "start" out of the constructor is mandatory! 😸
@antis81
I've tested your patch. Sorry, but I don't see much difference. Sometimes it still fails (at least once out of ten). It can be said that nothing has changed.
I'm not sure, but after some tracing it seems that crash occurs when XPeekEvent is called right at the same time (or, maybe, a bit later) when wakeX11Thread sends dummy event with XSendEvent. In this case, XPeekEvent causes
XIO: fatal IO error 25 (Inappropriate ioctl for device) on X server ":0"
after 122 requests (122 known processed) with 0 events remaining.
When the daemon starts normally, XPeekEvent is always called before wakeX11Thread. Can this be right?
Also, don't know why, but I see the actual XIO error message only when running daemon from QtCreator. Is there any envvars for that?
I've done a dirty shell script for testing purposes: testrun.txt.
Also discovered a segmentation fault on XFlush() call: coredump.txt (EDIT: applies for both patched and unpatched versions).
Just saw a report on reddit, with the added info that kglobalaccel also fails after some time..
https://www.reddit.com/r/archlinux/comments/rm2jjq/shortcuts_not_working_lxqt_in_a_vm/
I was always thinking what the hidden factor on @tsujan 's setup might be that he can't reproduce the issue. Could be kwin + kglobalsaccel+ maybe some else from KDE ?
BTW this was the second report on reddit.
I was always thinking what the hidden factor on @tsujan 's setup might be that he can't reproduce the issue. Could be kwin + kglobalsaccel+ maybe some else from KDE ?
No, it isn't, because I'm using compiz-reloaded for a week. kglobalaccel doesn't start without KWin and I don't use any KDE app that starts it — I've even disabled KDE plugins of Qt Designer.
I have no idea why I can't see the problem here. If it's related to the above-mentioned commit in libx11, I should see it too, but I don't.
@tsujan
Could you run my testing script which is trying to run and stop the daemon until it breaks? By the way, I've tested kglobalaccel5 with the script and can confirm that it is also broken in the same way as the lxqt-globalkeysd. Same error. Things become more and more interesting.
EDIT: Maybe it's time to ask xorg devs about this issue?
EDIT2: Sorry for false alarm.
My lxqt-globalkeys is rock-solid ;) No crash, no termination. Why? I don't know. But let's not complicate this problem more than it is.
The fact is that, after https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/93a050c3ad2d2264d3880db3791387b1a9bf2e9e, lxqt-globalkeys is terminated with the exit code 1 for many users. I couldn't find an invalid usage of X11 functions in our code. Xlib manual doesn't seem to tell otherwise, but I'm not an expert in Xlib.
If the problem is in lxqt-globalkeys, we should be able to tell exactly where and why. That will automatically lead to a fix.
Such an explanation might not be needed if an efficient workaround is found. Can we skip XPeekEvent? Can we use it in another way? etc. However, searching for a workaround presupposes that the root of the bug is outside the app.
what wil happend if it the modules of lxqt-session starts after the panel start up? or a option wait for panel first...
curius ..
Thought I wrote it already here my workaround (delay and repeating) but can't find it
/etc/xdg/autostart/lxqt-globalkeyshortcuts-fallback.desktop
[Desktop Entry]
Type=Application
Exec=/usr/local/bin/globalkeyscheck
OnlyShowIn=LXQt;
X-LXQt-Module=true
/usr/local/bin/globalkeyscheck
#!/bin/bash
while :; do
sleep 5
if [[ -z $(ps -C lxqt-globalkeys -opid=) ]]; then
/usr/bin/lxqt-globalkeysd
fi
done
@tsujan
You mentioned
I started to see artifacts in Falkon — and only in Falkon.
Could you be more specific of exactly what visual phenomena you saw? I may have noticed something similar in Firefox.
Just wondering...
Could you be more specific of exactly what visual phenomena you saw?
The browser view or a part of it was suddenly scrambled — sometimes it showed black zigzags. Changing of tabs restored the view. It was independent of WM and happened with both modesetting and Intel drivers.
After xorg-server was upgraded to 21.1.2 and mesa to 21.3.1, the problem almost disappeared; at least, it isn't as intense as before.
EDIT: I'd never encountered it in Falkon before.
WARNING: What follows is a shot in the drak.
Since I still think we can't do anything about XIOError, and because the daemon doesn't crash, what about the following patch for lxqt-session?
diff -ruNp lxqt-session-orig/lxqt-session/src/lxqtmodman.cpp lxqt-session/lxqt-session/src/lxqtmodman.cpp
--- lxqt-session-prerelease/lxqt-session/src/lxqtmodman.cpp
+++ lxqt-session/lxqt-session/src/lxqtmodman.cpp
@@ -273,7 +273,7 @@ void LXQtModuleManager::startConfUpdate(
startProcess(desktop);
}
-void LXQtModuleManager::restartModules(int /*exitCode*/, QProcess::ExitStatus exitStatus)
+void LXQtModuleManager::restartModules(int exitCode, QProcess::ExitStatus exitStatus)
{
LXQtModule* proc = qobject_cast<LXQtModule*>(sender());
if (nullptr == proc) {
@@ -288,7 +288,9 @@ void LXQtModuleManager::restartModules(i
{
case QProcess::NormalExit:
qCDebug(SESSION) << "Process" << procName << "(" << proc << ") exited correctly.";
- break;
+ if (exitCode == 0)
+ break;
+ /* Falls through. */
case QProcess::CrashExit:
{
qCDebug(SESSION) << "Process" << procName << "(" << proc << ") has to be restarted";
Nice shot I'd say.
First restart of the session one message popped up about XF86...not registered, but then shortcuts worked, then
2 reboot and 4 session restarts without issues.
then 2 reboot and 4 session restarts without issues.
Good to know that. Please also make sure it doesn't have a side effect. Can you stop the process from LXQt Session Settings?
BTW, this is similar to your workaround. The difference is that the user should be able to stop the process cleanly, from LXQt Session Settings.
lxqt-session restarts crashed modules up to 5 times. Previously, I thought it also restarted terminated modules with the exit code 1 (not crashed but exited "unsuccessfully") but, for some reason, exitCode was ignored by the code.
Can you stop the process from LXQt Session Settings?
Yes, working fine, looks still fine all.
If it proves to be working in the long run, and if it's approved by LXQt devs, we might be able to make a point release for lxqt-session. I still hope that this problem is temporary, but considering exitCode seems logical to me regardless of it.
As I mentioned in another thread I employed the workaround stefonarch posted to good effect. I would like to try the workaround tsujan proposes too, but I am not familiar with lxqt development and do not know how to employ it. Stefonarch gave clear instructions about what files to create and what to put in them. I would be grateful if someone could give similar clarity on the tsujan workaround as well if possible. Thanks.
I would be grateful if someone could give similar clarity on the tsujan workaround as well if possible. Thanks.
You'd need to a) apply the changes to the source code file mentioned and b) then recompile lxqt-session
This is not easy if your not familiar with compiling from source code.
Thanks. I see myself as an LXQt well-wisher and implementer rather than developer. I've compiled some apps from source but certainly wouldn't call myself familiar enough with either compiling or LXQt to confidently implement tsujan's solution. Plus there was talk of including it in a future release anyway, or perhaps an improved version. In the meantime stefonarch's solution seems to work well for the time being. I haven't applied it to the computer I'm typing this on now, and out of the last four logins three have been okay with no keyboard shortcut problems but one hasn't been. I'll see if the fix helps.
I do have a question. If tsujan's fix becomes part of a future release, will stefonarch's fix conflict?
I do have a question. If tsujan's fix becomes part of a future release, will stefonarch's fix conflict?
As it generates a second module "fallback" in session configuration you could disable it, but it won't be needed anymore so just removing the file from autostart is better.
Just saw a report on reddit, with the added info that
kglobalaccelalso fails after some time..
https://www.reddit.com/r/archlinux/comments/rm2jjq/shortcuts_not_working_lxqt_in_a_vm/
Never knew I'd find my reddit post here lmao.
In case this helps, someone told me to "Downgrade that package ('lxqt-globalshortcuts') to 1.7.2 and you'll have them back." on my post. However, I couldn't really find that package.
someone told me to "Downgrade that package ('lxqt-globalshortcuts') to 1.7.2
No, he/she meant libx11.
No, he/she meant libx11.
I probably misread, sorry. I'd try downgrading libx11 and see if anything happens
@tsujan to replicate can u add a new panel (or use an existing one) and add a LOT of mainmenu plugins? i tried here in a VM (VirtualBox) and it fails on almost every reboot (usually first boot doesn't).
like this:
vm config:
@slidinghotdog
When I say I don't see the problem here, I mean on this laptop, which has up-to-date Manjaro testing and is the computer that I use. Otherwise, most probably, I could see the problem with a VM. I haven't tried a VM but what would be the point if I did? We already know that the problem exists and is caused by the above-mentioned commit in libx11.
what would be the point if I did?
To make it easier to test fixes/workarounds.
Hi I have exactly the same issue here. Archlinux x64 (Linux 5.15.11-arch2-1), LXQT 1.0.0.
On my system, lxqt-globalkeysd just doesn't start on LXQT loading. And then no hotkey are working. But, I can start it manually in the LXQT's session settings, and then the hotkeys are working again.
So, my working workarround is to add lxqt-globalkeysd to the global application autostart (still in the LXQT's session settings). It's a little dirty, but working. I'll remove it when this issue will get fixed.
lxqt/lxqt-session#406 has been merged. A point release might be made but it would be very appreciated if you could test that commit and tell us if it prevents the issue for you (although it isn't a workaround for this specific X11 issue).
journalctl -b|grep global
one cold boot (1 restart), one relogin (3 restarts, with error messages notifications seen):`
dic 28 08:32:10 vito kernel: Kprobes globally optimized
dic 28 08:32:23 vito lxqt-session[861]: lxqt-session: start "/etc/xdg/autostart/lxqt-globalkeyshortcuts.desktop"
dic 28 08:32:24 vito lxqt-globalkeysd[969]: The X11 connection broke: No error (code 0)
dic 28 08:32:24 vito lxqt-globalkeysd[969]: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
dic 28 08:32:24 vito lxqt-session[861]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55baaba6d680) ) exited correctly.
dic 28 08:32:24 vito lxqt-session[861]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55baaba6d680) ) has to be restarted
......
.....
dic 28 08:55:46 vito lxqt-session[861]: lxqt-session: Module logout "lxqt-globalkeyshortcuts.desktop"
dic 28 08:55:52 vito lxqt-session[10005]: lxqt-session: start "/etc/xdg/autostart/lxqt-globalkeyshortcuts.desktop"
dic 28 08:55:54 vito lxqt-globalkeysd[10088]: The X11 connection broke: No error (code 0)
dic 28 08:55:54 vito lxqt-globalkeysd[10088]: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
dic 28 08:55:54 vito lxqt-session[10005]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55db92f88ea0) ) exited correctly.
dic 28 08:55:54 vito lxqt-session[10005]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55db92f88ea0) ) has to be restarted
dic 28 08:55:54 vito lxqt-globalkeysd[10322]: The X11 connection broke: No error (code 0)
dic 28 08:55:54 vito lxqt-globalkeysd[10322]: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
dic 28 08:55:54 vito lxqt-session[10005]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55db92f88ea0) ) exited correctly.
dic 28 08:55:54 vito lxqt-session[10005]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55db92f88ea0) ) has to be restarted
dic 28 08:55:54 vito lxqt-globalkeysd[10366]: The X11 connection broke: No error (code 0)
dic 28 08:55:54 vito lxqt-globalkeysd[10366]: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
dic 28 08:55:55 vito lxqt-session[10005]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55db92f88ea0) ) exited correctly.
dic 28 08:55:55 vito lxqt-session[10005]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55db92f88ea0) ) has to be restarted
"...has to be restarted" at the bottom shows that it has been started at last. Correct?
BTW, if you use the final patch (which is in git now), you'll see ...exited with code... instead of ...exited correctly. If the code is 0, the exit is correct (may have been done manually); if it's 1, there was a failure and the module will be restarted. In your case, it's 1.
I didn't remember if I had compiled after the last commit to the branch, it looks so. Now
dic 28 10:31:57 vito lxqt-session[21746]: lxqt-session: start "/etc/xdg/autostart/lxqt-globalkeyshortcuts.desktop"
dic 28 10:31:58 vito lxqt-globalkeysd[21850]: The X11 connection broke: No error (code 0)
dic 28 10:31:58 vito lxqt-globalkeysd[21850]: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
dic 28 10:31:58 vito lxqt-session[21746]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55cb3554f8a0) ) exited with code 1
dic 28 10:31:58 vito lxqt-session[21746]: lxqt-session: Process "Scorciatoie globali della tastiera" ( LXQtModule(0x55cb3554f8a0) ) has to be restarted
......
dic 28 10:34:14 vito lxqt-session[21746]: lxqt-session: Module logout "lxqt-globalkeyshortcuts.desktop"
dic 28 10:34:21 vito lxqt-session[23637]: lxqt-session: start "/etc/xdg/autostart/lxqt-globalkeyshortcuts.desktop"
I just tried downgrading libx11 to 1.7.2 and followed T0MuX's solution:
On my system, lxqt-globalkeysd just doesn't start on LXQT loading. And then no hotkey are working. But, I can start it manually in the LXQT's session settings, and then the hotkeys are working again.
So, my working workarround is to add lxqt-globalkeysd to the global application autostart (still in the LXQT's session settings). It's a little dirty, but working. I'll remove it when this issue will get fixed.
and it worked, I could access shortcuts after that.
I took another look at our code and also at the suspicious libx11 patch. I don't want to mislead anyone with my poor knowledge of X11 but I think that the problem happens in the 10 ms that checkX11Error() waits for X11 error after Core::wakeX11Thread() calls XSendEvent(). Before the libx11 patch, _XReply (in libx11's source file xcb_io.c) called ConditionWait(); now it may call _XIOError().
To test the above-mentioned hypothesis, you could try this:
diff -ruNp lxqt-globalkeys-orig/daemon/core.cpp lxqt-globalkeys/daemon/core.cpp
--- lxqt-globalkeys-orig/daemon/core.cpp
+++ lxqt-globalkeys-20211025/daemon/core.cpp
@@ -975,7 +975,7 @@ void Core::wakeX11Thread()
lockX11Error();
XSendEvent(mDisplay, mInterClientCommunicationWindow, 0, 0, reinterpret_cast<XEvent *>(&dummyEvent));
- checkX11Error();
+ checkX11Error(LOG_NOTICE, 0);
XFlush(mDisplay);
}
}
WARNING: I didn't think about probable side effects. Back up ~/.config/lxqt/globalkeyshortcuts.conf.