Bug 102354 - Mesa 17.2 no longer can give SRGB-capable framebuffer on i965, even though Mesa 17.1.x does.
Summary: Mesa 17.2 no longer can give SRGB-capable framebuffer on i965, even though Me...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 17.2
Hardware: x86-64 (AMD64) Linux (All)
: highest blocker
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL: https://github.com/supertuxkart/stk-c...
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2017-08-22 01:54 UTC by QwertyChouskie
Modified: 2018-01-22 16:34 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
changes in glxinfo output (6.27 KB, text/plain)
2017-09-11 05:40 UTC, Tapani Pälli
Details
glxinfo log from patched mesa (25.54 KB, text/plain)
2017-09-11 20:33 UTC, Deve
Details
glx test application (12.36 KB, text/plain)
2017-09-15 04:51 UTC, Tapani Pälli
Details
hopeful fix (5.96 KB, patch)
2017-09-15 04:52 UTC, Tapani Pälli
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description QwertyChouskie 2017-08-22 01:54:27 UTC
Intel Ivy Bridge, Ubuntu 17.10, Mesa from repos.

Output:

qwerty@qwerty-Inspiron-3520:~/STK/stk-update/stk-code/build$ gdb bin/supertuxkart
GNU gdb (Ubuntu 8.0-0ubuntu3) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bin/supertuxkart...done.
(gdb) r
Starting program: /home/qwerty/STK/stk-update/stk-code/build/bin/supertuxkart 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[verbose  ] main: Error messages and other text output will be logged to /home/qwerty/.config/supertuxkart/0.8.2/stdout.log.
[info   ] [FileManager]: Data files will be fetched from: '../data/'
[info   ] [FileManager]: User directory is '/home/qwerty/.config/supertuxkart/0.8.2/'.
[info   ] [FileManager]: Addons files will be stored in '/home/qwerty/.local/share/supertuxkart/addons/'.
[info   ] [FileManager]: Screenshots will be stored in '/home/qwerty/.cache/supertuxkart/screenshots/'.
[info   ] [FileManager]: User-defined grand prix will be stored in '/home/qwerty/.local/share/supertuxkart/grandprix/'.
[info   ] [FileManager]: Asset 0 will be loaded from '../data/challenges/'.
[info   ] [FileManager]: Asset 1 will be loaded from '../data/gfx/'.
[info   ] [FileManager]: Asset 2 will be loaded from '../data/grandprix/'.
[info   ] [FileManager]: Asset 3 will be loaded from '../data/gui/'.
[info   ] [FileManager]: Asset 4 will be loaded from '../data/library/'.
[info   ] [FileManager]: Asset 5 will be loaded from '../data/models/'.
[info   ] [FileManager]: Asset 6 will be loaded from '../data/music/'.
[info   ] [FileManager]: Asset 7 will be loaded from '../data/replay/'.
[info   ] [FileManager]: Asset 8 will be loaded from '../data/tracks/'.
[info   ] [FileManager]: Asset 9 will be loaded from '../data/sfx/'.
[info   ] [FileManager]: Asset 10 will be loaded from '../data/shaders/'.
[info   ] [FileManager]: Asset 11 will be loaded from '../data/skins/'.
[info   ] [FileManager]: Asset 12 will be loaded from '../data/textures/'.
[info   ] [FileManager]: Asset 13 will be loaded from '../data/ttf/'.
[info   ] [FileManager]: Asset 14 will be loaded from '../data/po/'.
[verbose  ] translation: Env var LANGUAGE = 'en'.
[verbose  ] translation: Language 'English'.
[warn   ] tinygettext: jbo.po: warning: ignoring, unknown language
[warn   ] tinygettext: no.po: warning: ignoring, unknown language
[warn   ] tinygettext: no_NO.po: warning: ignoring, unknown language
[warn   ] tinygettext: sc.po: warning: ignoring, unknown language
[warn   ] tinygettext: sco.po: warning: ignoring, unknown language
Irrlicht Engine version 1.8.0
Linux 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:26:42 UTC 2017 x86_64
[warn   ] [IrrDriver Temp Logger]: Level 2: No doublebuffering available.

