neovide: Neovide does not start with kwin 5.25 in wayland session (wayland-client error)

Describe the bug Since upgrade to KDE Plasma 5.25 Neovide does not start. Release build produces no output. Debug build produces the following:

[wayland-client error] Attempted to dispatch unknown opcode 0 for wl_shm, aborting.

To Reproduce Steps to reproduce the behavior:

  1. Use KDE Plasma (with kwin) 5.25 in Wayland session.
  2. neovide does not start

Expected behavior Neovide starting.

Screenshots none

Desktop (please complete the following information):

  • OS: Arch Linux with KDE Plasma 5.25 in Wayland session.
  • Neovide 0.9.0 (latest master, rev 7a3bf52)
  • Neovim 0.7.0

Please run neovide --log and paste the contents of the .log file created in the current directory here:

TRACE [neovide] Neovide version: 0.9.0
DEBUG [neovide::bridge::command] Starting neovim with: Command { std: "/usr/bin/nvim" "--embed", kill_on_drop: false }
INFO [neovide::bridge::setup] Neovide registered to nvim with channel id 1
INFO [neovide::bridge] Neovim process attached

Additional context

Output of WAYLAND_DEBUG=1 ./target/debug/neovide:

Click me
[1617421.741]  -> wl_display@1.get_registry(new id wl_registry@2)
[1617421.806]  -> wl_display@1.sync(new id wl_callback@3)
[1617425.226] wl_display@1.delete_id(3)
[1617425.246] wl_registry@2.global(1, "wl_compositor", 5)
[1617425.316]  -> wl_registry@2.bind(1, "wl_compositor", 5, new id [unknown]@4)
[1617425.345] wl_registry@2.global(2, "zwp_tablet_manager_v2", 1)
[1617425.359] wl_registry@2.global(3, "zwp_keyboard_shortcuts_inhibit_manager_v1", 1)
[1617425.372] wl_registry@2.global(5, "xdg_wm_base", 4)
[1617425.387] wl_registry@2.global(6, "zwlr_layer_shell_v1", 3)
[1617425.403] wl_registry@2.global(7, "zxdg_decoration_manager_v1", 1)
[1617425.418]  -> wl_registry@2.bind(7, "zxdg_decoration_manager_v1", 1, new id [unknown]@5)
[1617425.434] wl_registry@2.global(8, "wp_viewporter", 1)
[1617425.444] wl_registry@2.global(9, "wl_shm", 1)
[1617425.464]  -> wl_registry@2.bind(9, "wl_shm", 1, new id [unknown]@6)
[1617425.489] wl_registry@2.global(10, "wl_seat", 7)
[1617425.505]  -> wl_registry@2.bind(10, "wl_seat", 6, new id [unknown]@7)
[1617425.536] wl_registry@2.global(11, "zwp_pointer_gestures_v1", 3)
[1617425.547] wl_registry@2.global(12, "zwp_pointer_constraints_v1", 1)
[1617425.566]  -> wl_registry@2.bind(12, "zwp_pointer_constraints_v1", 1, new id [unknown]@8)
[1617425.591] wl_registry@2.global(13, "zwp_relative_pointer_manager_v1", 1)
[1617425.604]  -> wl_registry@2.bind(13, "zwp_relative_pointer_manager_v1", 1, new id [unknown]@9)
[1617425.619] wl_registry@2.global(14, "wl_data_device_manager", 3)
[1617425.630] wl_registry@2.global(15, "zwlr_data_control_manager_v1", 2)
[1617425.642] wl_registry@2.global(16, "zwp_primary_selection_device_manager_v1", 1)
[1617425.653] wl_registry@2.global(17, "org_kde_kwin_idle", 1)
[1617425.662] wl_registry@2.global(18, "zwp_idle_inhibit_manager_v1", 1)
[1617425.675] wl_registry@2.global(19, "org_kde_plasma_shell", 7)
[1617425.686] wl_registry@2.global(20, "org_kde_kwin_appmenu_manager", 1)
[1617425.697] wl_registry@2.global(21, "org_kde_kwin_server_decoration_palette_manager", 1)
[1617425.708] wl_registry@2.global(23, "org_kde_plasma_virtual_desktop_management", 2)
[1617425.719] wl_registry@2.global(25, "org_kde_kwin_shadow_manager", 2)
[1617425.731] wl_registry@2.global(26, "org_kde_kwin_dpms_manager", 1)
[1617425.742] wl_registry@2.global(27, "org_kde_kwin_server_decoration_manager", 1)
[1617425.754] wl_registry@2.global(28, "kde_output_management_v2", 2)
[1617425.765] wl_registry@2.global(29, "kde_primary_output_v1", 2)
[1617425.777] wl_registry@2.global(30, "zxdg_output_manager_v1", 3)
[1617425.788] wl_registry@2.global(31, "wl_subcompositor", 1)
[1617425.802]  -> wl_registry@2.bind(31, "wl_subcompositor", 1, new id [unknown]@10)
[1617425.817] wl_registry@2.global(32, "zxdg_exporter_v2", 1)
[1617425.828] wl_registry@2.global(33, "zxdg_importer_v2", 1)
[1617425.838] wl_registry@2.global(35, "xdg_activation_v1", 1)
[1617425.852] wl_registry@2.global(36, "wp_drm_lease_device_v1", 1)
[1617425.862] wl_registry@2.global(39, "wl_drm", 2)
[1617425.874] wl_registry@2.global(40, "zwp_linux_dmabuf_v1", 4)
[1617425.883] wl_registry@2.global(41, "kde_output_device_v2", 2)
[1617425.894] wl_registry@2.global(42, "wl_output", 3)
[1617425.903]  -> wl_registry@2.bind(42, "wl_output", 3, new id [unknown]@11)
[1617425.934] wl_registry@2.global(44, "zwp_text_input_manager_v2", 1)
[1617425.946] wl_registry@2.global(45, "zwp_text_input_manager_v3", 1)
[1617425.959]  -> wl_registry@2.bind(45, "zwp_text_input_manager_v3", 1, new id [unknown]@12)
[1617425.978] wl_registry@2.global(46, "org_kde_kwin_contrast_manager", 2)
[1617425.988] wl_registry@2.global(47, "org_kde_kwin_blur_manager", 1)
[1617426.000] wl_registry@2.global(48, "org_kde_kwin_slide_manager", 1)
[1617426.015] wl_callback@3.done(25429)
[1617426.024]  -> wl_display@1.sync(new id wl_callback@3)
[1617426.112] wl_display@1.delete_id(3)
[1617426.117] wl_shm@6.format(0)
[1617426.135] wl_shm@6.format(1)
[1617426.139] wl_shm@6.format(808669761)
[1617426.142] wl_shm@6.format(808669784)
[1617426.146] wl_shm@6.format(808665665)
[1617426.151] wl_shm@6.format(808665688)
[1617426.154] wl_shm@6.format(942948929)
[wayland-client error] Attempted to dispatch unknown opcode 0 for wl_shm, aborting.
fish: Job 1, 'WAYLAND_DEBUG=1 ./target/debug/…' terminated by signal SIGABRT (Abort)

