window example crash on x11
ghashy opened this issue · comments
Description
I cloned master branch and executed cargo run --release --example window
, and got crash:
RUST_BACKTRACE=full cargo run --release --example window
Finished release [optimized] target(s) in 0.08s
Running `target/release/examples/window`
2024-04-23T09:27:41.443493Z INFO window: Starting to send user event every second
2024-04-23T09:27:41.443623Z INFO window: Loading cursor assets
2024-04-23T09:27:41.443892Z INFO window: Resumed the event loop
2024-04-23T09:27:41.443898Z INFO window: Monitors information
2024-04-23T09:27:41.444833Z INFO window: Primary monitor: DP-2
2024-04-23T09:27:41.444839Z INFO window: Current mode: 2560x1440 @ 59.950 Hz
2024-04-23T09:27:41.444842Z INFO window: Position: 0,0
2024-04-23T09:27:41.444845Z INFO window: Scale factor: 1
2024-04-23T09:27:41.444849Z INFO window: Available modes (width x height x bit-depth):
2024-04-23T09:27:41.444853Z INFO window: 2560x1440x24 @ 59.950 Hz
2024-04-23T09:27:41.444856Z INFO window: 1280x720x24 @ 59.855 Hz
2024-04-23T09:27:41.444865Z INFO window: Using token ActivationToken { _token: "gnome-shell/kitty/1954-0-home_TIME662865" } to activate a window
2024-04-23T09:27:41.444912Z INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1
thread 'main' panicked at examples/window.rs:478:14:
failed to create initial window: PlatformError(Some("Visual 0x23 does not use softbuffer's pixel format and is unsupported"), None)
stack backtrace:
0: 0x556deb8ed486 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h410d4c66be4e37f9
1: 0x556deb919e60 - core::fmt::write::he40921d4802ce2ac
2: 0x556deb8ea1af - std::io::Write::write_fmt::h5de5a4e7037c9b20
3: 0x556deb8ed264 - std::sys_common::backtrace::print::h11c067a88e3bdb22
4: 0x556deb8ee937 - std::panicking::default_hook::{{closure}}::h8c832ecb03fde8ea
5: 0x556deb8ee699 - std::panicking::default_hook::h1633e272b4150cf3
6: 0x556deb8eee38 - std::panicking::rust_panic_with_hook::hb164d19c0c1e71d4
7: 0x556deb8eed12 - std::panicking::begin_panic_handler::{{closure}}::h0369088c533c20e9
8: 0x556deb8ed986 - std::sys_common::backtrace::__rust_end_short_backtrace::hc11d910daf35ac2e
9: 0x556deb8eea64 - rust_begin_unwind
10: 0x556deb9176d5 - core::panicking::panic_fmt::ha6effc2775a0749c
11: 0x556deb917bc3 - core::result::unwrap_failed::ha188096f98826595
12: 0x556deb5ece21 - <window::Application as winit::application::ApplicationHandler<window::UserEvent>>::resumed::hde5dec4d1f4476ac
13: 0x556deb6165ac - winit::platform_impl::platform::x11::EventLoop<T>::run_on_demand::h7026944958537c2f
14: 0x556deb5d3c53 - window::main::hd1a3b65b71c6f9e9
15: 0x556deb61d4f3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hc914f2e7a41b0e6e
16: 0x556deb62fb99 - std::rt::lang_start::{{closure}}::ha5494edbbfb7d859
17: 0x556deb8e4d11 - std::rt::lang_start_internal::h4d236095b69a230b
18: 0x556deb5ef215 - main
19: 0x7f9c8f029510 - __libc_start_call_main
20: 0x7f9c8f0295c9 - __libc_start_main_alias_1
21: 0x556deb5c9c55 - _start
22: 0x0 - <unknown>
~/Downloads/winit-master is 📦 v0.29.15 via 🦀 v1.77.2
OS: Linux fedora 36, Imac 2012, nvidia 675mx
Debugging output
No response
Window isn't shown unless you draw
- I understand that windows aren't shown on Wayland unless I draw and present to them.
Winit version
0.29.15
That's x11.
The error comes from here: https://github.com/rust-windowing/softbuffer/blob/28ebe6e7373bae59196bff5b39d047bcc0a41137/src/backends/x11.rs#L271
Uhm.... I can reproduce this?!?
$ cargo run --quiet --example window > /dev/null
thread 'main' panicked at 'failed to create initial window: PlatformError(Some("Visual 0x7a does not use softbuffer's pixel format and is unsupported"), None)', examples/window.rs:467:46
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Commit ea70f77 works (randomly chosen old commit). This leads to:
4f47a4e7932fb939408bfa191b5b86428974e5d1 is the first bad commit
commit 4f47a4e7932fb939408bfa191b5b86428974e5d1
Author: daxpedda <daxpedda@gmail.com>
Date: Thu Apr 18 21:52:38 2024 +0200
Update dev-dependencies (#3641)
Cargo.toml | 4 ++--
examples/util/fill.rs | 21 +++++++++++++++------
examples/window.rs | 22 ++++++++++++++++------
3 files changed, 33 insertions(+), 14 deletions(-)
This updated image from 0.24.0 to 0.25.0 and softbuffer from 0.3.0 to 0.4.0.
At that commit, after cargo update --package softbuffer --precise 0.4.0
. things still work. With 0.4.1, I get the failure. Uhm...
Another bisect in softbuffer points at:
09b8126909031eb442a638020fb3d9062de958b9 is the first bad commit
commit 09b8126909031eb442a638020fb3d9062de958b9
Author: Uli Schlachter <psychon@users.noreply.github.com>
Date: Mon Dec 11 06:54:10 2023 +0100
x11: Check visuals for validity
A visual describes how colors are laid out by the X11 server. So far,
softbuffer did not do anything with visuals and just passed them around.
This commit adds checks that should ensure that a given visual actually
lays out pixels in the only format supported by softbuffer:
- 32 bit per pixel
- 00RRGGBB byte order
In this patch, I also try to handle big endian systems and mixed endian
situations where we are e.g. running on a big endian system and talking
to a little endian X11 server. However, this is all theoretical and
completely untested. I only tested my X11 server's default visual works
and some ARGB visual is rejected.
Fixes: https://github.com/rust-windowing/softbuffer/issues/184
Signed-off-by: Uli Schlachter <psychon@znc.in>
Co-authored-by: John Nunley <dev@notgull.net>
src/x11.rs | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 70 insertions(+), 1 deletion(-)
Uhm... apparently I did this. 🙈
Seems like winit uses softbuffer with some unsupported visuals.
A "fix" is:
diff --git a/examples/window.rs b/examples/window.rs
index 437d90ec..b79f75ae 100644
--- a/examples/window.rs
+++ b/examples/window.rs
@@ -132,7 +132,7 @@ impl Application {
#[allow(unused_mut)]
let mut window_attributes = Window::default_attributes()
.with_title("Winit window")
- .with_transparent(true)
+ //.with_transparent(true)
.with_window_icon(Some(self.icon.clone()));
#[cfg(any(x11_platform, wayland_platform))]
Dunno what a proper fix would be. Not use softbuffer? Talk them into supporting alpha channels (but I don't think they want to do that).
CC @notgull