[warn   ] [IrrDriver Temp Logger]: Level 3: Fatal error, could not get visual.

[warn   ] [IrrDriver Temp Logger]: Level 2: No doublebuffering available.

[warn   ] [IrrDriver Temp Logger]: Level 3: Fatal error, could not get visual.

[warn   ] [IrrDriver Temp Logger]: Level 2: No doublebuffering available.

[warn   ] [IrrDriver Temp Logger]: Level 3: Fatal error, could not get visual.

[verbose  ] irr_driver: An invalid resolution was set in the config file, reverting to saner values

[info   ] IrrDriver: OpenGL version: 4.2
[info   ] IrrDriver: OpenGL vendor: Intel Open Source Technology Center
[info   ] IrrDriver: OpenGL renderer: Mesa DRI Intel(R) Ivybridge Mobile 
[info   ] IrrDriver: OpenGL version string: 4.2 (Core Profile) Mesa 17.2.0-rc4
[info   ] GLDriver: AMD Vertex Shader Layer Present
[info   ] GLDriver: ARB Buffer Storage Present
[info   ] GLDriver: ARB Base Instance Present
[info   ] GLDriver: ARB Draw Indirect Present
[info   ] GLDriver: ARB Compute Shader Present
[info   ] GLDriver: ARB Arrays of Arrays Present
[info   ] GLDriver: ARB Texture Storage Present
[info   ] GLDriver: ARB Texture View Present
[info   ] GLDriver: ARB Image Load Store Present
[info   ] GLDriver: ARB Shader Atomic Counters Present
[info   ] GLDriver: ARB Shader Storage Buffer Object Present
[info   ] GLDriver: ARB Multi Draw Indirect Present
[info   ] GLDriver: EXT Texture Compression S3TC Present
[info   ] GLDriver: ARB Texture Compression RGTC Present
[info   ] GLDriver: ARB Uniform Buffer Object Present
[info   ] GLDriver: ARB Explicit Attrib Location Present
[info   ] GLDriver: EXT Texture Filter Anisotropic Present
[info   ] GLDriver: Geometry Shaders Present
[info   ] GLDriver: ARB Texture Swizzle Present
[info   ] GLDriver: ARB Pixel Buffer Object Present
[warn   ] irr_driver: Created visual is not sRGB-capable. Re-creating device to workaround the issue.
[warn   ] [IrrDriver Temp Logger]: Level 2: No doublebuffering available.

[warn   ] [IrrDriver Temp Logger]: Level 3: Fatal error, could not get visual.

[fatal  ] irr_driver: Couldn't initialise irrlicht device. Quitting.

