Bug 103646 - latest mesa git probably after commit c591b1e59454db2e8854e36852e0d413ce38b2f2 causes strange transparency in supertuxkart
Summary: latest mesa git probably after commit c591b1e59454db2e8854e36852e0d413ce38b2f...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Tapani Pälli
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-09 13:15 UTC by david becerra
Modified: 2018-01-25 08:23 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
screenshot (734.71 KB, image/png)
2017-11-09 13:15 UTC, david becerra
Details
it also happens in the configuration (568.15 KB, image/png)
2017-11-09 14:19 UTC, david becerra
Details
stdout.log (9.47 KB, text/x-log)
2017-11-09 20:17 UTC, david becerra
Details
glxinfo (32.15 KB, text/plain)
2017-11-09 20:18 UTC, david becerra
Details
on windowed mode and on top of firefox (545.14 KB, image/png)
2017-11-09 21:58 UTC, david becerra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description david becerra 2017-11-09 13:15:09 UTC
Created attachment 135348 [details]
screenshot

before this commit there were problems with supertuxkart but i did build mesa with the v2 of the patch and everything was fine. after the patch landed i decided to rebuild mesa without the patch and this happened:
Comment 1 david becerra 2017-11-09 14:19:12 UTC
Created attachment 135352 [details]
it also happens in the configuration
Comment 2 Tapani Pälli 2017-11-09 16:37:36 UTC
It is not clear from the bug description if these screenshots are taken with or without mentioned commit. Are these taken with latest Mesa master?
Comment 3 Tapani Pälli 2017-11-09 16:43:17 UTC
Also, did you install the built Mesa in your system (replace existing i965_dri.so) or did you run test with LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH?
Comment 4 david becerra 2017-11-09 16:51:58 UTC
it is from latest git so that commit is included,
i build mesa with a pkgbuild on archlinux so it's a fresh install
Comment 5 david becerra 2017-11-09 16:54:53 UTC
i suspect the v3 of the patch(what has landed) has the issue as the v2 that i applied worked fine.
 it could also be another commit but it seems unlikely
Comment 6 Tapani Pälli 2017-11-09 17:13:33 UTC
ok thanks I will try to reproduce and figure out what could be going wrong here
Comment 7 david becerra 2017-11-09 17:26:13 UTC
btw im using stk 0.9.3rc1 from archlinux
Comment 8 Deve 2017-11-09 17:54:28 UTC
Could you post the stdout.log file from ~/.config/supertuxkart/0.8.2? The glxinfo output may be usefull too.

