Neovide: Tracking upstream: Wayland support not implemented/buggy

Created on 6 Jan 2020  Â·  19Comments  Â·  Source: Kethku/neovide

UI thread spawned
fontkey from: Roboto, 14
thread 'main' panicked at 'internal error: entered unreachable code', /home/sawyer/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-0.5.0/src/renderer/window_support.rs:45:14
stack backtrace:
   0:     0x55c26be318f4 - backtrace::backtrace::libunwind::trace::h65597d255cb1398b
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:     0x55c26be318f4 - backtrace::backtrace::trace_unsynchronized::hd4f479d7150ec4a0
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:     0x55c26be318f4 - std::sys_common::backtrace::_print_fmt::h015072984a2b172c
                               at src/libstd/sys_common/backtrace.rs:77
   3:     0x55c26be318f4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h6df05d3335f32194
                               at src/libstd/sys_common/backtrace.rs:61
   4:     0x55c26be57d6c - core::fmt::write::h1f444f4312eb6c27
                               at src/libcore/fmt/mod.rs:1028
   5:     0x55c26be2ea37 - std::io::Write::write_fmt::h8d147888220078ef
                               at src/libstd/io/mod.rs:1412
   6:     0x55c26be33e4e - std::sys_common::backtrace::_print::h8a6df0fa81d6af62
                               at src/libstd/sys_common/backtrace.rs:65
   7:     0x55c26be33e4e - std::sys_common::backtrace::print::h6f05b4733407e509
                               at src/libstd/sys_common/backtrace.rs:50
   8:     0x55c26be33e4e - std::panicking::default_hook::{{closure}}::h0d0a23bd02315dd8
                               at src/libstd/panicking.rs:188
   9:     0x55c26be33b41 - std::panicking::default_hook::h8d15a9aecb4efac6
                               at src/libstd/panicking.rs:205
  10:     0x55c26be3454b - std::panicking::rust_panic_with_hook::hbe174577402a475d
                               at src/libstd/panicking.rs:464
  11:     0x55c26bdb1783 - std::panicking::begin_panic::hfc51a6f59961fcca
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/panicking.rs:400
  12:     0x55c26b5d8efa - skulpin::renderer::window_support::create_surface::hdafadb24e11b4148
                               at /home/sawyer/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-0.5.0/src/renderer/window_support.rs:45
  13:     0x55c26b5b3055 - skulpin::renderer::device::VkDevice::new::hb87b290a8f6fd6cc
                               at /home/sawyer/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-0.5.0/src/renderer/device.rs:50
  14:     0x55c26b5aa1c1 - skulpin::renderer::renderer::Renderer::new::hc5d4e7bf2204550e
                               at /home/sawyer/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-0.5.0/src/renderer/renderer.rs:249
  15:     0x55c26b5a9d7a - skulpin::renderer::renderer::RendererBuilder::build::h4991be65e14a1fbf
                               at /home/sawyer/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-0.5.0/src/renderer/renderer.rs:163
  16:     0x55c26b3dea5b - neovide::window::ui_loop::hdcad53034d51e52c
                               at src/window.rs:42
  17:     0x55c26b4429f9 - neovide::main::hcc0d95a0303618df
                               at src/main.rs:91
  18:     0x55c26b43f520 - std::rt::lang_start::{{closure}}::hfbadcd0574f266cc
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  19:     0x55c26be33f73 - std::rt::lang_start_internal::{{closure}}::h6ea535ec5c50fc3e
                               at src/libstd/rt.rs:48
  20:     0x55c26be33f73 - std::panicking::try::do_call::h631c6408dfccc6f5
                               at src/libstd/panicking.rs:287
  21:     0x55c26be3c2ca - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:78
  22:     0x55c26be34a2d - std::panicking::try::hab539b2d1255d635
                               at src/libstd/panicking.rs:265
  23:     0x55c26be34a2d - std::panic::catch_unwind::hd5e0a26424bd7f34
                               at src/libstd/panic.rs:396
  24:     0x55c26be34a2d - std::rt::lang_start_internal::h3bdc4c7d98181bf9
                               at src/libstd/rt.rs:47
  25:     0x55c26b43f4f9 - std::rt::lang_start::h1cd89b6af8d283da
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  26:     0x55c26b442a7a - main
  27:     0x7f3a6ddfd153 - __libc_start_main
  28:     0x55c26b385e9e - _start
  29:                0x0 - <unknown>

Might be upstream, but should look at the issue here to be sure

bug help wanted upstream

All 19 comments

Not reachable on a later version, may be hidden by an earlier issue though (currently trying to resolve on my end)

