torizon / vscode-torizon-templates

VS Code Torizon Integrated Development Environment Templates
MIT License
17 stars 23 forks source link

Slint templates not showing the GUI on the display #203

Closed andreriesco closed 2 months ago

andreriesco commented 5 months ago

When trying to run the Slint templates on the board, the GUI is not shown on the display.

With the following message on rustSlint:

Protocol error 0 on object zwp_linux_explicit_synchronization_v1@36: 
Error: Other("Error running winit event loop: Exit Failure: 1")

And with the following message, with the same error, on cppSlint:

Protocol error 0 on object zwp_linux_explicit_synchronization_v1@36: 
thread '<unnamed>' panicked at api/cpp/lib.rs:64:6:
called `Result::unwrap()` on an `Err` value: Other("Error running winit event loop: Exit Failure: 1")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

@tronical do you know what may be the issue?

andreriesco commented 5 months ago

On cppSlint, when adding the environment variable RUST_BACKTRACE=full, this is the message shown:

Protocol error 0 on object zwp_linux_explicit_synchronization_v1@36: 
thread '<unnamed>' panicked at api/cpp/lib.rs:64:6:
called `Result::unwrap()` on an `Err` value: Other("Error running winit event loop: Exit Failure: 1")
stack backtrace:
   0:     0xffffa861bdac - std::backtrace_rs::backtrace::libunwind::trace::h4210404a228eb944
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/libunwind.rs:105:5
   1:     0xffffa861bdac - std::backtrace_rs::backtrace::trace_unsynchronized::hea2e482630a56378
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0xffffa861bdac - std::sys_common::backtrace::_print_fmt::h326180b7b26e4e21
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:68:5
   3:     0xffffa861bdac - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::haee13570c31cb77b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:44:22
   4:     0xffffa86446f8 - core::fmt::rt::Argument::fmt::hee8176c00818b355
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/rt.rs:142:9
   5:     0xffffa86446f8 - core::fmt::write::he0b40f3f74e7e87c
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/mod.rs:1153:17
   6:     0xffffa861837c - std::io::Write::write_fmt::hc8024efb884f388c
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/io/mod.rs:1843:15
   7:     0xffffa861bbf8 - std::sys_common::backtrace::_print::he99739ec6cb2be23
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:47:5
   8:     0xffffa861bbf8 - std::sys_common::backtrace::print::hf1431a2be8ae8207
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:34:9
   9:     0xffffa861d33c - std::panicking::default_hook::{{closure}}::ha26cf0d89fc27676
  10:     0xffffa861cff0 - std::panicking::default_hook::hddcfc2aac016eb46
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:292:9
  11:     0xffffa861d748 - std::panicking::rust_panic_with_hook::hbd9f5866892982cc
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:779:13
  12:     0xffffa861d5f8 - std::panicking::begin_panic_handler::{{closure}}::hf930a65f0587fc68
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:657:13
  13:     0xffffa861c270 - std::sys_common::backtrace::__rust_end_short_backtrace::h8aeef1aadd5204df
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:171:18
  14:     0xffffa861d390 - rust_begin_unwind
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:645:5
  15:     0xffffa797ced0 - core::panicking::panic_fmt::h3c23aa0af13818a0
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:72:14
  16:     0xffffa797d224 - core::result::unwrap_failed::h96aa0d56e71b0bb4
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1654:5
  17:     0xffffa7980914 - slint_run_event_loop
  18:     0xaaaace696928 - _ZN5slint14run_event_loopENS_13EventLoopModeE
                               at /usr/include/slint/slint.h:1353:43
  19:     0xaaaace6a27dc - _ZN9AppWindow3runEv
                               at /home/torizon/app/build/arm64/appwindow.h:3332:26
  20:     0xaaaace693f3c - main
                               at /home/torizon/app/src/main.cpp:15:12
  21:     0xffffa7457780 - <unknown>
  22:     0xffffa7457858 - __libc_start_main
  23:     0xaaaace693cf0 - _start
  24:                0x0 - <unknown>
Aborted (core dumped)
tronical commented 5 months ago

Is this with a new version of Weston?

does reverting https://github.com/toradex/vscode-torizon-templates/commit/97c66e02c71da4142d99d537afab7e829201f9eb help?

andreriesco commented 5 months ago

I tried here, it does seem to solve the issue. Also, I tried here and changing from 3.3.0-bookworm-1.6.0 to 3.3.0-bookworm-1.5.1 does seem to solve the issue, so I think the problem is just with version 1.6.0

tronical commented 5 months ago

Thanks for checking! Yep, somehow there’s an incompatibility between Weston (which is quite old) and slint 1.6.0.

There are two paths forward:

  1. We revert back to 1.5.1.
  2. We change the 1.6.0 based templates to use linuxkms instead of Weston/wayland.

I can work on (2) but I need a bit of time. If you’re planning to make a release soon, then option (1) is the better short-term remedy.

How does your release schedule look like?

andreriesco commented 5 months ago

We are planning to do a release next week, so I think that for the short-term the option (1) is needed. But then, on the next release, we can do the fix described in option (2).

tronical commented 5 months ago

Sounds good to me. do you want to revert or shall I make a PR?

andreriesco commented 5 months ago

I can create it here. I will also add it in the same PR the fix for issue #199

andreriesco commented 5 months ago

Created here, please review @tronical

tronical commented 5 months ago

I've found a workaround for this in Slint now with https://github.com/slint-ui/slint/commit/72e35ea5f946ef89b76213de9c4f1722c8f1270e - that'll be in our next release, to which we can upgrade then :)

microhobby commented 2 months ago

so, we are using the backend-linuxkms-noseat now for Rust Slint and seems to work. @tronical let me know if this is ok for you.

tronical commented 2 months ago

Yes, that’s okay for me. The fix for this issue was already in 1.7 - I forgot about this issue when that was merged. Meanwhile, the switch to the linuxkms backend avoids the problem altogether.