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

[C-Bouthoorn]

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

[juchiast]

This is a problem with glutin back-end. I suggest running the glutin example here: https://github.com/tomaka/glutin/

Below are lines that probably caused the panic:
https://github.com/tomaka/glutin/blob/abd8d2e20d3ab929b20b03c2def11a3c577b9e1f/src/platform/macos/helpers.rs#L63
https://github.com/tomaka/glutin/blob/cf646240a4210fa06bd2534165a451a262eb059c/src/api/egl/mod.rs#L476
https://github.com/tomaka/glutin/blob/c4774367ca22ddb1c27d7d3f8efa2ac295c434a6/src/platform/macos/mod.rs#L71
https://github.com/tomaka/glutin/blob/30ebcadcbf32f11e373ace8ad48112e2efab1c01/src/api/wgl/mod.rs#L114
https://github.com/tomaka/glutin/blob/cf646240a4210fa06bd2534165a451a262eb059c/src/api/glx/mod.rs#L82

Hope this will help!!

[C-Bouthoorn]

All their examples seem to work. 😅 I'll try to see which of those lines might be the issue

Update:

The error seems to originate from api/glx/mod.rs#L82.

The failing function is choose_fbconfig, which is called (by piston_examples) with the following arguments:

extensions: "GLX_ARB_create_context GLX_ARB_create_context_profile GLX_ARB_create_context_robustness GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_fbconfig_packed_float GLX_EXT_framebuffer_sRGB GLX_EXT_create_context_es2_profile GLX_EXT_create_context_es_profile GLX_MESA_copy_sub_buffer GLX_MESA_multithread_makecurrent GLX_MESA_query_renderer GLX_MESA_swap_control GLX_OML_swap_method GLX_OML_sync_control GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group GLX_EXT_texture_from_pixmap GLX_INTEL_swap_event GLX_EXT_buffer_age "

display: 0x7fcabf85a000

screen_id: 0

pf_reqs: PixelFormatRequirements { hardware_accelerated: Some(true), color_bits: Some(24), float_color_buffer: false, alpha_bits: Some(8), depth_bits: Some(24), stencil_bits: Some(8), double_buffer: None, multisampling: None, stereoscopy: false, srgb: true, release_behavior: Flush }

transparent: false

compare to what the glutin examples call it with

extensions: "GLX_ARB_create_context GLX_ARB_create_context_profile GLX_ARB_create_context_robustness GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_fbconfig_packed_float GLX_EXT_framebuffer_sRGB GLX_EXT_create_context_es2_profile GLX_EXT_create_context_es_profile GLX_MESA_copy_sub_buffer GLX_MESA_multithread_makecurrent GLX_MESA_query_renderer GLX_MESA_swap_control GLX_OML_swap_method GLX_OML_sync_control GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group GLX_EXT_texture_from_pixmap GLX_INTEL_swap_event GLX_EXT_buffer_age "

display: 0x7f545a45a000

screen_id: 0

pf_reqs: PixelFormatRequirements { hardware_accelerated: Some(true), color_bits: Some(24), float_color_buffer: false, alpha_bits: Some(8), depth_bits: Some(24), stencil_bits: Some(8), double_buffer: None, multisampling: None, stereoscopy: false, srgb: false, release_behavior: Flush }

transparent: false

The only difference (besides display) seems to be that pf_regs.srgb == true for piston_examples, and pf_regs.srgb == false for the glutin examples.

Searching for issues regarding srgb on piston yielded no results. On the piston_window repo, 2 were found, of which one seemed related: PistonDevelopers/piston_window#139

Update 2:
It seems as if the value of WindowSettings.srgb is completely ignored. It doesn't matter if you call .srgb(false) or .srgb(true), the value of pf_reqs.srgb remains true.

However, I never used this function in my project (which is now failing) and the default value seems to always have been true. Besides that, I haven't changed graphics card, and it seems to offer sRGB support.

Update 3:
Adding

let pf_reqs = &mut pf_reqs.clone();
pf_reqs.srgb = false;

before try!(choose_fbconfig(...)) in glutin/src/api/glx/mod.rs around line 82 (thus forcing to disable sRGB) fixes both the piston_examples and my own project.

[C-Bouthoorn]

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.

[crsaracco]

Note for any that are still having this issue: I had to set .srgb(false) on my system. Simply commenting it out didn't help.

[bvssvni]

Notice that sRGB is enabled in piston_window because the shaders assume linear color space. Discussion: PistonDevelopers/gfx_graphics#293

[est31]

Now that Ubuntu 17.10 artful has been released with Mesa version 17.2.2 this issue will affect more people. Including me!

The bug is indeed a regression of Mesa from the 17.1 branch to the 17.2 branch. I've ran a bisect and the first bad commit is:

commit 6e06e281c6ee342276d087ed4ee4a442626e433a
Author: Neha Bhende <bhenden@vmware.com>
Date:   Wed Apr 26 16:21:32 2017 -0700

    glx: add missing sRGB attribute check in fbconfigs_compatible()
    
    This patch will allow driver to choose srgb capable FBconfig
    if GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB attribute is 1
    
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Reviewed-by: Charmaine Lee <charmainel@vmware.com>

