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?

However an actual deadlock situation could be in this case block on mDataMutex.

That may also be possible.

I can't work in this way; should find a computer with which I can see the problem firsthand. Working with VMs is painful because they're too slow. My old computer hasn't been updated for 6 months and I prefer to keep it that way for comparison (has been useful on many occasions). I might patch its libx11 if I find the time.

OK. On my older laptop (Asus — this one is Lenovo), I applied the suspicious patch to libx11 1.7.2, recompiled and installed the latest lxqt-globalkeys, added 10 instances of main menu (as @slidinghotdog had suggested), and did NOT use lxqt/lxqt-session#406. Then I did 8 cold boots, two reboots and several logouts — I removed ~/.config/lxqt/globalkeyshortcuts.conf with the last three boots. In all cases, lxqt-globalkeys started correctly.

There is an unknown factor.

EDIT: The unknown factor may be that both computers are powerful gaming laptops.

Good news:
After adding 20 instances of main menu, I was able to reproduce the issue by stopping the daemon, logging out and logging in :) About 3 attempts out of 4 resulted in exit(1).

Bad news:
I freely tested my wildest ideas but none of them worked.

Lxqt-Session 1.0.1 is released; it restarts the module on exit(1). When it comes to your distro, please remove any other workaround that you may have used for this issue.

Most probably, the issue isn't caused by our code but we'll do our best to make sure of that or circumvent it in lxqt-globalkeys itself.

@stefonarch, @avallach2000, @antis81
Desperate times call for desperate measures. At last, one of my experiments was 100% successful, although I don't understand why.

First, I put log(LOG_NOTICE, "haha"); immediately before XPeekEvent (don't ask why):

By doing so, I succeeded in reproducing the issue inside the session and after startup. Almost every time I started lxqt-globalkeysd in QTerminal, it exited with code 1. Replacing log(LOG_NOTICE, "haha"); with qDebug("haha"); had the same effect.

Then, understandably, I just changed

To

void Core::log(int level, const char *format, ...) const
{ return;

After that, I haven't had a single instance of exit(1).

If anyone has an explanation, I'm all ears.

Negative... 2 restarts → always errors messages, 4 session restarts 1 error.

Negative... 2 restarts → always errors messages, 4 session restarts 1 error.

OK, it happened to me too, after 15 or 16 tries. Still, I don't understand why log(LOG_NOTICE, "haha"); or qDebug("haha"); before XPeekEvent makes it almost always exit with 1, even without restarting the session.

The aforementioned observation lead me to this (which is probably used for debugging):

So, I changed it to (I could have commented it out too):

XSynchronize(mDisplay, False);

I can't trust my magical system but no exit(1) after 8 boots. Sorry, I'm tired of so many startups...

@tsujan

XSynchronize(mDisplay, False);

It seems to work, but I'm unsure about side-effects this may cause.
More than a hundred successful launches (!) in my test VM — that means something, right?

@tsujan, @avallach2000 Actually no need to call XSynchronize. XOpenDisplay should do this job perfectly!

EDIT: With this change in #248 XFlush now also does have an effect (leaving it out deadlocks)!
EDIT 2: And… those suspicious async line breaks in the log aree also gone!

One reboot and 2 relogin without errors with only that change here.

Actually no need to call XSynchronize. XOpenDisplay should do this job perfectly!

@antis81 , yes. As I mentioned, commenting out is enough.

@avallach2000, @stefonarch
If it fixes the problem for you, it should fix it for all :)

but I'm unsure about side-effects this may cause.

As far as I know, it shouldn't have any side effect. XSynchronize was used for debugging. I haven't seen it in other codes.

I'll make a PR and try to explain the situation in it.

Last but not least, obstinacy pays off ;) Thank you all.

if true; then a good start in the new year for LXQt :)

if true; then a good start in the new year for LXQt :)

The end result seems good; the whole process was a nightmare that apparently ended with 2021 ;)

Or simply merge #248. :)

On many occasions, we need to check previous commits. Therefore, we should keep the changes as pertinent as possible. In this case, only the removal of synchronization was needed.

In general, unnecessary code changes should be avoided.

In general, unnecessary code changes should be avoided.

lxqt-globalkeysd is such an unnecessary piece of code I'm not going to waste any more time :)

I run Manjaro and was having the issue on almost every reboot. I noticed it was possible to start lxqt-globalkeysd after the desktop was up and then everything would work.
That led to a temp solution that has worked 99.9% of the time. It might help people while they wait for the fix to make it to the repositories. First I created a script and placed it in /usr/bin as "startgkey" and made it executable.

#!/bin/bash
sleep 10
lxqt-globalkeysd

Then I edited 2 lines in /etc/xdg/autostart/lxqt-globalkeyshortcuts.desktop to

# TryExec=lxqt-globalkeysd
Exec=startgkey

So far its worked on every reboot (about 20) except 1 when it was at sleep 5 so I boosted that to 10.

Tomorrow the fix will be merged probably, so lxqt-globalkeys-1.0.1 should show up soon in your updates.

Yes, we agreed on testing the fix (which is already in git) for a week before putting it in lxqt-globalkeys-1.0.1. Perhaps we were overcautious but we'll release it tomorrow. It'll quickly appear among the updates of Arch and then Manjaro.

I have the same issue, I think the issue appeared with 1.0.0.4, but is still there with 1.0.1-1
archlinux based EndeavourOS
running it manually doesn't fix it:

$ lxqt-globalkeysd
The X11 connection broke: No error (code 0)
X connection to :0 broken (explicit kill or server shutdown).
QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread

$ sudo lxqt-globalkeysd
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[Critical] Cannot register service 'org.lxqt.global_key_shortcuts'
[Notice] Stopped

Dunno right now about XDG_RUNTIME_DIR, I'm not used to debug it atm...

EDIT:
aaaah, sorry!
I thought it was installed yesterday (I did a big paru round) - it was not!

@Loader009
This problem is definitely fixed in lxqt-globalkeys 1.0.1.

Yes, my fault, I thought it was installed yesterday - I noticed with pacman -Qi that it was still an older version. - sorry!

It's OK. To see the change, a logout and login is also needed.