piston: Couldn't find any pixel format that matched the criterias.

I have been able to run my own programs using piston for a while, but since a few days I suddenly get this error.

When trying to run cargo run --bin hello_world from the piston_examples:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Couldn\'t find any pixel format that matches the criterias."', /checkout/src/libcore/result.rs:860:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic_new
             at /checkout/src/libstd/panicking.rs:553
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:521
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:92
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:41
  10: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:738
  11: hello_world::main
             at src/hello_world.rs:7
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:458
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  14: main
  15: __libc_start_main
  16: _start

System

Antergos, based on Arch Linux $ uname -r: 4.12.12-1-ARCH $ cargo --version: cargo 0.21.0 (5b4b8b2ae 2017-08-12) $ rustc --version: rustc 1.20.0 (f3d6973f4 2017-08-27) $ rustup --version: rustup 1.6.0

glxinfo recently updated packages, most notably:

upgraded mesa (17.1.8-1 -> 17.1.8-2)
upgraded gtk3 (3.22.19-2 -> 3.22.20-1)
upgraded linux (4.12.10-1 -> 4.12.12-1)

Update 4: All intermediate versions of mesa (17.1.8-1, 17.1.8-2, 17.2.0-2, 17.2.0-3, 17.2.1-3, 17.2.2-1) have this same problem.

Let me know if you need more information 😄

Update: Seems to be the case for all OpenGL versions. Rebooting didn’t work either. Update 2: Also happens on a clean Debian 9 (kernel 4.9.0-3-amd64) build in VirtualBox 5.1.26 Update 3: Also happens on Rust 1.19.0, and Rust 1.18.0 and earlier don’t compile

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 8
Comments: 45 (5 by maintainers)

Commits related to this issue

Fix error with old versions of mesa See: https://github.com/PistonDevelopers/piston/issues/1202 for details. — committed to AgustinCB/emulators by deleted user 6 years ago

Most upvoted comments

Working around this issue should just be a matter of requesting a PistonWindow with sRGB disabled. Unfortunately some of the higher level APIs override this setting for you. However, it should work if you directly create the window like this:

extern crate piston_window;
use piston_window::*;

let mut window: PistonWindow = PistonWindow::new(
    OpenGL::V3_3,
    0,
    WindowSettings::new("Hello World!", [640 480])
        .opengl(OpenGL::V3_3)
        .srgb(false)
        .build()
        .unwrap(),
);

+11

fintelia on Feb 25, 2018

Solution which helped me on Arch Linux: sudo pacman -U https://archive.archlinux.org/packages/m/mesa/mesa-17.1.0-1-x86_64.pkg.tar.xz

hanula on Dec 21, 2017

Fix has been pushed to Mesa master, now Mesa exposes BGRA8888 sRGB visuals. I will try to get it for mesa stable but as there are risks with that it might be that it will only come to new Mesa releases.

tpalli on Nov 9, 2017

Arch Linux was updated to Mesa 18.0 recently, so I tested my Piston project and it works now.

pmarcelll on Apr 10, 2018

This bug is terrible, I have waited months for the fix. Is there any workaround for it?

juchiast on Feb 25, 2018

@ibrokemypie soon (within the next few days), we are going to have Mesa 18.0.0 with a fix for this. Until then you could try an RC build of 18.0.0.

est31 on Feb 8, 2018

Update 4: Line 143 of piston_window/src/lib.rs looks suspicious:

// Turn on sRGB.
let settings = settings.clone().srgb(true);

Commenting out that line (and keeping glutin unmodified) also fixes all problems. I don’t think it has any use to dive into it more.

Cxarli on Sep 11, 2017

Can also confirm this is now working again on my system with mesa 18.0.1-1. Thanks for the help everyone 😊

Cxarli on May 2, 2018

@eisterman The 17.3 branch will never be fixed, even though it is still maintained. See the comment by the mesa developer above. All you can do is to wait for 18.0 which has the fix. There has been a 4th release candidate for 18.0 on Feb 9 and according to schedule we should already have had 18.0.1 on Feb 23 but there was no such message on the mesa announce list nor any message about the 18.0 branch after the rc4 email. Let’s see when we’ll get an official release of mesa version 18.0 that has the fix 😃. Look for emails on the mesa-announce list 😃.

est31 on Feb 26, 2018

If you can specify that you don’t need certain GLX features, you may get the window created.

I’m on my phone now so can’t give a comprehensive reply, but if you have a read of the following gist, it may help you to figure out how to fix your particular set up:

https://gist.github.com/azriel91/7a33da3061fa1fb734083e8d22451f91

azriel91 on Feb 25, 2018

Thanks Tapani!

bvssvni on Oct 23, 2017

Note on my compilation setup (on Ubuntu 17.10 artful; after having done apt build-dep libgl1-mesa-glx):

git clone https://anongit.freedesktop.org/git/mesa/mesa.git
cd mesa
git checkout mesa-17.1.9
./autogen.sh --prefix=/path/to/desired/mesa-inst --with-gallium-drivers="i915,swrast" --with-dri-drivers="i915,i965,swrast"
make -j 8
make install

And then I ran the tools with the given mesa installation like: LD_LIBRARY_PATH=/path/to/desired/mesa-inst/lib <your command here>

I’m not a fan of sudo make install, I don’t want stuff that is not my package manager to mess with my root.

est31 on Oct 20, 2017