Open JonathanxD opened 2 years ago
Please set debug_key_events=true
and see how to debug key events to see and share the key event debug logs here!
Also: WEZTERM_LOG=window::os::x11::keyboard=trace,info wezterm
will log more verbose/detailed information about key events than the built-in debugging; please try that together with debug_key_events!
tl;dr: after hours of investigation I discovered that it is a Mutter issue. I explain it further down
I've got extremely curious by this problem and was thinking about opening a PR to fix it, so I investigated a little more (and I think I went too far, so not that little).
It seems like Gnome Mutter is sending Modifiers
event before the Enter
event here.
I've got very confused by the code since it mentions sending pressed keys with the
Enter
event, and I thought it was talking about the key modifiers.
I was able to confirm this by adding some tracing
to the keyboard_event
logic.
It looks like everything should be working fine in the wezterm side, but Mutter is breaking the spec by sending the wl_keyboard::modifiers
before wezterm has a proper keyboard_window_id
, which is when wl_keyboard::enter
is received.
The spec states crearly that modifiers
must only be sent (and must be sent) after wl_keyboard::enter
. A workaround is possible, but I don't think that spec-breaking implementations of wayland protocol should be supported.
I haven't opened an issue in mutter yet because I spend a bunch of time investigating and it is very late, but feel free to do if you wish, I may do after I rest and comeback refreshed.
Thanks for investigating! It's worth reporting to the mutter folks so that they can queue up a fix for it; would you mind doing that when you're feeling more refreshed? I can't run mutter in wayland mode on my nvidia hardware at this time (waiting for Fedora 36 to release and hopefully resolve that!), so I'd essentially be paraphrasing what you've shared here and it would an inefficient way to to work through things!
It totally makes sense, I've opened an issue in Gnome Mutter repo. I also did more investigation and found that KWayland, wlroots (base for a range of tiling WM and some stacking ones) and Weston all implements this correctly, so it is probably a Gnome one issue.
Interestingly, the Gnome Mutter keyboard modifiers logic dates 5 to 7 years ago, so this problem has been there for years without anyone noticing (or bothering reporting it and just did a workaround).
What Operating System(s) are you seeing this problem on?
Linux Wayland
WezTerm version
20220408-101518-b908e2dd / 20220412-095203-132377cc
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
Numlock is not properly detect in wezterm running under Wayland (not XWayland). The same does not happen under XWayland (I can't say for Xorg since I does not have X installed).
I've compiled wezterm directly from source, tried both the compilation from
2022-04-08
and today2022-04-12
.To Reproduce
Just open wezterm with wayland enabled, it will not detect that Num Lock is active and will treat like it's not, sending CTRL+C fixes the problem temporarily, however, if you switch applications and come back to wezterm, it will behave the same way, like Num Lock wasn't enabled, sending CTRL+C fixes again.
It only happens with numpad, top row numbers works fine.
Configuration
Expected Behavior
Properly detect that numpad is enabled when wezterm is in focus and capture the number input.
Logs
There is nothing special in the logs:
Anything else?
Here is a video of the problem occurring (the numpad respective keys are on the bottom right, the scheme is not correct because it is an overlay prototype).
https://user-images.githubusercontent.com/5360060/163038751-65bec316-6ba8-4dd0-b88b-184f0f6e0794.mp4
Keyboard device specification (I don't know if it does matter, but may be helpful):
lsusb -v
``` Bus 005 Device 002: ID 1532:0226 Razer USA, Ltd Huntsman Elite Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1532 Razer USA, Ltd idProduct 0x0226 Huntsman Elite bcdDevice 2.00 iManufacturer 1 Razer iProduct 2 Razer Huntsman Elite iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0054 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 61 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 159 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 94 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Status: 0x0000 (Bus Powered) ```And output of
evtest
for Num Lock led:As stated in the
evtest
manpage, exit code 10 means that the key is activated.Package versions:
Wayland:
Mutter and Gnome:
Uname -a
:If you need any additional information, feel free to ask.