wezterm
wezterm copied to clipboard
wez
Strange keyboard input behaviour
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Hyprland 0.31.0.r47.7f4b0aaa-1
WezTerm version
20231017-091526-fec90ae0
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
Sometimes keystrokes are registered double times after original single one. It appears after ≈500ms of original keystroke. This way comes up double spaces, double a's or worse - double new lines.
To Reproduce
- It's hard to reproduce - it's pretty random.
- Just open terminal and start typing.
Configuration
local wezterm = require 'wezterm'
local act = wezterm.action
local mykeys = {
}
local My_font_size = 14.0
local Font_size = My_font_size
function Recompute_font_size(window)
local window_dims = window:get_dimensions()
local overrides = window:get_config_overrides() or {}
local Dpi = window_dims.dpi / 96
local Scale_factor_general = 7
local Scale_factor_x = window_dims.pixel_width / ( Scale_factor_general * 9 * Dpi )
local Scale_factor_y = window_dims.pixel_height / ( Scale_factor_general * 7 * Dpi )
local Scale_factor = Scale_factor_x
if (Scale_factor_y > Scale_factor_x)
then
Scale_factor = Scale_factor_x
else
Scale_factor = Scale_factor_y
end
if Scale_factor > My_font_size
then
Font_size = My_font_size
else
Font_size = math.floor(Scale_factor)
end
overrides.font_size = Font_size
window:set_config_overrides(overrides)
end
wezterm.on('window-resized', function(window)
Recompute_font_size(window)
end)
for i = 1, 8 do
-- CTRL+ALT + number to activate that tab
table.insert(mykeys, {
key = tostring(i),
mods = 'CTRL|ALT',
action = act.ActivateTab(i - 1),
})
-- F1 through F8 to activate that tab
table.insert(mykeys, {
key = 'F' .. tostring(i),
action = act.ActivateTab(i - 1),
})
end
if wezterm.target_triple == 'x86_64-pc-windows-msvc' then
Default_prog = { 'powershell.exe' }
else
Default_prog = { 'zsh' }
end
if wezterm.target_triple == 'x86_64-pc-windows-msvc' then
Font = wezterm.font 'VictorMono NF'
else
Font = wezterm.font 'VictorMono Nerd Font'
end
return {
font = Font,
font_size = Font_size,
color_scheme = 'GruvboxDark',
window_background_opacity = 0.9,
window_close_confirmation = 'NeverPrompt',
default_prog = Default_prog,
enable_wayland = true,
hide_tab_bar_if_only_one_tab = true,
default_cursor_style = 'SteadyBlock',
front_end = "WebGpu",
keys = {
-- {{{1
{
key = 'F1',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F2',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F3',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F4',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F5',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F6',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F7',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F8',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F9',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F10',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F11',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
{
key = 'F12',
mods = 'CMD',
action = wezterm.action.DisableDefaultAssignment,
},
-- }}}
}
}
Expected Behavior
Keystrokes have to be registered as they should be.
Logs
15:41:05.005 INFO wezterm_gui > Spawned your command via the existing GUI instance. Use wezterm start --always-new-process if you do not want this behavior. Result=SpawnResponse { tab_id: 1, pane_id: 1, window_id: 1, size: TerminalSize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 384, dpi: 0 } }
Anything else?
https://github.com/wez/wezterm/assets/1036957/71b5fb9d-1259-4528-8a78-c152ef552f57
There was only one keystroke of "Return" in the beginning, only one keystroke of "d" in third prompt and one "w" in fourth.
I have this problem too:
What Operating System(s) are you seeing this problem on? Linux Wayland (NixOS)
Which Wayland compositor or X11 Window manager(s) are you using? hyprland-0.32.0+date=2023-11-08_c619e69
WezTerm version f0e3eecba6faec0aa963a6f0067577afc99e11db (latest commit at the time of writing)
Also experiencing this as fairly random but quite frequent.
The worst is asking questions with default answer and unintentional ENTER...
I tested wezterm on river as well - i.e https://github.com/riverwm/river. River uses wlroots 0.16 (while hyprland uses more or less HEAD of wlroots).
I observed the same input behavior in river as in hyprland so this seems to be something that was introduced in wezterm relatively recently. I didn't have these issues in 20230712-072601-f4abf8fd. I can't use an older version of wezterm though as those won't launch on hyprland at least.
When debugging key events (eg. config.debug_key_events = true), this is what stderr looks like when a duplicate "l" is output:
17:48:58.106 INFO wezterm_gui::termwindow::keyevent > key_event RawKeyEvent { key: Physical(L), modifiers: NONE, leds: (empty), phys_code: Some(L), raw_code: 46, repeat_count: 1, key_is_down: true, handled: Handled(false) }
17:48:58.106 INFO wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Char('l'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(L), modifiers: NONE, leds: (empty), phys_code: Some(L), raw_code: 46, repeat_count: 1, key_is_down: true, handled: Handled(false) }) }
17:48:58.106 INFO wezterm_gui::termwindow::keyevent > send to pane DOWN key=Char('l') mods=NONE
17:48:58.106 INFO wezterm_term::terminalstate::keyboard > key_down: sending "l", Char('l') NONE
17:48:58.707 INFO wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Char('l'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(L), modifiers: NONE, leds: (empty), phys_code: Some(L), raw_code: 46, repeat_count: 1, key_is_down: true, handled: Handled(false) }) }
17:48:58.707 INFO wezterm_gui::termwindow::keyevent > send to pane DOWN key=Char('l') mods=NONE
17:48:58.708 INFO wezterm_term::terminalstate::keyboard > key_down: sending "l", Char('l') NONE
17:48:58.708 INFO wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Char('l'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Physical(L), modifiers: NONE, leds: (empty), phys_code: Some(L), raw_code: 46, repeat_count: 1, key_is_down: false, handled: Handled(false) }) }
17:48:58.708 INFO wezterm_gui::termwindow::keyevent > send to pane UP key=Char('l') mods=NONE
The timings in the log matches how it "feels". It's not immediate but, as the log indicates, the dupe is output about half a second later. Generally, when just writing text, I don't notice the problem as much as it doesn't seem to manifest if a key is pressed before about 5-600 ms has passed.
@johnae Can you check it with recent commit? I don't see that behavior anymore. Could you confirm?
@grappas I was testing the latest commit of wezterm, i.e https://github.com/wez/wezterm/commit/600652583594e9f6195a6427d1fabb09068622a7 - I tried it with the -n option (don't load any lua at all). And unfortunately I still see this behavior.
No. Any pointers? I mean I could build a dev build but what would I be looking for? If you mean log verbosity, I didn't set anything but can do that ofc if it'd be helpful.
Nah... it randomly came back again. It has to be somehow directly connected with: https://github.com/wez/wezterm/issues/4501
I suppose it could be related to that other issue. Still - I see this happening after a reboot with only a single terminal window and nothing else opened. That window was never not visible. I too ofc see the 100% cpu issue from that other issue. I'm not convinced they're related though.
I believe I've found the likely issue. This became an issue when updating SCTK to 0.16.1 (from 0.16.0). This was done to support startup on newer compositors, so for most it'd be a big deal to downgrade both the compositor and wezterm.
The issue is (likely) upstream in SCTK, more specifically this issue: https://github.com/Smithay/client-toolkit/issues/356 - it fairly closely resembles the issue I'm seeing anyway.
The fix commit is in SCTK 0.17.0 and 0.18.0 so basically wezterm would need to update to any of those versions, which may not be a small thing I suppose - I'm not too familiar with the wezterm code base yet.
What are your thoughts on this @wez ?
Elsewhere in wezterm's issue's tagged with wayland there is a discussion about the level of effort involved: the changes from 0.16 -> 0.17 and the wayland ecosystem crates are effectively a rewrite of wayland support in wezterm, for which I do not have time or energy.
I would really welcome a PR for that!
Alternatively, if sufficient funding could be provided, I could make time for this, but I view this as a large effort and no one has been serious about funding that effort so far. (https://github.com/sponsors/wez?frequency=one-time&sponsor=wez shows the ballpark for funding a large project).
Yeah I get it. I'd actually welcome a challenge myself, I'm not a Rust beginner really. I think the main challenge would be wayland/smithay (haven't done much such work if any really). Well that and the constant absence of time.
Regardless - wezterm is really awesome, thanks for making it!
Not OP, but I'm still having this issue on current version of Wezterm + Wayland.