I could also reproduce the bug on the latest master branch (commit 59fb59ad54d368683d5cc3b149f021452bddc05f) and on the 17.2.3 release.

There is a bug reported upstream for Mesa: https://bugs.freedesktop.org/show_bug.cgi?id=102354

Supertuxkart ran into the same issue, they ended up supporting a non-sRGB mode: supertuxkart/stk-code#2902

@tpalli has proposed a patch for the issue but it got a negative response during review and was probably abandoned due to that reason, given that there have been multiple stable releases on the 17.2 branch of Mesa since (17.2.2 and 17.2.3) and none of them included the patch.

It would be really nice to have the bug fixed by upstream Mesa!

As people have noted above, reverting to one of the Mesa 17.1.* releases fixes the bug.

Please don't be misled by the "upgraded mesa (17.1.8-1 -> 17.1.8-2)" in the initial comment by @C-Bouthoorn. Both linked glxinfo refers to mesa 17.2.0 and the linked "recently upgraded packages" includes two upgrades of mesa, first the cited one, and second one to 17.2.0. So its definitely caused for @C-Bouthoorn by the upgrade to 17.2 as well.

[est31]

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.

[tpalli]

Hi;

On 10/21/2017 12:47 AM, est31 wrote: Now that Ubuntu 17.10 artful has been released with Mesa version 17.2.2 this issue will affect more people. Including me! The bug is indeed a regression of Mesa from the 17.1 branch to the 17.2 branch. I've ran a bisect and the first bad commit is: |commit 6e06e281c6ee342276d087ed4ee4a442626e433a Author: Neha Bhende ***@***.***> Date: Wed Apr 26 16:21:32 2017 -0700 glx: add missing sRGB attribute check in fbconfigs_compatible() This patch will allow driver to choose srgb capable FBconfig if GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB attribute is 1 Reviewed-by: Brian Paul ***@***.***> Reviewed-by: Charmaine Lee ***@***.***> | I could also reproduce the bug on the latest master branch (commit |59fb59ad54d368683d5cc3b149f021452bddc05f|) and on the 17.2.3 release. There is a bug reported upstream for Mesa: https://bugs.freedesktop.org/show_bug.cgi?id=102354 Supertuxkart ran into the same issue, they ended up supporting a non-sRGB mode: supertuxkart/stk-code#2902 <supertuxkart/stk-code#2902> @tpalli <https://github.com/tpalli> has proposed a patch <https://bugs.freedesktop.org/attachment.cgi?id=134248> for the issue but it got a negative response during review <https://lists.freedesktop.org/archives/mesa-dev/2017-September/168465.html> and was probably abandoned due to that reason, given that there have been multiple stable releases on the 17.2 branch of Mesa since (17.2.2 and 17.2.3) and none of them included the patch. It would be really nice to have the bug fixed by upstream Mesa!

The patch in question has not been abandoned but can be considered 'floating' as there are currently many other issues Mesa team is dealing with and we wanted to try alternative approach. Unfortunately so far I haven't figured out alternative that would not break other applications :/ I will ping some people to consider reviewing this soon if no better fix can be found. // Tapani

[bvssvni]

Thanks Tapani!

[tpalli]

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.

[est31]

@tpalli that's really cool to hear! I'll try it out soon. "Pushed to master" means that it won't appear in any of the 17.2 or 17.3 releases, but need to wait for 17.4, right? It would definitely be nice to have it fixed in 17.2 and 17.3 as well :).

[tpalli]

Yeah, it might land only to 17.4 due to it being a functional change, typically only bugfixes get accepted to stable release.

[est31]

@tpalli I've tested the piston example with recent mesa master now (17.4.0-devel (git-ffc2060616)). It includes your patch, I have verified. It still failed with the familiar error :/. The apitrace dump output is:

2 glXChooseFBConfig(dpy = 0x7f752b28e000, screen = 0, attribList = {GLX_X_RENDERABLE, True, GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR, GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT, GLX_RENDER_TYPE, GLX_RGBA_BIT, GLX_RED_SIZE, 8, GLX_GREEN_SIZE, 8, GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, True, GLX_STEREO, False, GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, 1, GLX_CONFIG_CAVEAT, -1, 0}, nitems = &0) = NULL
5 glXChooseFBConfig(dpy = 0x7f752b28e000, screen = 0, attribList = {GLX_X_RENDERABLE, True, GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR, GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT, GLX_RENDER_TYPE, GLX_RGBA_BIT, GLX_RED_SIZE, 8, GLX_GREEN_SIZE, 8, GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, True, GLX_STEREO, False, GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, 1, GLX_CONFIG_CAVEAT, -1, 0}, nitems = &0) = NULL

[tpalli]

Which distro are you running and are you running with XWayland or pure X/GLX? In case of 'pure X' (like for example Ubuntu 16.04) you will need to install the DRI driver so that X server is using the same one as your Mesa has (running against custom Mesa tree with LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH is not enough). In case of Fedora (XWayland) this should work without replacing system DRI driver.