Neovide starts successfully using XWayland backend (WINIT_UNIX_BACKEND=x11 ./target/debug/neovide).

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 28
  • Comments: 73 (17 by maintainers)

Commits related to this issue

Most upvoted comments

I’d like to wait around a bit until the new keyboard api lands and then update neovide to support the upstream version of winit, I’m not sure what other changes our fork has but we can upstream them if nessecary. This should fix the above issues (and let us publish to crates.io, finally 😃)

I’d rather not depend on a PR in main, mainly because its a moving target and we might need to keep up with it. Stay tuned, just a bit longer!

Fwiw now we’re having eyes on https://github.com/rust-windowing/winit/pull/2662 instead of the aforementioned two PRs. The winit maintainers are not quite finished on negotiating their API, but the PR is moving very fast.

For me, both workarounds:

WINIT_UNIX_BACKEND=x11 neovide

And

env -u WAYLAND_DISPLAY neovide

succeed in launching neovide.

Yet, there’s a different problem, then. If the window loses focus, I can’t seem to get it to accept key strokes again by simple focusing it. I’m using swaywm, by the way. If I move the mouse over it, it does start accepting key strokes.

Same exact issue here, on Hyprland

With commit f412399, neovide runs perfectly, at least for me on Hyprland. I believe this issue is now resolved and should be marked as closed.

I managed to make it work in #1813, which depends on changes on both winit(neovide/winit#11) and glutin(neovide/glutin#3) side.

Try this branch if you want a working version on Wayland eyes

Hey wtf, your branch works! After a few hours of usage I haven’t run into any issues with it either.

Are the fixes you made something that could be merged? Or does it break other things?

It’s a bit sad that Wayland support has been broken for almost a year at this point 😕

I managed to make it work in #1813, which depends on changes on both winit(https://github.com/neovide/winit/pull/11) and glutin(https://github.com/neovide/glutin/pull/3) side.

Try this branch if you want a working version on Wayland 👀

It seems the issue does not exist when using updated winit+glutin. Maybe because of newer version of wayland-protocols libraray, since smithay/client-toolkit (dependancy of winit) uses unstable wayland protocols?

I’ve managed to get Neovide working here using maroider’s fork of winit (new keyboard api for linux branch). Although my fork of Neovide probably works only on Linux+Wayland as new keyboard PR’s for winit are still outstanding. And I had to remove IME input in my fork since there was some breaking change in API (likely this commit).

Awesome. Thanks. I’ve managed to rebase this content onto the latest in main and I can now run under Sway.

https://github.com/williamspatrick/neovide/commit/677e87e887bc14544ca6156907666a5739f5a361

