Strange keyboard input behaviour #4504

grappas · 2023-10-29T14:50:30Z

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?

keystrokes.mp4

There was only one keystroke of "Return" in the beginning, only one keystroke of "d" in third prompt and one "w" in fourth.

johnae · 2023-11-09T19:32:11Z

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
f0e3eec (latest commit at the time of writing)

Also experiencing this as fairly random but quite frequent.

grappas · 2023-11-12T23:44:46Z

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

johnae · 2023-11-14T23:15:09Z

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 · 2023-11-19T16:54:20Z

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 · 2023-11-19T17:57:01Z

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

johnae · 2023-11-19T18:54:42Z

@grappas I was testing the latest commit of wezterm, i.e 6006525 - I tried it with the -n option (don't load any lua at all). And unfortunately I still see this behavior.

grappas · 2023-11-19T20:37:01Z

Do you have any debug flag enabled?

johnae · 2023-11-19T21:28:02Z

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 · 2023-11-19T21:35:09Z

Nah... it randomly came back again.
It has to be somehow directly connected with:
#4501

johnae · 2023-11-20T10:13:05Z

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 · 2023-11-20T22:57:18Z

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: Smithay/client-toolkit#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 · 2023-11-20T23:14:53Z

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 · 2023-11-23T20:52:52Z

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 · 2024-02-11T21:39:08Z

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

zach-wahrer · 2024-02-11T21:46:51Z

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

grappas · 2024-02-11T21:59:06Z

@zach-wahrer stable?

zach-wahrer · 2024-02-11T22:02:31Z

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

grappas · 2024-02-11T22:03:14Z

ok

wez · 2024-09-22T15:45:04Z

I'm closing this since the OP reports that their issue is resolved. If you are experiencing this or a similar issue, please try with the latest nightly build to confirm and then open a new issue of your own for that.

grappas · 2024-09-22T16:46:09Z

It seems to be the case also. Thanks @wez
💗

grappas added the bug Something isn't working label Oct 29, 2023

grappas mentioned this issue Nov 3, 2023

Wezterm (20230712.072601.f4abf8fd-1, stable) insta crash on hyprland main branch hyprwm/Hyprland#3742

Closed

wez added the Wayland label Nov 4, 2023

johnae mentioned this issue Nov 27, 2023

Wezterm fails to start, emits Resource temporarily unavailable #4483

Closed

tzx mentioned this issue Jan 11, 2024

Upgrade smithay-client-toolkit 0.17 #4777

Closed

9 tasks

grappas closed this as completed Feb 11, 2024

grappas reopened this Feb 11, 2024

johnae mentioned this issue Mar 7, 2024

Duplicate / phantom key presses #4836

Closed

wez closed this as completed Sep 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Strange keyboard input behaviour #4504

Strange keyboard input behaviour #4504

grappas commented Oct 29, 2023

johnae commented Nov 9, 2023 •

edited

Loading

grappas commented Nov 12, 2023

johnae commented Nov 14, 2023

johnae commented Nov 19, 2023

grappas commented Nov 19, 2023

johnae commented Nov 19, 2023

grappas commented Nov 19, 2023

johnae commented Nov 19, 2023

grappas commented Nov 19, 2023

johnae commented Nov 20, 2023 •

edited

Loading

johnae commented Nov 20, 2023

wez commented Nov 20, 2023

johnae commented Nov 23, 2023

grappas commented Feb 11, 2024

zach-wahrer commented Feb 11, 2024

grappas commented Feb 11, 2024

zach-wahrer commented Feb 11, 2024

grappas commented Feb 11, 2024

wez commented Sep 22, 2024

grappas commented Sep 22, 2024

Strange keyboard input behaviour #4504

Strange keyboard input behaviour #4504

Comments

grappas commented Oct 29, 2023

What Operating System(s) are you seeing this problem on?

Which Wayland compositor or X11 Window manager(s) are you using?

WezTerm version

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Describe the bug

To Reproduce

Configuration

Expected Behavior

Logs

Anything else?

johnae commented Nov 9, 2023 • edited Loading

grappas commented Nov 12, 2023

johnae commented Nov 14, 2023

johnae commented Nov 19, 2023

grappas commented Nov 19, 2023

johnae commented Nov 19, 2023

grappas commented Nov 19, 2023

johnae commented Nov 19, 2023

grappas commented Nov 19, 2023

johnae commented Nov 20, 2023 • edited Loading

johnae commented Nov 20, 2023

wez commented Nov 20, 2023

johnae commented Nov 23, 2023

grappas commented Feb 11, 2024

zach-wahrer commented Feb 11, 2024

grappas commented Feb 11, 2024

zach-wahrer commented Feb 11, 2024

grappas commented Feb 11, 2024

wez commented Sep 22, 2024

grappas commented Sep 22, 2024

johnae commented Nov 9, 2023 •

edited

Loading

johnae commented Nov 20, 2023 •

edited

Loading