|Summary:||latest mesa git probably after commit c591b1e59454db2e8854e36852e0d413ce38b2f2 causes strange transparency in supertuxkart|
|Product:||Mesa||Reporter:||david becerra <davidbecerraporres>|
|Component:||Drivers/DRI/i965||Assignee:||Tapani Pälli <lemody>|
|Status:||RESOLVED FIXED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Priority:||medium||CC:||deveee, germano.massullo, leonard|
|i915 platform:||i915 features:|
it also happens in the configuration
on windowed mode and on top of firefox
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 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 20 Deve 2017-11-10 22:22:14 UTC
Ok, it should work now: https://github.com/supertuxkart/stk-code/commit/252403c9cc92f83403246b8ad6336b6e06d0445a
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 <firstname.lastname@example.org> 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 <email@example.com> Signed-off-by: Tapani Pälli <firstname.lastname@example.org> 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
Comment 27 WilliamRiley 2019-01-31 04:52:55 UTC
Took a look at all attachments related to this bug which is about latest mesa git perhaps after commit c591b1e59454db2e8854e36852e0d413ce38b2f2 that caused strange transparency in supertuxkart and also read all the comments that shares solution of bugs and tips what to do if such error happens. William, http://www.eliteassignment.co.uk/