NoAvailablePixelFormat error

[gheoan]

Running the window example on Windows 10, with Intel GMA X4500 GPU results in error NoAvailablePixelFormat at .\examples/window.rs:11. Glutin version is 0.9.1. Is it possible to configure the context to support this GPU? Let me know if more information is needed.

[jrmiller82]

Try commenting out the .with_multisampling(x); line in your rust file. You'll lose antialiasing, but that should work. Don't forget to add a terminal semicolon to the line above if your commenting out the other line changes the semicolon flow.

But, yes, this is definitely a bug, glutin needs to check if the underlying system's OpenGL is high enough version to support the features called by glutin.

[jrmiller82]

Devs, I have this same issue on Debian unstable on an older Lenovo Thinkpad x201, as well as on an Ubuntu 17.04 system running on a virtualbox VM.

[gheoan]

This is not neccesary a bug. I do not expect glutin to support a GPU with OpenGL version 1.1 (Intel GMA X4500). However, the error is not very descriptive and there is no documentation regarding minimum supported OpenGL version.

[jrmiller82]

% glxinfo | grep "version"
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 17.0.3
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Here's the output from my virtualbox machine. Looking like max core is 3.3. Not 1.1.

[tomaka]

The error is not a matter of supported OpenGL version.
Glutin queries the system for the configuration you request (multisampling, sRGB, depth buffer size, etc.) and if the system doesn't support this configuration, then NoAvailablePixelFormat is returned.

[lo48576]

Same error occured in my environment (gentoo linux amd64) with gfx_device_gl and gfx_window_glutin crates and glutin::GlProfile::Core, gfx::format::Srgba8 and gfx::format::DepthStencil config.

The error happened with mesa-17.2.0_rc3 but didn't happen with mesa-17.1.6 or older versions.

[Cxarli]

This issue also appears on Linux (Antergos - Arch based)

$ glxinfo | grep "version"
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 17.2.0
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

GPU is Nvidia GTX 1050. This error seems to have happened after updating mesa from 17.1.8-1 to 17.1.8-2. Also the most recent version of 17.2.0-2 gives this error.
Update: Not fixed with mesa 17.2.0-3

Also see PistonDevelopers/piston#1202 for more details.

[gridbugs]

I'm having the same issue on archlinux on a macbook air with intel integrated graphics. Downgrading mesa from 17.2.0-2 to 17.1.8-1 is my temporary workaround.

[lolzballs]

I'm having the same issue on both Intel HD Graphics 630 and GTX 1050 via bumblebee.
GTX 1050 directly with proprietary drivers works however.

I'm running Arch with mesa 17.2.0-2.

[Cxarli]

Update: Still the case with mesa-17.2.1-3, glutin v0.9.2 and updated subdependencies.

Update 2: No change for mesa-17.2.2-1, glutin v0.9.2, rust 1.20.0

[norru]

Mee Too!™

Just got NoAvailablePixelFormat error on Devuan Ceres, Lenovo Thinkpad X1 (Intel 520), rust 1.22.0-nightly, glutin 0.10.0. I have resumed work on my gfx "demo" and just managed to port and run from rust 1.12, just to see it panicking. As it stands, this is a showstopper.

  nico@lenovo-devuan:~/Projects/itadinanta/rust-oids$ glxinfo | grep version
  server glx version string: 1.4
  client glx version string: 1.4
  GLX version: 1.4
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
  OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0
  OpenGL core profile shading language version string: 4.50
  OpenGL version string: 3.0 Mesa 17.2.0
  OpenGL shading language version string: 1.30
  OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.2.0
  OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

[norru]

It is Srgb's fault. Uncommenting the "does not work" line below reproduces the error. As a result I had to replace all Srgba8 pixelformats in my gfx calls to Rgba8 - perhaps one for @kvark - and do the gamma correction in the tonemapper's fragment program.

	const WIDTH: u32 = 1024;
	const HEIGHT: u32 = 1024;

	let mut events_loop = glutin::EventsLoop::new();

	let builder = glutin::WindowBuilder::new()
		.with_title("Box2d + GFX".to_string())
		.with_dimensions(WIDTH, HEIGHT);

	let context_builder = glutin::ContextBuilder::new()
		//.with_srgb(true) <--- does not work
		.with_gl(glutin::GlRequest::Latest)
		.with_gl_robustness(glutin::Robustness::TryRobustNoResetNotification)
		.with_gl_profile(glutin::GlProfile::Core)
		.with_multisampling(1)
		.with_depth_buffer(24u8)
		.with_stencil_buffer(8u8)
		.with_pixel_format(24u8, 0u8)
		.with_vsync(true);


	let window = glutin::GlWindow::new(builder, context_builder, &events_loop).unwrap();

[lo48576]

FYI: 102354 – Mesa 17.2 no longer can give SRGB-capable framebuffer on i965, even though Mesa 17.1.x does. seems causing this issue.
(I'm sorry if I am wrong).

[rivertam]

I'm not sure exactly what's happening, but with mesa 17.4.0-devel and 17.3.0-devel, this issue is still occurring despite indications that it should be fixed on master (which I believe is currently 17.3.0; versions are confusing me because oibaf has 17.4.0 available while mesa's website only has 17.3.0. Both have been updated since the patch should have gone out, as far as I can tell). .with_srgb(true) does not fix the issue for me. I'm unclear on how to downgrade mesa safely, so I'm probably going to hold off until mesa resolves the issue on newer, accessible packages, unless someone has any guidance for me.

glxinfo | rg opengl yields:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.4.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.4.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

[Cxarli]

This issue seems to be fixed with the latest mesa 18.*. Please see PistonDevelopers/piston#1202 for more information

[fasihrana]

I'm working on a webrender based GUI framework and I get this error when executing the program via a remotedesktop connection on windows. Might this issue be causing the same error for me which is NoAvailablePixelFormat ?

[nickelc]

The problem is gone on my laptop with archlinux for X11 and wayland.

$ glxinfo | grep -i opengl
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 965GM 
OpenGL version string: 2.1 Mesa 18.3.1
OpenGL shading language version string: 1.20

$ cargo run --example window
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s                                                                
     Running `target/debug/examples/window`
Pixel format of the window's GL context: PixelFormat { hardware_accelerated: true, color_bits: 24, alpha_bits: 8, depth_bits: 24, stencil_bits: 8, stereoscopy: false, double_buffer: true, multisampling: None, srgb: false }
OpenGL version 2.1 Mesa 18.3.1

[goddessfreya]

@gheoan @fasihrana See #952 (comment)

[RpxdYTX]

Getting this error on windows 8.1 when trying to use ContextBuilder::new ().build_windowed (/* ... */)

[maroider]

Is this a native windows installation or is it running in a VM?

[RpxdYTX]

I am not sure, it seems native, but the performance is significantly better than before, it also contains an installation of Oracle's VM

I am not sure because the computer broke and i brought it to someone that could fix it, when it came, it was with Oracle VirtualBox installed.

Also, it was a x86 processor, but suddently when i got it back it was suddently in a 64-bit OS

[RpxdYTX]

I tried running msinfo32 but nothing about VMs appeared, so i guess i am in native

[RpxdYTX]

Also, using the crate glfw and gl_loader worked for me, i used a macro to transmute the pointer to a function pointer, not only did everything work, but I was even able to use a nice blue color in a basic window.

I really dunno why glutin does not work