Yep, still present for me. Backtrace updated with any new offsets

Looks like skulpin may not support wayland? Shouldn't be an issue though since it should be able to just run through xwayland

https://github.com/aclysma/skulpin/blob/master/src/renderer/window_support.rs

Reporting upstream though since I doubt this is a lib usage issue

Yeah unfortunately the decision to use Vulcan is making life hard on non windows platforms seems like. I've been considering some other renderer targets such as pathfinder and the like, but they run into problems when it comes to remote desktop on windows.

In the end I will likely build a generic renderer trait which I build multiple implementations for. But for now and I think for the initial release I will need to add better readme support for getting vulcan running on the various platforms.

How well do other rust vulkan libs work cross-plat?

Upstream is working on adding wayland support

Not sure how to debug this at the moment, after applying the patch this runs and does a couple loops in the event loop but a window never appears

Unfortunately I don't have a linux box easily accessible, so testing wayland is somewhat difficult at the moment. Further I've got some other fish to fry (emoji support, documentation, random other crashes :P). For the moment, I'm going to rely on upstream skulpin support to land for this. If however it doesn't work after I have finished the immediate next tasks, I will build a linux test environment and dig in.

Thanks for testing and trying what you have so far! It helps a lot.

successfully built this project for wayland by using upstream skulpin.

Cargo.toml:

- skulpin = "0.5"
+ skulpin = { git = "https://github.com/aclysma/skulpin" }

Thanks for catching that, seems to work now on my end :)

Different bug seems to have cropped up now, only appears on wayland: animations don't continue to animate unless events come in, like it enters idle too quickly or forgets to page flip or something. Recording attached.
anim_demo_1

Ok yeah I should be able to fix this by adding a grace period before sleeping. It's a bit of a hack but I don't know how to fix it otherwise...

Sent with GitHawk

How are the animations done? Is there a way of tracking whether they have frames left/if they've settled?

I've been meaning to document it, but haven't gotten around to it.

I just made some changes that should fix it more permanently, but the basic gist is this:

  1. Winit has a window loop which I configure to run 60 times a second
  2. Every frame the winit loop checks with the redraw scheduler to see if it should render
  3. Any part of the code can tell the redraw scheduler to draw the next frame. Similarly the cursor manager may at times schedule a frame to draw in the future.
  4. The cursor animates by moving each corner of the cursor some percentage of the way toward the destination. This percentage is chosen by how far a given corner is from the center of the destination. Farther distance leads to smaller percentage. This results in the dragged out smear effect
  5. Frames are continuously queued so long as the cursor corners are not at their destination.

My change was to make it so that there is a grace period where any time a part of the code requests a redraw, the system will draw 60 more frames afterward to make sure the animation was completed. This is overkill, but sufficient to fix the problem for now. I believe the core of the issue has to do with Winit, and I have plans to build alternate windowing and rendering pipelines on druid-shell, a custom window system, and others, but for now this should unblock us.

TLDR: I think the animation problem should be fixed. Can you try now with a more recent pull of master?

It works! Thou, I had to use upstream skulpin = { git = "https://github.com/aclysma/skulpin" }, else it gives me the same error.

I updated the repo to track upstream like you've done. Thanks for trying it out!

Thanks,
Keith


From: Martins Talbergs notifications@github.com
Sent: Monday, January 27, 2020 1:03:40 PM
To: Kethku/neovide neovide@noreply.github.com
Cc: Keith Simmons keith@the-simmons.net; Comment comment@noreply.github.com
Subject: Re: [Kethku/neovide] Tracking upstream: Wayland support not implemented/buggy (#33)

It works! Thou, I had to use upstream skulpin = { git = "https://github.com/aclysma/skulpin" }, else it gives me the same error.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/Kethku/neovide/issues/33?email_source=notifications&email_token=AAZLN375MDBPHAP4KOUMQRLQ75D2ZA5CNFSM4KDFCB4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBBR7Y#issuecomment-578951423, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAZLN356HAVVUSL7GYXBCJLQ75D2ZANCNFSM4KDFCB4A.

This should be fixed now. I'm going to close it. Feel free to reopen if you still run into issues though!

So is Wayland supported now? Neovide still launches as a xwayland client by default on my system. I don't see Wayland mentioned in the README or the Wiki, so how do I instruct it to be a Wayland client? :man_shrugging:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Connor-Frank picture Connor-Frank  Â·  6Comments

basus picture basus  Â·  4Comments

jberryman picture jberryman  Â·  4Comments

noelzubin picture noelzubin  Â·  6Comments

Kethku picture Kethku  Â·  7Comments