window example crash on x11

[ghashy]

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

[kchibisov]

That's x11.

[psychon]

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