ggez: WindowError(SdlError("Could not create GL context"))

FINALLY we got mesa 18.0 which should include a fix for this bug. Looking forward to mesa 18.0 hitting all the distros, then this issue should be history.

This sounds very much like a known regression of the intel i965 MESA driver from the 17.1 branch to the 17.2 branch. See my comment for the piston engine for more: https://github.com/PistonDevelopers/piston/issues/1202#issuecomment-338330125

For the users I suggest to obtain MESA 17.1 (e.g. by compiling it yourself). For the maintainers of ggez I suggest to add a non-srgb mode to work on intel hardware on MESA 17.2. Don’t please ping the MESA developers, they are already aware of the bug!

@cider-teeworlds If I started a patreon with the promise that I would work on making ggez support older hardware if people donated, would you donate? 😄

@AaronM04 the workaround that I apply is to downgrade to mesa 17.1: https://github.com/PistonDevelopers/piston/issues/1202#issuecomment-338331123

The 17.2 series has the bug as well as the 17.3 series. One has to wait for Mesa 18.0 to come out or compile mesa master 😕. But in order to get it working with mesa master you need to update the kernel component as well, for which the steps described in my post above are not enough.

I have the exact same problem but I don’t believe @FuzzyLitchi 's problem come from lack of openGL 3.3 support. Indeed my glxinfo | grep -i opengl reads

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 515 (Skylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.3
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.2.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

The line that indicates the opengl version is OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.3, not OpenGL version string: 3.0 Mesa 17.2.3.

Moreover the following code runs fine:

extern crate sdl2;

use sdl2::video::GLProfile;

fn main() {
    let sdl_context = sdl2::init().unwrap();
    let video_subsystem = sdl_context.video().unwrap();

    let gl_attr = video_subsystem.gl_attr();
    gl_attr.set_context_profile(GLProfile::Core);
    gl_attr.set_context_version(3, 3);

    let window = video_subsystem.window("Window", 800, 600)
        .opengl()
        .build()
        .unwrap();

    let _ctx = window.gl_create_context().unwrap();

    debug_assert_eq!(gl_attr.context_profile(), GLProfile::Core);
    debug_assert_eq!(gl_attr.context_version(), (3, 3));
}

with the 0.29.1 version of the sdl2 crate.

This is another common question that needs to be documented somewhere well; we need an FAQ or such.

If you aren’t feeling adventerous enough to use bleeding-edge mesa, I was able to get the patch to apply against mesa 17.2.2 (the one in Ubuntu 17.10). I don’t recall every step of the process, but it went something like this:

mkdir Build ; cd Build
apt-get source mesa
sudo apt-get build-dep mesa
cd mesa*
cp ~/srgba.patch debian/patches/
echo srgba.patch >>debian/patches/series
dpkg-buildpackage -us -uc
sudo dpkg -i ../*.deb

srgba.patch.txt

I had to remove one hunk out of the upstream’s patch since it didn’t make sense in 17.2.

After doing that and rebooting, I was able to get a sample app running. So far my laptop hasn’t caught fire or anything so it’s probably OK 😃

You are optimistic about whether people check the issue tracker before posting things! But, can’t hurt.

Another one solution for Arch/Manjaro user’s:

1. Edit /etc/pacman.conf file and enable mesa-git custom repository :

sudo vim /etc/pacman.conf
# ...
[mesa-git]
SigLevel = Optional
Server = https://pkgbuild.com/~lcarlier/$repo/$arch

1. Synchronize packages and install : sudo pacman -Syu mesa-git lib32-mesa-git
2. Reboot OS
3. Check the version:

glxinfo | grep "OpenGL version"   # or glxinfo | grep -i opengl
# ...
OpenGL version string: 3.0 Mesa 18.1.0-devel (git-e1b2e5667c)

This specific bug has little to do with the provided OpenGL version but rather with sRGB support. That’s it.

I solved this issue by upgrading mesa 17.2 to mesa 17.4 through oibaf’s PPA. This may not be as good as downgrading to mesa 17.1 because I’m running bleeding-edge code hot off the mesa git repo:

add-apt-repository ppa:oibaf/graphics-drivers
apt update
apt upgrade

See https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

This bug is fixed for me (and for everyone I hope) in Mesa master. So this issue should be closed.

A lot of the innards have been reworked in commit 83561845a53667fae2611bf14b799654b0235a76 and the few previous ones. It might still take some rearranging, and it will definitely involve an API break. GraphicsContext needs to be generic on the color type, since it has to store the surface format information somewhere and it has to be known at compile time for many of gfx-rs’s functions, and the ability to go from compile-time to run-time and back is still rather awkward.

What we probably have to do is either make Context generic on the color format, which seems somewhat silly and means you are going to have to do extra work to choose which color format to use at runtime, or to make GraphicsContext a trait object, which is somewhat more work but makes it easier to choose at runtime.

This seems to have been fixed with the latest mesa 18.*. See https://github.com/PistonDevelopers/piston/issues/1202 for more information.

@bestouff

This kind of isn’t a trivial patch because to my knowledge the RenderFormat should be Srgba8 and changing it will screw with the color balance of basically every image ever … The right solution may be to make SRGB a config flag that can be toggled: https://love2d.org/wiki/love.graphics.isGammaCorrect . However all of gfx-rs’s types (framebuffer, texture, shader, etc) are generic on the RenderFormat, so being able to specify it at runtime while making it still convenient to use is a little non-trivial.

Long story short, it’s not currently designed to be modified, hardcoding a different value would be Incorrect, and I’m not yet sure how to redesign it to be easily modified.

You’re right though, this is a setting that should be able to be toggled. #299 has been created.

I also ran into this issue. It would be great to have a way in conf to specify that an advanced graphics mode isn’t needed; my current project just needs to draw pixels, rectangles, and text on the screen, and it would be great to be able to signal that to GGEZ so I can fall back to basics in terms of OpenGL.

In any case, many thanks for all the help on this project.

@ibrokemypie Yeah, looks like it. So that confirms that Mesa 17.3 has this issue as well… 😦