supertuxkart: /home/qwerty/STK/stk-update/stk-code/src/utils/log.hpp:93: static void Log::fatal(const char*, const char*, ...): Assertion `false' failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f68e71fb3aa in __GI_abort () at abort.c:89
#2  0x00007f68e71f1b77 in __assert_fail_base (fmt=<optimized out>, 
    assertion=assertion@entry=0x1011a9217 "false", 
    file=file@entry=0x1011a91e0 "/home/qwerty/STK/stk-update/stk-code/src/utils/log.hpp", line=line@entry=93, 
    function=function@entry=0x1011a9a00 <Log::fatal(char const*, char const*, ...)::__PRETTY_FUNCTION__> "static void Log::fatal(const char*, const char*, ...)") at assert.c:92
#3  0x00007f68e71f1c22 in __GI___assert_fail (assertion=0x1011a9217 "false", 
    file=0x1011a91e0 "/home/qwerty/STK/stk-update/stk-code/src/utils/log.hpp", 
    line=93, 
    function=0x1011a9a00 <Log::fatal(char const*, char const*, ...)::__PRETTY_FUNCTION__> "static void Log::fatal(const char*, const char*, ...)")
    at assert.c:101
#4  0x000000010086a3ac in Log::fatal (component=0x1011d44ec "irr_driver", 
    format=0x1011d4768 "Couldn't initialise irrlicht device. Quitting.\n")
    at /home/qwerty/STK/stk-update/stk-code/src/utils/log.hpp:93
#5  0x0000000100975809 in IrrDriver::initDevice (this=0x1019df030)
    at /home/qwerty/STK/stk-update/stk-code/src/graphics/irr_driver.cpp:595
#6  0x0000000100b9a552 in initRest ()
    at /home/qwerty/STK/stk-update/stk-code/src/main.cpp:1378
#7  0x0000000100b9b261 in main (argc=1, argv=0x7fffffffde28)
---Type <return> to continue, or q <return> to quit---
    at /home/qwerty/STK/stk-update/stk-code/src/main.cpp:1551
(gdb)
Comment 1 Deve 2017-08-22 17:12:10 UTC
Just note that it's a bug in STK, because we request srgb-capable framebuffer and don't handle the case when it fails. So you can just close it, or do whatever you want...
Comment 2 QwertyChouskie 2017-08-22 18:16:12 UTC
(In reply to Deve from comment #1)
> Just note that it's a bug in STK, because we request srgb-capable
> framebuffer and don't handle the case when it fails. So you can just close
> it, or do whatever you want...

Although the crash is an STK bug, the fact that Mesa 17.1.x can give a SRGB-capable framebuffer but Mesa 17.2 does not is a Mesa regression.

Will update title accordingly.
Comment 3 Kenneth Graunke 2017-08-22 19:47:48 UTC
Is it using GLX or EGL?  I diffed the output of glxinfo between these versions:

- Mesa 17.1.0 (git-15a38605fc3)
+ Mesa 17.2.0-rc3 (git-29df4deef2)

and there were no changes in visuals whatsoever.
Comment 4 QwertyChouskie 2017-08-22 20:03:43 UTC
(In reply to Kenneth Graunke from comment #3)
> Is it using GLX or EGL?  I diffed the output of glxinfo between these
> versions:
> 
> - Mesa 17.1.0 (git-15a38605fc3)
> + Mesa 17.2.0-rc3 (git-29df4deef2)
> 
> and there were no changes in visuals whatsoever.

You may want to see https://bugs.freedesktop.org/show_bug.cgi?id=92759#c7
Comment 5 Deve 2017-08-23 08:10:19 UTC
It uses GLX, but I can test EGL if you want (it's already done for Wayland, but disabled by default).

glxinfo doesn't report ANY config with srgb-capable framebuffer, even though B8G8R8A8 IS srgb-capable (we use GLX_ALPHA_SIZE=1 for intel since mesa 10.6 to force srgb-capable fb).

Most likely I will eventually get rid of all "glEnable(GL_FRAMEBUFFER_SRGB);" calls in STK because it causes too many issues and we need it for OpenGL ES renderer on Android anyway.

And the reason of this bug may be that old mesa was ignoring the GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, and now it recognizes it and thus fails because there is no config with srgb-capable framebuffer?

And btw. current git STK doesn't crash anymore.
Comment 6 Tapani Pälli 2017-09-04 13:13:02 UTC
Please check if following patch makes difference:
https://lists.freedesktop.org/archives/mesa-dev/2017-September/168453.html
Comment 7 Deve 2017-09-09 20:34:37 UTC
I just checked the patch and nothing changed for me (with GLX, I didn't test EGL). I patched mesa version 4d807d7fe272db97fb9e20800872d5970fa2696d.

If you run current git STK, there are two warnings in console:

[warn   ] irr_driver: Created visual is not sRGB-capable. Re-creating device to workaround the issue.
[warn   ] [IrrDriver Temp Logger]: Level 2: No sRGB framebuffer available.

The first one happens for intel when
glGetFramebufferAttachmentParameteriv(GL_DRAW_FRAMEBUFFER, GL_BACK_LEFT,
                              GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING, &param);

returns GL_LINEAR, so this is true for all mesa versions >= 10.6 (precisely since MESA_FORMAT_R8G8B8X8_UNORM has been added). In this case we make an ugly hack and re-create device with alpha channel, that forces to use MESA_FORMAT_R8G8B8A8_SRGB.

The second warning happens when request a config with GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB fails. So then we try to get a config without this flag.

And glxinfo still doesn't show any srgb configs for me. Are there some particular requirements, such as current libdrm, DRI2/DRI3 etc...?
Comment 8 Tapani Pälli 2017-09-11 05:40:01 UTC
(In reply to Deve from comment #7)
> I just checked the patch and nothing changed for me (with GLX, I didn't test
> EGL). I patched mesa version 4d807d7fe272db97fb9e20800872d5970fa2696d.
> 
> If you run current git STK, there are two warnings in console:
> 
> [warn   ] irr_driver: Created visual is not sRGB-capable. Re-creating device
> to workaround the issue.
> [warn   ] [IrrDriver Temp Logger]: Level 2: No sRGB framebuffer available.
> 
> The first one happens for intel when
> glGetFramebufferAttachmentParameteriv(GL_DRAW_FRAMEBUFFER, GL_BACK_LEFT,
>                               GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING,
> &param);
> 
> returns GL_LINEAR, so this is true for all mesa versions >= 10.6 (precisely
> since MESA_FORMAT_R8G8B8X8_UNORM has been added). In this case we make an
> ugly hack and re-create device with alpha channel, that forces to use
> MESA_FORMAT_R8G8B8A8_SRGB.
> 
> The second warning happens when request a config with
> GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB fails. So then we try to get a config
> without this flag.
> 
> And glxinfo still doesn't show any srgb configs for me. Are there some
> particular requirements, such as current libdrm, DRI2/DRI3 etc...?

No additional requirements, I get additional visuals/fbconfigs to glxinfo on my HSW, I'll attach the diff from output.
Comment 9 Tapani Pälli 2017-09-11 05:40:47 UTC
Created attachment 134151 [details]
changes in glxinfo output

additional visuals/fbconfigs in glxinfo with the patch mentioned
Comment 10 Tapani Pälli 2017-09-11 08:20:27 UTC
My GLX skills are poor, but I've attempted to build a small test app.

In the list returned by glXGetFBConfigs I do see configs that have GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT set. However, when calling glXChooseVisual with 'GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT' I get no visual at all. So something is missing? I think glXCreateContext should be called with XVisualInfo capable to sRGB in order for this to work. Is this the same error that is seen with STK?
Comment 11 Tapani Pälli 2017-09-11 11:28:28 UTC
(In reply to Tapani Pälli from comment #10)
> My GLX skills are poor, but I've attempted to build a small test app.
> 
> In the list returned by glXGetFBConfigs I do see configs that have
> GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT set. However, when calling glXChooseVisual
> with 'GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT' I get no visual at all. So something
> is missing? I think glXCreateContext should be called with XVisualInfo
> capable to sRGB in order for this to work. Is this the same error that is
> seen with STK?

ok it seems I was not using API properly, I do get sRGB visual fine with following attribs defined:

--- 8< ---
            int srgb_attr[] = {
               GLX_RENDER_TYPE, GLX_RGBA_BIT,
               GLX_RGBA,
/* these are not really necessary */
#if 0          
               GLX_RED_SIZE,   4,
               GLX_GREEN_SIZE, 4,
               GLX_BLUE_SIZE,  4,
               GLX_DEPTH_SIZE, 4,
               GLX_DOUBLEBUFFER, True,
               GLX_STENCIL_SIZE, 1,
#endif
               GLX_ALPHA_SIZE, 0,
               GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT,
               None
            };
--- 8< ---

and later get 0x8c40 as GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
Comment 12 Tapani Pälli 2017-09-11 11:47:49 UTC
I also noticed that STK sets a value of 0/1 to attribute GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, IMO this is wrong as this attribute is a boolean attribute, not int or enum. Booleans have default value of false and are turned true by including attrib on the list (there should be no value after attrib). Please correct me if this is wrong interpretation of the spec.
Comment 13 Deve 2017-09-11 20:32:16 UTC
I tried to make a clean build with current git mesa and your patch to make sure that I did everything properly, but unfortunately with no luck. You can see glxinfo log in attachment.

STK uses glXChooseFBConfig by default and from what I see in the specs after a quick look: "All attributes in attrib_list, including boolean attributes, are immediately followed by the corresponding desired value."

It has a fallback with glXChooseVisual for glx <= 1.2, but tbh. I don't think that it's used somewhere...
Comment 14 Deve 2017-09-11 20:33:12 UTC
Created attachment 134169 [details]
glxinfo log from patched mesa
Comment 15 Tapani Pälli 2017-09-12 05:24:53 UTC
(In reply to Deve from comment #13)
> I tried to make a clean build with current git mesa and your patch to make
> sure that I did everything properly, but unfortunately with no luck. You can
> see glxinfo log in attachment.
> 
> STK uses glXChooseFBConfig by default and from what I see in the specs after
> a quick look: "All attributes in attrib_list, including boolean attributes,
> are immediately followed by the corresponding desired value."
> 
> It has a fallback with glXChooseVisual for glx <= 1.2, but tbh. I don't
> think that it's used somewhere...

ok, I'll do some testing on other machines to see if there is some dependency after all, I don't really understand why your glxinfo does not have any srgb configs listed :/
Comment 16 Deve 2017-09-12 19:17:46 UTC
One thing that I noticed is that when you added new formats in intel_screen.c, now it should be probably:

   if (intel_loader_get_cap(dri_screen, DRI_LOADER_CAP_RGBA_ORDERING))
      num_formats = ARRAY_SIZE(formats);
   else
      num_formats = 5;

rather than num_formats = 3. At least for me intel_loader_get_cap(dri_screen, DRI_LOADER_CAP_RGBA_ORDERING) returns false.

In this case I see quite a lot configs with modes->sRGBCapable = true in driCreateConfigs in utils.c, but still no srgb-capable format in glxinfo :(
Comment 17 Tapani Pälli 2017-09-14 08:48:27 UTC
(In reply to Deve from comment #16)
> One thing that I noticed is that when you added new formats in
> intel_screen.c, now it should be probably:
> 
>    if (intel_loader_get_cap(dri_screen, DRI_LOADER_CAP_RGBA_ORDERING))
>       num_formats = ARRAY_SIZE(formats);
>    else
>       num_formats = 5;
> 
> rather than num_formats = 3. At least for me
> intel_loader_get_cap(dri_screen, DRI_LOADER_CAP_RGBA_ORDERING) returns false.
> 
> In this case I see quite a lot configs with modes->sRGBCapable = true in
> driCreateConfigs in utils.c, but still no srgb-capable format in glxinfo :(

Yep, that is a clear bug in the patch. With the change I get even more configs/visuals that have srgb set to 's'. Will debug some more.
Comment 18 Tapani Pälli 2017-09-15 04:51:07 UTC
Created attachment 134247 [details]
glx test application

Here's a test application. Deve, could you try running this and see what comes up? For me output is (tested on HSW and KBL machines):

--- 8< ---
created window with visual id 36
using visual 0x1ee (srgb 1) (rgba 8880)
GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_BLUE_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING 0x8c40
--- 8< ---

Program has 3 different ways of setting up GLX (see init_glx() function), for 2 of those I'm getting sRGB visual with my patch. Remember to set LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH when running against custom Mesa tree.
Comment 19 Tapani Pälli 2017-09-15 04:52:04 UTC
Created attachment 134248 [details] [review]
hopeful fix

v2 of the patch
Comment 20 Tapani Pälli 2017-09-15 06:32:05 UTC
I think I also understood why this works for you and not for me. It works nicely if you run on Fedora (x-wayland) but on Ubuntu you will need to replace the DRI driver used by X server. When this is done, sRGB visuals are exposed correctly.
Comment 21 Tapani Pälli 2017-09-15 09:58:59 UTC
(In reply to Tapani Pälli from comment #20)
> I think I also understood why this works for you and not for me. It works

*sigh* .. meant to say "why this works for me and not for you" :)
Comment 22 Deve 2017-09-15 21:53:50 UTC
I understood :)

Regarding to LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH, this is what I'm doing.

I didn't install everything to avoid a mess in the system, but I tried to set LD_LIBRARY_PATH to directory that contains patched libgl/i965_dri and current git libdrm and started second X server, but it doesn't make any difference.

In your test app, the first method prints:
created window with visual id 33
found a matching visual id (33)
using visual 0x21 (srgb 0) (rgba 8888)
GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_BLUE_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE 0x8
GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING 0x8c40

And next two methods:
created window with visual id 33
error initializing glx

But... I started gnome wayland session on second tty and it works there! Both your example and glxinfo.

As I said before driCreateConfigs in utils.c creates srgb-capable configs, so something must filter and remove/ignore it later. Maybe some unsupported formats or extensions, no idea tbh...
Comment 23 Deve 2017-09-15 22:05:58 UTC
Ok, I replaced the system i965_dri.so and it works now in X session too! I'm not sure why xserver ignored this library in path from LD_LIBRARY_PATH. But now I can at least confirm that it works fine for me :)
Comment 24 Mark Janes 2017-09-15 22:19:57 UTC
On my system Xorg is a wrapper script that starts the xserver as root, and does not pass LD_LIBRARY_PATH through.
Comment 25 Tapani Pälli 2017-09-18 05:50:28 UTC
(In reply to Deve from comment #23)
> Ok, I replaced the system i965_dri.so and it works now in X session too! I'm
> not sure why xserver ignored this library in path from LD_LIBRARY_PATH. But
> now I can at least confirm that it works fine for me :)

Good to know, now I think we still need some KDE/Plasma testing. I'll send my patch to list later and CC KDE people.
Comment 26 Deve 2017-09-18 07:00:20 UTC
I just tested and EGL_GL_COLORSPACE_SRGB works too. You can check it in current git STK with "cmake .. -DENABLE_WAYLAND_DEVICE=1".

Btw. is there a way to let xserver know that is should use self-compiled dri rather than the one in /usr/lib?
Comment 27 Tapani Pälli 2017-09-19 04:58:17 UTC
(In reply to Deve from comment #26)
> I just tested and EGL_GL_COLORSPACE_SRGB works too. You can check it in
> current git STK with "cmake .. -DENABLE_WAYLAND_DEVICE=1".
> 
> Btw. is there a way to let xserver know that is should use self-compiled dri
> rather than the one in /usr/lib?

I'm not aware of any, I was told that LIBGL_DRIVERS_PATH (and other env) is ignored for security reasons because xserver used to run as root.
Comment 28 Tapani Pälli 2017-11-09 07:06:50 UTC
Following commit is now available in Mesa master. It exposes BGRA8888 sRGB visuals and should fix your problem. Please let me know if this is not the case and I can try to help further. I will try to promote this patch to Mesa stable releases if we find no issues.

--- 8< ----
commit c591b1e59454db2e8854e36852e0d413ce38b2f2
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Tue Oct 31 10:56:28 2017 +0200

    i965: expose SRGB visuals and turn on EGL_KHR_gl_colorspace
    
    Patch exposes sRGB visuals and adds DRI integer query support for
    __DRI2_RENDERER_HAS_FRAMEBUFFER_SRGB. Further changes make sure that
    we mark if the app explicitly wanted sRGB and for these framebuffers
    we don't turn sRGB off in intel_gles3_srgb_workaround. This way we
    keep compatibility for existing applications relying on default sRGB
    and ony add more visual support.
    
    With this change, following dEQP tests start to pass:
    
       dEQP-EGL.functional.wide_color.window_8888_colorspace_srgb
       dEQP-EGL.functional.wide_color.pbuffer_8888_colorspace_srgb
    
    v2: some code cleanup (Emil Velikov)
        update num_formats correctly (reported by deveee@gmail.com)
    
    v3: cleanup, remove redundant is_srgb
        rename explicit_srgb as 'need_srgb' to follow style better
    
    Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v2)
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102264
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102354
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102503


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.