search

Mudlet / Mudlet

⚔️ A cross-platform, open source, and super fast MUD client with scripting in Lua
https://mudlet.org
GNU General Public License v2.0
733 stars 267 forks source link

Linux/Wayland: Qt::KeypadModifier not being recognised #4925

Open Xabre666 opened 3 years ago

Xabre666 commented 3 years ago

Brief summary of issue / Description of requested feature:

Even though Mudlet generally works well on Wayland, one problem remains: detection of keys on numeric keyboard, which are recognized as keys on keyboaard in general (no difference is made between, say, 3 or Keypad + 3), which makes creation and usage of keybindings tricky/impossible. Most common use for numeric keypad (numpad) in Mudlet is probaby as keybindins for movement, but with no difference between number and keypad+number, using keypad for that purpose makes it imposible to type in numbers for regular text.

Mudlet uses Qt::KeypadModifier for detection of the keypad, and I have no idea why is it not working. All other modifiers work flawlessly. Again, this is Qt/Mudlet on Wayland I'm speaking of, keypad is properly detected on X11.

Steps to reproduce the issue / Reasons for adding feature:

  1. Run Mudlet in Wayland session
  2. Create new keybinding, click on Grab New Key, press number on numeric keypad, here key 5 for example
  3. Key is detected as 5 and fired on pressing either 5 or keypad + 5. (On X11 it would be detected as keypad + 5 and fire only on keypad +5)

There ought to be some way to re-establish proper detection of Keypad modifier, reading Qt documentation there should be no difference and Qt itself should be responsible for detection and handlling of platform input devices, however here it is not working, and not working just for Qt::KeypadModifier only.

Main reason for fixing this would be that most major Linux distributions are switching, or will in near future, to Wayland session as default. Fedora already has, Ubuntu 21.04 is expected to do the same, and so on. Workaround fix is obviously running Mudlet in XWayland, but that requires user intervention (running Mudlet with _QT_QPAPLATFORM=xcb mudlet), and given that X11 is slowly (but surely) being depreciated, proper fix/solution for this is much more desirable.

Xabre666 commented 3 years ago

In interest of full disclosure, Nvidia just released the latest version of their proprietary driver that enables hardware acceleration when applicaton is running via XWayland, so when using that driver performance penalty on Nvidia GPUs should be much less noticable when running Mudlet in Xwayland mode on a full Wayland session. (Drivers for Intel/AMD GPUs already suport Wayland/XWayland fully) So, issue described here is much less important than it used to be when it was posted. Still, it would be nice to be solved.

Am wondering has anyone else been able to at least confirm the issue? I know that most Linux users use official appimages, but I know that there are more people than just me who compile Mudlet on their own. :)

vadi2 commented 3 years ago

Wayland isn't an option on my system, and the obvious instructions on how to make it show don't work - so I can't test it myself. That said try looking into what Qt has to say there, since as you mention it's unlikely a purely Mudlet issue - we use the semantics correctly.

Xabre666 commented 3 years ago

I'd say it's a pure Qt issue if Mudlet was not the only application behaving as described.

My Google foo did not help me much when looking for people with same/similar problem, only thing I found was from several years ago where they solved the problem with shortcut on NumKey5 in Alacritty (terminal app, not Qt, but hey, holding onto straws is better than nothing) by checking the NumLock state (not keypad modifier) before assigning the shortcut on a NumPad key. (Mudlet on Wayland recognizes NumLock without issues. just as well as all other keys and key combinations except plain keypad number - again: the only app I have behving so.

Semantics appear OK. Qt documentation describes it exactly as it's implemented. Qt Wayland exists/is deemed stable since Qt 5.8, been quite some time since then to not see something like KeyPadModifier not working, yet internet is -not- filled with bug reports about it. Or my GoogleFoo is simply crap.

vadi2 commented 3 years ago

Mm okay, something we ought to look at then.

ZookaOnGit commented 1 year ago

Am wondering has anyone else been able to at least confirm the issue? I know that most Linux users use official appimages, but I know that there are more people than just me who compile Mudlet on their own. :)

I have run into this problem and run X11 purely because of it. Let me know if you need further information.

Xabre666 commented 1 year ago

Am wondering has anyone else been able to at least confirm the issue? I know that most Linux users use official appimages, but I know that there are more people than just me who compile Mudlet on their own. :)

I have run into this problem and run X11 purely because of it. Let me know if you need further information.

FYI, just so you (or maybe others) are aware, you do not have to run a full X session, can simply force Mudlet to use XWayland. Just run it with QT_QPA_PLATFORM=xcb ./Mudlet.AppImage, or simply QT_QPA_PLATFORM=xcb mudlet, depending on type of your Mudlet installation. If testing a Flatpak instalation, it is automatically locked in X mode. Given how long this issue exists here and that devs seem to be Nvidia users (thus avoiding Wayland), I doubt that it will be properly fixed any time soon, so forcing Xwayland seems like a logical way to go.