Not a workaround (well, semi) but I have the following suggestion to make:

  • The winit PR https://github.com/rust-windowing/winit/pull/1932 (from now on referred to as the “linux PR”) provides the “new” keyboard API for Linux in winit, as required by Neovide. Only problems are that it uses wayland-client 0.29 (the newest is 0.30), which doesn’t seem to work on Hyprland (https://github.com/neovide/neovide/issues/1356#issuecomment-1371084992), and that it is out of sync with the other new keyboard API PRs.
  • Completely insane, but we could improve this by
    • forking the linux PR
    • upgrading it to wayland-client 0.30 and the latest smithay-client-toolkit version
    • creating a PR at the winit repo with the linux PR as target
    • pulling in that upgraded branch to a new dependency winit_linux/winit_wayland
    • using that dependency only on Wayland as a replacement for winit.

The end result of this would mean 2 different winits in our dependency tree, but at least we can handle Wayland upgrades independently of the other platforms then, and other platforms are very unlikely to make breaking changes.

Stopped working on sway after upgrading wlroots (0.15.1-6 -> 0.16.1-2) and sway (1:1.7-10 -> 1:1.8-3) on arch linux.

Output error is the same.

UPD: I noticed also libxkbcommon (1.4.1-2 -> 1.5.0-1) and libxkbcommon-x11 (1.4.1-2 -> 1.5.0-1) were upgraded. Could they be an issue?

Are there any plans to merge upstream winit any time soon?

There’s no need for a separate ticket for wlroots. The root cause is the same and opening duplicate tickets won’t help.

The main issue is that neovide uses forks of older versions of libraries which has issues on most wayland implementations.

See also: https://github.com/neovide/neovide/issues/1588

It seems the issue does not exist when using updated winit+glutin. Maybe because of newer version of wayland-protocols libraray, since smithay/client-toolkit (dependancy of winit) uses unstable wayland protocols?

I’ve managed to get Neovide working here using maroider’s fork of winit (new keyboard api for linux branch). Although my fork of Neovide probably works only on Linux+Wayland as new keyboard PR’s for winit are still outstanding. And I had to remove IME input in my fork since there was some breaking change in API (likely this commit).

I love neovide. I’ve been using it for a few months and now I can’t seem to use it due to this bug 😢 .

This will eventually be fixed by https://github.com/neovide/neovide/pull/1789, in combination with https://github.com/neovide/neovide/pull/1797

(PR 1789 doesn’t build on linux, though PR 1797 will fix that - I haven’t tested it yet though)

williamspatrick@677e87e

Can confirm this works on Hyprland

@williamspatrick more motivated than I am 👏 .

I’m noticing that with this workaround:

env -u WAYLAND_DISPLAY neovide

The clipboard integration fails to work properly, because as documented in :h clipboard:

The presence of a working clipboard tool implicitly enables the '+' and '*'
registers. Nvim looks for these clipboard tools, in order of priority:

  - |g:clipboard|
  - pbcopy, pbpaste (macOS)
  - wl-copy, wl-paste (if $WAYLAND_DISPLAY is set)
  - waycopy, waypaste (if $WAYLAND_DISPLAY is set)

Because $WAYLAND_DISPLAY is not set, the clipboard commands don’t get wired up properly.

  1. How would I install the version https://github.com/neovide/neovide/commit/f412399676c83ea670cd22745b850dad9ee210a0? Neovide is currently installed via pacman for me on Manjaro.
  2. Is there a way to work around the $WAYLAND_DISPLAY variable not being set, and manually wire up the clipboard? I tried setting my leader keys for y and p manually, but I’m apparently not doing that correctly. An example would help if anyone is willing to provide.

Heads up for those still monitoring this issue: https://github.com/rust-windowing/winit/pull/2662 has been merged. Is there any other roadblock or does that mean that work on a proper fix can start now?

the only way I have to run it on wayland (Hyprland)

alias xw='env -u WAYLAND_DISPLAY'
alias nv="xw neovide --multigrid"

@huge-pancake you made the same mistake as I did, you used main, that doesn’t work. However, can you check to see if the key “k” gets repeated when you try again with the new-keyboard-v3-dep branch ?

also strange workaround that seems to work: you can start neovide inside cage, a small kiosk wayland compositor. It sounds weird, but this gives decent performance and it feels like you are just running another wayland window, since that’s what cage kinda is.

Could you please explain it in detail?

Suppose you press and hold the w key for a brief moment; typically, this would result in the output of wwwwwwww. However, when using this particular branch, Neovim will only output a single w and will not process any further input.

EDIT: So it’s working fine today, no clue why 😄

The whole API is different, except for making changes in Neovide itself there’s nothing possible to do from a user perspective.

I created a specific sway/wlroots issue here: https://github.com/neovide/neovide/issues/1724

Although I’m more inclined to say libwayland-client.so could be the reason here, since this doesn’t happen only on wlroots-based compositors.

Also an issue on swaywm (both latest release and master).

It’s not a real workaround. Xwayland has issues with HiDPI on sway and the sway developers refuse to fix it, through which every program which connects through X only gets available_window_size / hidpi_scale as window size, then just scaling up, ending up pixelated. Also there’s #1278 which I’m completely clueless about.