winit: `get_current_monitor()` panics on Wayland.

See: https://github.com/ggez/ggez/issues/579

Basically, this function does a some_vec.last().unwrap() of a Vec that can be null. The vec appears to be acquired from sctk::surface::get_outputs() here: https://github.com/Smithay/client-toolkit/blob/2c28ada5c7dd067ac1245382bc371cc933d4c416/src/surface.rs#L109 . As far as I can tell, the outputs vec is created empty and only has things added to it on SurfaceUserData::enter(), but I don’t know enough about the Wayland protocol to understand what’s actually going on there.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 21 (16 by maintainers)

Commits related to this issue

Most upvoted comments

I’m working on that issue right now during some other rework, just could take a bit of time for me to finish.

Just thinking more about that fullscreen startup problem on Wayland. I feel like we can change the Fullscreen enum from

#[derive(Clone, Debug, PartialEq)]
pub enum Fullscreen {
    Exclusive(VideoMode),
    Borderless(MonitorHandle),
}

To

#[derive(Clone, Debug, PartialEq)]
pub enum Fullscreen {
    Exclusive(VideoMode),
    Borderless(Option<MonitorHandle>),
}

The None will be treated like ‘let the system decide’, which will most of the time result in a current monitor being picked on at least Wayland. If the platform doesn’t have a concept of ‘let the system decide’ like on Wayland, it may fallback to picking current monitor by itself.

I’m not sure what to do about Exclusive fullscreen, since Wayland doesn’t have such things at all, so having it under Option isn’t something I can speak for.

What to do you think @chrisduerr , @murarth , @Osspial, @ryanisaacg , @francesca64 ?