Shortcuts Ignored After Upgrade about lxqt-globalkeys HOT 136 CLOSED

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 .

from lxqt-globalkeys.

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

from lxqt-globalkeys.

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'

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

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?

https://github.com/freedesktop/xorg-libX11/compare/f906fe8e9769e4313294b68e61c402610ade69da..4c96f3567a8d045ee57b886fddc9618b71282530

from lxqt-globalkeys.

No, he/she meant libx11.

I probably misread, sorry. I'd try downgrading libx11 and see if anything happens

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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

from lxqt-globalkeys.

after an update, but not one from lxqt.

What do you mean by "not one from lxqt"?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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....

from lxqt-globalkeys.

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 :)

from lxqt-globalkeys.

If I remember well I also tried once renaming globalkeyshortcuts.conf on manjaro, with no effect.

from lxqt-globalkeys.

[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*

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

It can be reproduced in a Virtulabox VM as well with fresh Arch install (2021 december iso) with LXQT.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

alt+tab doesn't matter IMO.
In manjaro Vbox I don't have this issue (yet?) and no X11 errors. Upgrading now.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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?

from lxqt-globalkeys.

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?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

I can confirm the bug schijo described. Here are my test results:

1. ~/.xprofile

   export QT_AUTO_SCREEN_SCALE_FACTOR=0
   export QT_SCALE_FACTOR=1.0
   

   • no change
2. /etc/environment
QT_AUTO_SCREEN_SCALE_FACTOR=0
   • no change
3. /etc/environment

   QT_AUTO_SCREEN_SCALE_FACTOR=0
   QT_SCALE_FACTOR=1.0
   

   • lxqt-config-globalkeyshortcuts showing up again
4. Shutdown and restart machine
   • bug persists
5. Reboot
   • lxqt-config-globalkeyshortcuts showing up again

Well, not quite a proper workaround...

Archlinux
LXQt version 1.0.0
Qt version 5.15.2

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

• Shutdown and restart machine

  • bug persists

• Reboot

  • lxqt-config-globalkeyshortcuts showing up again

Exactly the same. Also editing /etc/environment causes a hang on shutdown here.
kwin makes no difference too.

from lxqt-globalkeys.

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

from lxqt-globalkeys.

Can confirm that sudo downgrade libx11 to 1.7.2 solves.
Thanks!

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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)

from lxqt-globalkeys.

I see it both with intel and AMD.

from lxqt-globalkeys.

@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:

1. Get Lubuntu 21.10 ISO-image: http://cdimage.ubuntu.com/lubuntu/releases/21.10/release/
2. Setup a Virtualbox or VMware VM (I've tried both) with at least 3(!) gigs of RAM
3. Boot VM to ISO
4. 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

4. Press Return in login prompt (live session has empty password)
5. You'll see some lxqt-panel notifications about shortcuts that cannot be registered. And this not a conflict with window manager, because pgrep lxqt-globalkeysd returns nothing.
6. If lxqt-globalkeysd was started normally, open terminal and do pkill lxqt-globalkeysd ; lxqt-globalkeysd a couple of times. The X11 error should appear at least once out of five or so.

from lxqt-globalkeys.

@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

from lxqt-globalkeys.

@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

from lxqt-globalkeys.

@avallach2000, Thank you very much!

Now, the question is: How can we work around this new problem, especially in a backward compatible way?

from lxqt-globalkeys.

@tsujan what do u think of making lxqt-session try to restart modules once or twice when they fail?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

@tsujan

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.

ltrace5.log
ltrace6.log

from lxqt-globalkeys.

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

from lxqt-globalkeys.

@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).

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

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 QEventLoop

from lxqt-globalkeys.

First: 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?

from lxqt-globalkeys.

@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! 😸

from lxqt-globalkeys.

@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?

from lxqt-globalkeys.

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).

from lxqt-globalkeys.

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/

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

what wil happend if it the modules of lxqt-session starts after the panel start up? or a option wait for panel first...
curius ..

from lxqt-globalkeys.

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

from lxqt-globalkeys.

@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...

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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";

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

Can you stop the process from LXQt Session Settings?

Yes, working fine, looks still fine all.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

@kendew Would you mind to try #248 and verify the error is ignored?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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?

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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/

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.

from lxqt-globalkeys.

someone told me to "Downgrade that package ('lxqt-globalshortcuts') to 1.7.2

No, he/she meant libx11.

from lxqt-globalkeys.

@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:

from lxqt-globalkeys.

@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.

from lxqt-globalkeys.

what would be the point if I did?

To make it easier to test fixes/workarounds.

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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).

from lxqt-globalkeys.

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

from lxqt-globalkeys.

"...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.

from lxqt-globalkeys.

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"

from lxqt-globalkeys.

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.

from lxqt-globalkeys.

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().

from lxqt-globalkeys.

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.

from lxqt-globalkeys.