Strange keyboard input behaviour

[grappas]

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

1. It's hard to reproduce - it's pretty random.
2. 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.

[johnae]

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.

[grappas]

The worst is asking questions with default answer and unintentional ENTER...

[johnae]

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.

[johnae]

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.

[grappas]

@johnae Can you check it with recent commit? I don't see that behavior anymore. Could you confirm?

[johnae]

@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.

[grappas]

Do you have any debug flag enabled?

[johnae]

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.

[grappas]

Nah... it randomly came back again. It has to be somehow directly connected with: https://github.com/wez/wezterm/issues/4501

[johnae]

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.

[johnae]

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 ?

[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).

[johnae]

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!

[grappas]

Doesn't seem to be an issue anymore. @johnae could you confirm?

[zach-wahrer]

Not OP, but I'm still having this issue on current version of Wezterm + Wayland.

[grappas]

@zach-wahrer stable?

[zach-wahrer]

@grappas I'm running 20240203-110809-5046fc22.

[grappas]

ok