ggez: Creating context fails with "glxSwapIntervalMESA failed"
Whenever ggez tries to make a context, it fails with UnknownError("glxSwapIntervalMESA failed"). I’ve included at the end a backtrace running the hello_world example (as of commit 40d70a79bb3f46c75b4d11bd4424c036c540a9fd).
This is running in a VM, which seems extremely likely to be the issue at some level. It’s a Ubuntu 16.04 VM running on a Windows 7 host in VMWare Workstation 12. Here’s the output of glxinfo.
I’ve tried modify the OpenGL version used, to no avail: I’ve tried 3.0, 2.1, and 1.1. Here’s the diff showing what I did in case I did it wrong:
diff --git a/examples/hello_world.rs b/examples/hello_world.rs
index 58e8e9b..c3138fd 100644
--- a/examples/hello_world.rs
+++ b/examples/hello_world.rs
@@ -62,7 +62,8 @@ impl event::EventHandler for MainState {
// do the work of creating our MainState and running our game,
// * then just call `game.run()` which runs the `Game` mainloop.
pub fn main() {
- let c = conf::Conf::new();
+ let mut c = conf::Conf::new();
+ c.backend = conf::Backend::OpenGL{major: 3, minor:0};
let ctx = &mut Context::load_from_conf("helloworld", "ggez", c).unwrap();
// We add the CARGO_MANIFEST_DIR/resources do the filesystems paths so
And here’s the backtrace:
cargo run --example hello_world
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/examples/hello_world`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UnknownError("glxSwapIntervalMESA failed")', libcore/result.rs:945:5
stack backtrace:
0: 0x55ef91ea6c63 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h038efa1ead8ee277
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: 0x55ef91ea14c4 - std::sys_common::backtrace::_print::haa2469a6e6008f11
at libstd/sys_common/backtrace.rs:71
2: 0x55ef91ea5c0d - std::panicking::default_hook::{{closure}}::ha5918fb5e6555fa7
at libstd/sys_common/backtrace.rs:59
at libstd/panicking.rs:206
3: 0x55ef91ea5909 - std::panicking::default_hook::h4ddc2e74f1ee24ea
at libstd/panicking.rs:222
4: 0x55ef91ea606f - std::panicking::rust_panic_with_hook::hf7d91abe57c1b397
at libstd/panicking.rs:400
5: 0x55ef91ea5e92 - std::panicking::begin_panic_fmt::h83678fb4d002c950
at libstd/panicking.rs:347
6: 0x55ef91ea5dc2 - rust_begin_unwind
at libstd/panicking.rs:323
7: 0x55ef91eec670 - core::panicking::panic_fmt::h28698393dd7f7d54
at libcore/panicking.rs:71
8: 0x55ef91986657 - core::result::unwrap_failed::hb6a6cad29b2abe59
at /checkout/src/libcore/macros.rs:23
9: 0x55ef919864b6 - <core::result::Result<T, E>>::unwrap::h87e337a4feea38b9
at /checkout/src/libcore/result.rs:782
10: 0x55ef91991f0d - hello_world::main::h2b713c399af204e2
at examples/hello_world.rs:66
11: 0x55ef91992f01 - std::rt::lang_start::{{closure}}::h4119ece9ec322894
at /checkout/src/libstd/rt.rs:74
12: 0x55ef91ea5d27 - std::panicking::try::do_call::hc331ed8d98dd7e72
at libstd/rt.rs:59
at libstd/panicking.rs:305
13: 0x55ef91eb1f9e - __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
14: 0x55ef91ea6533 - std::rt::lang_start_internal::h2271475d0185b808
at libstd/panicking.rs:284
at libstd/panic.rs:361
at libstd/rt.rs:58
15: 0x55ef91992ee1 - std::rt::lang_start::h376a47b757c20492
at /checkout/src/libstd/rt.rs:74
16: 0x55ef919923fd - main
17: 0x7fa35d9b482f - __libc_start_main
18: 0x55ef91985858 - _start
19: 0x0 - <unknown>
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 15 (9 by maintainers)
Thanks!
This does seems like a situation where you’d like to make as many errors soft as possible: it’s not like the people using ggez are going to repent and write better code if the errors are hard, since the problematic code is presumably their drivers. I’d even favor making the DPI check recoverable (of course, I’m motivated by the prospect of being able to use ggez without maintaining the world’s tiniest fork).
All that said, I’m not sure what a good way to deal with soft errors would be: maybe also return a vector of errors?