x error 8 (BadMatch) on Linux Mint

[ghost]

Opening an 800x600 window from piston_window with GL version 2.1, and rendering the text "Hello, World!" gives the following X-error, though everything seems to have worked fine:

[glutin] x error code=8 major=42 minor=0!

Based on this page it appears that a bad argument is being passed to an xlib function somewhere. (Error code 8 -> BadMatch, described as a "parameter mismatch".)

I can't investigate till later, but I figured I'd open this issue now.

[SimonSapin]

I see the same message on stdout every time I run Servo (on Archlinux x86_64 with GNOME 3), but rendering still seems ok.

There’s probably two parts to this issue:

• Fixing the underlying cause, which might be a "parameter mismatch"
• Should these messages really go to stdout by default? I see in src/api/x11/xdisplay.rs:

        unsafe extern "C" fn x_error_callback(_: *mut ffi::Display, event: *mut ffi::XErrorEvent)
                                              -> libc::c_int
        {
            println!("[glutin] x error code={} major={} minor={}!", (*event).error_code,
                     (*event).request_code, (*event).minor_code);
            0
        }

        unsafe { (xlib.XInitThreads)() };
        unsafe { (xlib.XSetErrorHandler)(Some(x_error_callback)) };

But I don’t think numeric error codes from X11 are very meaningful to developers using gultin, much less end users. What do you think of having x_error_callback be a no-op by default, unless logging is enabled somehow? Maybe with https://crates.io/crates/env_logger/ ?

[elinorbgr]

@SimonSapin The meaningfullness of X11 error messages has been slightly improved by #675 (it now retrieves the error description from xlib).

Other than that, I agree with you regarding error reporting. Maybe, at least, the errors should be written to stderr instead of stdout ?

[tomaka]

I added better error handling for X in #679

As for the actual error, most of the errors I see come from this code: https://github.com/tomaka/glutin/blob/8236564a5224e38cd6e345df8ffaf343bfa24320/src/api/glx/mod.rs#L179-L199

It tries to create a context with version 3.2. If version 3.2 is not supported, an error is returned and it tries to create a context with version 3.1. If an error is returned again, it tries version 1.0. This is a normal process, but every time there is an error it gets printed to stdout.

So this needs more diagnostic (with #679)

[SimonSapin]

#679 looks good to me.

[SimonSapin]

The error message I get with #679 is "Failed to call XSendEvent after wakeup", which is api::x11::WindowProxy::wakeup_event_loop, not api::glx::ContextPrototype::finish.

[francesca64]

This doesn't look relevant anymore, and even if it were, it would now be a problem with winit.