It looks that in your case STK still uses the ugly hack with alpha_channel=true to force srgb-capable framebuffer. And the compositor for some reason doesn't make the window opaque. Actually it never happened for me on xserver... For wayland there is wl_surface_set_opaque_region. I will try to reproduce it with current git mesa.
Comment 9 Deve 2017-11-09 19:52:40 UTC
Cannot reproduce on Gnome :( I tried both xserver and xwayland.
Comment 10 david becerra 2017-11-09 20:17:27 UTC
Created attachment 135357 [details]
stdout.log
Comment 11 david becerra 2017-11-09 20:18:32 UTC
Created attachment 135358 [details]
glxinfo
Comment 12 Deve 2017-11-09 20:35:18 UTC
So the srgb patch seems to work fine. STK doesn't complain about framebuffer that is not srgb-capable, it doesn't use the alpha_channel=true hack, and also glxinfo shows some configs with srgb framebuffers.

I suppose that something in your compositor/window manager was changed. And actually I would like to find a way to reproduce it, so that I can fix it in STK.

Maybe we need a wl_surface_set_opaque_region equivalent for x11 to be 100% correct...
Comment 13 david becerra 2017-11-09 21:46:15 UTC
(In reply to Deve from comment #12)
> So the srgb patch seems to work fine. STK doesn't complain about framebuffer
> that is not srgb-capable, it doesn't use the alpha_channel=true hack, and
> also glxinfo shows some configs with srgb framebuffers.
> 
> I suppose that something in your compositor/window manager was changed. And
> actually I would like to find a way to reproduce it, so that I can fix it in
> STK.
> 
> Maybe we need a wl_surface_set_opaque_region equivalent for x11 to be 100%
> correct...

im using gnome shell 3.26 on xorg
Comment 14 david becerra 2017-11-09 21:58:07 UTC
it also happens on windowed mode
Comment 15 david becerra 2017-11-09 21:58:46 UTC
Created attachment 135361 [details]
on windowed mode and on top of firefox
Comment 16 Tapani Pälli 2017-11-10 07:19:49 UTC
I could not reproduce this on FC26 with gnome-shell 3.24.3 and supertuxkart 0.9.2.
Comment 17 Deve 2017-11-10 12:32:33 UTC
If you have enough skills, you can try to set _NET_WM_OPAQUE_REGION to whole window size using xprop.
Comment 18 Deve 2017-11-10 18:28:44 UTC
I made some experiments with rgba windows and setting opaque region with netwm works fine under Gnome. You can check if it works for you when game is started:

xprop -name SuperTuxKart -f _NET_WM_OPAQUE_REGION 32c -set _NET_WM_OPAQUE_REGION 0,0,$width,$height

Replace $width and $height with proper values.

And if it works for you, then I will just set this property during window creation in STK.
Comment 19 david becerra 2017-11-10 20:28:12 UTC
(In reply to Deve from comment #18)
> I made some experiments with rgba windows and setting opaque region with
> netwm works fine under Gnome. You can check if it works for you when game is
> started:
> 
> xprop -name SuperTuxKart -f _NET_WM_OPAQUE_REGION 32c -set
> _NET_WM_OPAQUE_REGION 0,0,$width,$height
> 
> Replace $width and $height with proper values.
> 
> And if it works for you, then I will just set this property during window
> creation in STK.

it works !
but if i apply new resolution it starts to have transparency again
Comment 21 david becerra 2017-11-10 23:43:26 UTC
(In reply to Deve from comment #20)
> Ok, it should work now:
> https://github.com/supertuxkart/stk-code/commit/
> 252403c9cc92f83403246b8ad6336b6e06d0445a

good to know
is it gonna be pushed for 0.9.3rc2 or final?
Comment 22 david becerra 2017-11-10 23:44:32 UTC
also i would like to see the mesa part fixed soon :)
Comment 23 Tapani Pälli 2017-11-13 09:30:31 UTC
(In reply to david becerra from comment #22)
> also i would like to see the mesa part fixed soon :)

It seems very unlikely that there is any bug in Mesa considering this issue. Bisected Mesa change exposes additional visuals for applications to use and does not change existing visuals behaviour. I will leave this bug open for now in case there will be more similar/same bug reports but it will be soon resolved as NOTOURBUG if no such reports arrive and we are not able to reproduce the failure.
Comment 24 Deve 2017-11-13 10:17:20 UTC
The main reason is that probably alpha blending is somewhere messed in STK. It shouldn't produce semi-transparent image...

It was happening for me on wayland when I was creating EGL context with alpha channel. And that's why I added wl_surface_set_opaque_region.

So there may be two reasons:
- Current Gnome+xserver now behaves the same as Gnome+wayland
- Mesa now uses alpha channel even if we didn't request it

But again, I can't reproduce it with Intel HD 4000 and Gnome 3.24.
Comment 25 david becerra 2017-11-20 10:50:19 UTC
this is fixed on stk 0.9.3
and no other game shows this behaviour
Comment 26 Tapani Pälli 2018-01-16 06:05:05 UTC
I haven't been able to reproduce this after following commit landed to Xorg and I haven't received any new bugs on this subject. Resolving as fixed, please reopen if this still occurs.

--- 8< ---
commit c2954b16c8730c7ed8441fd8dba25900f3aed265
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Tue Nov 28 09:23:29 2017 +0200

    glx: do not pick sRGB config for 32-bit RGBA visual
    
    This fixes blending issues seen with kwin and gnome-shell when
    32bit visual has sRGB capability set.
    
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103699
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103646
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103655


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.