Hi;
On 11.01.2018 20:20, Mario Kleiner wrote:
On 01/11/2018 09:14 AM, Tapani Pälli wrote:
Yes, but as it broke regular visuals (on some of our testing machines
as well) we needed a fast fix for this.
While this is an issue, I think the visual corruption has higher
priority than this. This can be fixed meanwhile or afterwards when
things work OK. Now it can be toggled true in intel_screen.c when
debugging/investigating the issue.
That regression in Bug 104536, could you only reproduce it on "Ubuntu
16.04 or 17.04 respectively, with latest git versions of libdrm, mesa,
xserver, xlibs, and the drm-tip kernel." as David Weinehall reported in
private message?
So far this has been only seen in CI machines. (I've been busy with
something else ATM but I will also try to get to this one soon.)
Does it require X-Server from git master?
Yes, this is how those machines do, it's the latest components of the
graphics stack.
Because testing here on Intel Ivybridge and Skylake with KUbuntu 16.04.3
LTS and the distribution-provided X-Server 1.19.3 and the Unity-7 +
Compiz standard Ubuntu 16.04 GUI, i can't reproduce the visual
corruption from that screenshot in bug 104536?, neither with the
intel-ddx nor the modesetting-ddx used by default, neither depth 24 nor
depth 30.
What I've understood (from some bugs related to problems with sRGB
visuals) is that with X server master there are a lot more visuals in
general and as example can be multiple 32bit visuals (which did not
happen before). This could possibly explain why these issues cannot be
reproduced on LTS provided Xorg.
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
