winit: winit panicks failing to find x11 monitor

copied from https://github.com/tomaka/glutin/issues/1018:

When I iterate over available monitors with events loop, nothing is returned, and attempting to call get_primary_monitor() will crash:

extern crate glium;
use glium::glutin;

fn main () {
  {
    let events_loop = glutin::EventsLoop::new();
    let mut available_monitors_count = 0; 
    for i in events_loop.get_available_monitors() {
      available_monitors_count += 1;
    }
    println!("avilable monitors count: {}", available_monitors_count);  // prints '0'
    let primary_monitor = events_loop.get_primary_monitor(); // crash 1
  }
  let events_loop = glutin::EventsLoop::new();  // crash 2
}

crash 1 with:

thread 'main' panicked at '[winit] Failed to find any x11 monitor', libcore/option.rs:916:5

If crash 1 is commented out, then code will reach crash 2 with:

thread 'main' panicked at 'Failed to call XInternAtom: XError { description: "BadRequest (invalid request code or no such operation)", error_code: 1, request_code: 140, minor_code: 42 }', libcore/result.rs:945:5

Previously the iter loop would show some available monitors, and the primary monitor would be returned, but I’m not sure exactly what has changed since the last time it worked. This is on end of life LTS Ubuntu (14.04) so it may be something out of date.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 23 (23 by maintainers)

Most upvoted comments

@spearman this branch adds some debug messages: https://github.com/francesca64/winit/tree/x11-randr

@b-r-u XRRGetScreenResources is apparently really slow, so I’m going to look into caching the monitor list and using XRRSelectInput to receive events when the state changes. That’s totally unrelated to this problem; I just enjoy caching things.