[est31]

@tpalli I'm running Kubuntu 17.10 with pure X. The test failure is probably due to me only setting LD_LIBRARY_PATH without installing the DRI driver... That one worked when I compiled Mesa 17.1 so I've thought it would work here too. About Wayland: I seem to not be able to reproduce the bug with Weston. Maybe it is using a software renderer?

Is there a way to set the DRI driver without changing something in the root fs? I just don't like to mess with it :).

[tpalli]

Unfortunately this change requires both X server and Mesa to use exact same i965_dri.so because of the added visuals. Weston works because then client is using EGL instead of GLX.

[est31]

@tpalli @Biohazard50 reports that the issue is fixed for them on mesa master. Could we get a fix into 17.2 and 17.3? It is a fix of a regression so I would say that it qualifies as a bugfix.

[tpalli]

Unfortunately there are 3 regression bugs open against this change, therefore stable (17.2, 17.3) is not possible. The regressions are:

https://bugs.freedesktop.org/show_bug.cgi?id=103655
https://bugs.freedesktop.org/show_bug.cgi?id=103699
https://bugs.freedesktop.org/show_bug.cgi?id=103646

[est31]

@tpalli I see, thanks.

[sunjay]

Is there anything I can do if I'm experiencing this issue? I'm trying to run some GUI tests on Travis CI. Travis does support GUI testing with xvfb, but trying to run my tests results in the error described in this issue.

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value:
"Couldn\'t find any pixel format that matches the criterias."', /checkout/src/libcore/result.rs:906:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

If it helps, here are my build logs. This is a problem I've also experienced when trying to run an app using piston_window on a Windows virtual machine using VirtualBox. Seems to happen a lot. ☹️

Is there a way to work around it?

[est31]

@sunjay see my comment above: #1202 (comment)

[sunjay]

@est31 Thanks. I went down the rabbit hole of trying to install mesa on Travis. No luck yet, but I will try again tomorrow. :)

[fintelia]

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(),
);

[eisterman]

Mesa 17.3.5-1 on Arch Linux is still bugged.

Downgrading to 17.1.0-1 temporarily fix the problem

[est31]

@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 :).

[pmarcelll]

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

[est31]

I've just updated to Ubuntu bionic (18.04) which uses Mesa 18.0.0-rc5. Can confirm that the bug is fixed. 🎉

[juchiast]

Yeah, Fedora 28 is fixed too!

[C-Bouthoorn]

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

[JeffBusterCase]

The error still occurs on Arch linux updated. Using mesa 18.0.4-1 and rustup default nightly. And by using arch, I am unable to install other mesa version.

[est31]

@JeffBusterCase what does glxinfo | grep "renderer string" say?

[JeffBusterCase]

@est31 It says: OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile

[pmarcelll]

Are you absolutely sure your program is not using anything that is not supported by the GPU (OpenGL 4.1+, high level of anti-aliasing, etc.).

[C-Bouthoorn]

@JeffBusterCase It works fine on my system:

Arch: 4.16.13-1
mesa: 18.0.4-1
glxinfo: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
Project: hello world example
Rust: 1.26.1 (stable) and 1.28.0 (nightly)

[JeffBusterCase]

@C-Bouthoorn even hello_world doesn't work.

No more clue about what is happening, but maybe is cause I'm accessing it by chroot, so it makes me directs this question to some other repo. Thanks by the way. :)

[nyghtly-derek]

Still getting this error on lubuntu. Updating the mesa drivers didn't work. Still need to test the srgb fix.

OS: Ubuntu 18.04 LTS
Project: hello world example
Rust: stable (1.27.1) + nightly (not sure how to check version)

EDIT: error continues even with .srgb(false) fix; am I missing something?

EDIT2: here is a snippet from backtrace of another project....

9: <core::result::Result<T, E>>::unwrap
                         at /checkout/src/libcore/result.rs:782
10: double_tetris::init_window
                         at src/main.rs:372

And here is the init_window() function...

fn init_window() -> PistonWindow {
    let window: PistonWindow = {
        WindowSettings::new("DoubleTet", WINDOW_DIMENSIONS)
            .exit_on_esc(true)
            .build()
            .unwrap()
    };
    window
}

Everything runs fine on a separate Windows 10 setup.

[fintelia]

@nyghtly-derek You don't seem to be hitting this bug, but rather window creating is failing for some other reason. You should look at exactly what Err() value is being returned by build, and then if the cause isn't obvious, figure out where that specific kind of error is generated.

[nyghtly-derek]

@fintelia I'm think I'm getting the same error. It reads:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Couldn\'t find any pixel format that matches the criterias."', libcore /result.rs:945:5

[fintelia]

@nyghtly-derek The fact that you have an updated mesa version and that disabling sRGB doesn't fix the issue strongly suggests that you are actually running into a different problem. It would probably be better to open a new issue if you aren't able to figure it out, but to point you in the right direction, you may want to compare the exact pixel format parameters you're requesting to the supported ones shown by glxinfo.