Hotkeys do not work on certain keyboard mappings...

[ManuelSchneid3r]

I recognized that several hotkeys do not work on my machine (arch linux, xorg-server 1.18.1). I even encountered a segfault. The problematic line is native = keycodes.data()[0];. When there is no keycode this will result in a segfault.

I debugged the code and realized that the keys reported by the nativeEventFilter are different from the ones that I wanted to be grabbed before via xcb_grab_key_checked. The reason why my hotkey has no effect, is that the key reported by the nativeEventFilter is the one in keycodes.data()[1]. keycodes.data()[0] is adiaeresis (german Ä). Now I know that after registering Alt+Y, I can open zeal by pressing Alt+Ä.

Well I printed my keycode mapping like this (xmodmap -pke does it as well)

for (int cc =0 ; cc<256; ++cc){
    qDebug() << cc << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,0))
             << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,1))
    << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,2))
    << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,3))
    << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,4))
    << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,6))
    << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,7))
    << XKeysymToString(xcb_key_symbols_get_keysym(xcbKeySymbols,cc,8));
}

which looks like this (snippet)

48 adiaeresis Adiaeresis y Y dead_circumflex at Greek_upsilon period
49 dead_circumflex degree dead_circumflex dead_caron U2032 U21BB U02DE dead_abovedot
50 Shift_L  Shift_L Caps_Lock    
51 numbersign apostrophe ISO_Level3_Shift  rightsinglequotemark   
52 y Y udiaeresis Udiaeresis guillemotright numbersign  Escape

And, yes, keysym Y (keycode 52 on my keyboard) is listed in the mapping of keycode 48 ( keysym Ä on my keyboard)... I stopped here working on this. Well this stuff is boring and annoying. Even xcb itelf states

At the moment, XCB implements only a basic and incomplete sets of keyboard functions. Therefore, it greatly restricts the usages of XCB in "real-world" applications and duplicate the efforts as most applications ported to XCB so far (such as Awesome Window Manager, VLC and others) have to write their own implementation, which is often incomplete and buggy as it is rather tricky to implement properly and entirely.

I wish nobody to have to do this again, so I want to ask, if you are willing to make some kind of qxt-community organization (or soimething like that, doesnt have to be qxt). Qxt has been discontinued and there are several projects that are maintaining qxtglobalshortcut on their own, e.g. CopyQ, zeal, albert (mine, partially). If we'd unite our effort we could have more stability for less effort.

I think of a separated library for hotkey handling, not even necessarily using Qt.

[trollixx]

Thank you for this very detailed investigation!

I'll fix the crash you pointed, but that doesn't solve the actual issue.

I spent a lot of time fighting with all kinds of different bugs in QxtGlobalShortcut. Seems it's an infinite source of problems. In fact today the version in Zeal is very far from what the latest Qxt library had. Zeal's version is using XCB, while the original one was based on older X11 API. Still not perfect.

One option could be KGlobalAccel, but at the moment it's Linux-only. Maybe it could solve the problem at least for KDE users.

I am all for having a one unified library, that handles global shortcuts. We could try to polish someone's implementation, or start from scratch.

Also worth noting that Wayland-based DEs are coming as well, so another backend might be required soon.

[ManuelSchneid3r]

I'm currently trying ton understand the x window system protocol and the differences between the client libraries xlib and libxcb. Unfortunately the xcb documentation is virtually not existant. But the protocol is the same so I try to understand xcb by reading xlib documentation.

Well while reading I recognized that modifier mappings arent considered either.

[trollixx]

I've just fixed the crash, once again thanks for reporting.

It's really hard to force myself into digging into the XCB hell. :(

I wonder if grabbing all key codes returned by xcb_key_symbols_get_keycode() would be the proper solution.

[kocielnik]

For a temporary solution (more like a workaround) resetting the shortcut and enabling Zeal to start on Fedora 32, see below.

Problem details

After assigning a global keyboard shortcut and pressing "Apply" on Fedora 32, Zeal abruptly exits.

Then, when called from the desktop shortcut it does not start. The incident reporting tool reports an error that happened in the function xcb_send_request_with_fds64. That pointed me to this particular issue.

When calling Zeal from console, the output is:

$ zeal
QSocketNotifier: Can only be used with threads started with QThread
zeal.core.applicationsingleton: Starting as a primary instance. (PID: 5115)
[1]    5115 segmentation fault (core dumped)  zeal

Solution

To start Zeal, you can disable the shortcut directly in the configuration file.

Zeal stores config at ~/.config/Zeal/Zeal.conf. In that file, find the section:

[global_shortcuts]
show=<your_hotkey>

To remove the shortcut, remove whatever is after the equality sign ("="), leaving the declaration empty as below:

[global_shortcuts]
show=

Save the file and Zeal should start normally now.

When Zeal.conf is not there

In some cases, the configuration file may be located elsewhere. If that is true, to identify the path, try: locate Zeal.conf, or find ~ -name Zeal.conf.

[trollixx]

@kocielnik thanks for the detailed report. It's a different problem. Can you create a separate issue? Please add information about Zeal version. A full stack trace would be helpful as well.

[ManuelSchneid3r]

@trollixx just a note because i was fed up with xcb and moved to QHotkey. maybe you should check it. it works quite well for me (in albertlauncher). Ill close this one because it is pretty old