Game windows (minecraft, titan attacks, maybe others) on Intel are transparent and no longer playable

[Alan Pope 🍺🐧🐱 🦄]

Fully up to date Trusty.
Open Minecraft, notice that the window is transparent - you can see through to the desktop wallpaper, making the game unplayable.
Also tested with Titan Attacks which is also a lwjgl based game - dunno if that's coincidence

This worked a few days ago. Probably before the most recent xorg update.

See screenshots.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xserver-xorg-video-intel 2:2.99.909-0ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-7.25-generic 3.13.1
Uname: Linux 3.13.0-7-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.13.2-0ubuntu2
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,grid,imgpng,gnomecompat,scale,workarounds,mousepoll,regex,wall,move,place,vpswitch,resize,unitymtgrabhandles,snap,session,expo,ezoom,unityshell]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Sat Feb 8 10:54:09 2014
DistUpgraded: 2014-01-20 08:54:25,315 DEBUG enabling apt cron job
DistroCodename: trusty
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21da]
InstallationDate: Installed on 2012-06-29 (588 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MachineType: LENOVO 4287CTO
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-7-generic root=UUID=6088859e-4fc3-4ec8-903f-5b52cdc1d0eb ro quiet splash vt.handoff=7
SourcePackage: xserver-xorg-video-intel
UpgradeStatus: Upgraded to trusty on 2014-01-20 (19 days ago)
dmi.bios.date: 12/05/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET67WW (1.37 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4287CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8DET67WW(1.37):bd12/05/2012:svnLENOVO:pn4287CTO:pvrThinkPadX220:rvnLENOVO:rn4287CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4287CTO
dmi.product.version: ThinkPad X220
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu4
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.0.1-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.0.1-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.15.0-1ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.909-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2
xserver.bootTime: Sat Feb 8 10:50:45 2014
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 728
 vendor LGD
xserver.version: 2:1.15.0-1ubuntu3

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Updated and rebooted and all seems okay now.

[Chris Wilson (ickle)]

Any ideas what changed? I guess a library update didn't take effect until the reboot, or another enviromnental issue (perhaps something like an update causing a drop back to indirect GLX).

[Alan Pope 🍺🐧🐱 🦄 (popey)]

That's possible.

Rebooted on Friday in US, flew home, slept.

alan@deep-thought:~$ last | grep reboot
reboot system boot 3.13.0-8-generic Mon Feb 10 00:58 - 10:26 (09:28)
reboot system boot 3.13.0-7-generic Fri Feb 7 13:45 - 10:26 (2+20:41)

Looks like I did some updates on Friday/Saturday. Nothing interesting looking though.

http://paste.ubuntu.com/6908331/

Filed bug on Saturday afternoon after trying minecraft.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Well this is odd. It's happened again today.

I played Minecraft at ~18:45 and now it's ~22:30 and it's broken. No reboot inbetween, however I logged out and back in inbetween at ~19:15.

I did some updates earlier (lunch time).. http://paste.ubuntu.com/6922587/ which includes some xorg packages. Related?

[Ryan Finnie (fo0bar)]

Confirmed on a up to date and rebooted trusty laptop as of 2014-02-23, Thinkpad X220 with Intel graphics.

[Chris Wilson (ickle)]

I wonder if Alan's issue is related to the interesting effect of running at 1360 vs 1366 we see on his machine (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1283568). Ryan can you also please attach your Xorg.0.log when this occurs to you? Is it immediate? Does it show up in screenshots? etc

[Alan Pope 🍺🐧🐱 🦄 (popey)]

It happens when I use an external 1080p display and the internal panel is off too..

[Ryan Finnie (fo0bar)]

Chris, I can reproduce it consistently. The effect is immediate, and shows up in screenshots. I haven't tried an external display, but according to Xorg.0.log, my Thinkpad is running at native 1366x768.

Minecraft is the only application I've seen it on in trusty so far, but admittedly I don't really play games on my laptop.

[truant (launchpad-ninj4)]

Confirmed on Toshiba Satellite L830, Intel GFX @1366x768 native resolution.

Was OK yesterday, updated this afternoon, rebooted, now transparent Minecraft.

Happens in Kerbal Space Program too.

[truant (launchpad-ninj4)]

Oh, just to be clear, I'm using Ubuntu Gnome.

So that might rule some things out.

KSP screenshot attached, showing groovy pink desktop image under fullscreen KSP window. Minecraft behaves the same way.

[Chris Wilson (ickle)]

It is hard to tell - the regions in question look like OpenGL content, but if this only started very recently, you should test with

xf86-video-intel commit 27ac9f574f65cbd535751c925e9b2e2d7c8a6b3a
Author: Chris Wilson <email address hidden>
Date: Thu Feb 27 08:33:52 2014 +0000

    sna: Avoid promoting region-to-whole migration and discarding damage

    Fixes regression from
    commit 1de1104064b5898cbed37e836901694a381c1266
    Author: Chris Wilson <email address hidden>
    Date: Fri Feb 21 22:43:04 2014 +0000

        sna: Use a hint to do whole image uploads inplace

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75549
    Signed-off-by: Chris Wilson <email address hidden>

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Sorry I haven't tried the various options yet Chris. I generally don't have an xorg.conf (2014 yay!) :)

Is there some skeleton xorg.conf I can use which won't introduce any additional issues which might cloud my testing?

[Chris Wilson (ickle)]

You can just write snippets, such as:

Section "Device"
  Identifier "Device0"
  Option "SwapbuffersWait" "false"
EndSection

[Aaron Taddei (pringjocky)]

FWIW, I am running xubuntu 14.04 and it does the same thing. I can get it to work when i turn off compositing.

[Alberto Salvia Novella (es20490446e)]

It's estimated to have a moderate impact on a large portion of Ubuntu users.

[Devin (thatguyweallknow)]

Can comfirm this issue and that the image from post #12 is identical to the issue I see in minecraft as well.

Intel® Core™ i5-2430M CPU
Ubuntu 14.04 fully updated as of this morning
I have seen this issue for ~1 week.
Unity7 DE
No ppa's that affect video card drivers, or kernels. A pretty stock installation.

[Jana Saout (jana-h)]

I'm not a Ubuntu user myself, but seeing the exact same issue on my Gentoo (unstable) system. I've seen it before the last couple of months, but only occasionally, typically after a long-running X session and it usually went away with an X server restart. For a bit over a week now the problem has been permanent however.

X.Org 1.15.0, xf86-video-intel 2.99.910, Mesa 10.1.0 (also seen with 9.2.5), Linux 3.13.3, Gnome 3 Shell

OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
[ 27305.329] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000

Notice that there is a 256x256 area in the lower left corner of the window in which the window is not translucent. This corner always stays there independent of window resizes or going fullscreen. For the rest of the window it looks like its content are being "added" to the background.

I've seen this bug posted in various places, like reported as a Minecraft bug or as LWJGL bug (the Java-GL glue library). It's certainly not a Minecraft bug, as it apparently appears with LWJGL demo applications as well. All the bug reports seem to have Intel onboard graphics in common.

Note that there are also reports for a similar bug on Windows, but I doubt it's related.

[Jana Saout (jana-h)]

PS: I tried the latest git version of xf86-video-intel (that includes that fix "Avoid promoting region-to-whole migration and discarding damage" by Chris) - same issue.

[Jana Saout (jana-h)]

I did some bit of uneducated debugging.

It seems there is something going on with the GL/GLX and alpha bits.

The LWJGL code is creating a GLX window for its content.

I noticed that the screen displaying the logo on startup was entirely translucent, without the 256x256 block in the lower left corner that is not translucent later on.

Changing a "glClearColor(0, 0, 0, 0);" to "glClearColor(0, 0, 0, 1);" makes the logo screen not translucent (and any value between 0 and 1 for the alpha value makes it somewhere in-between). - i.e. using glClearColor(0, 0, 0, 1); makes at least the logo screen look the way it should be!

Now, it seems Minecraft is only using that code path for the logo and not for the rest of the game. Now I am wondering if "0" for the alpha means translucend and "1" means solid or if it's supposed to be the other way around.

Also, I am wondering if the game is expecting that the alpha value on the window has any meaning at all or if there is some hidden flag somewhere that tells the compositing manager what to do with that alpha bit and something is wrong in there. (?)

Maybe Minecraft/LWJGL is selecting a visual where it expects the alpha bit to be ignored and chooses the wrong one - but this is a random guess as I really don't know much about GLX and the setup procedure of windows/visuals and how the alpha information is passed down to the compositor.

Maybe someone with more knowledge could point me into the right direction...

[Jana Saout (jana-h)]

Note that you can find the GL setup code here:

https://github.com/LWJGL/lwjgl/blob/master/src/native/linux/opengl/org_lwjgl_opengl_Display.c

somewhere around Java_org_lwjgl_opengl_LinuxDisplay_nCreateWindow

[Jana Saout (jana-h)]

I have a possible culprit.

The composite extension requires premultiplied alpha data when compositing images with alpha. So (0, 0, 0, 0) means fully transparent and (0, 0, 0, 1) means solid black. This is consistent with what I am seeing with the login window.

I found some example code with walks through the proposed matching GLX FB configs and uses the Render exentsion to check for the alpha mask of that framebuffer. This is used by code that explicitly wants an alpha channel for compositing.

Something along the lines of

        for (i = 0; i < numfbconfigs; i++) {
                visinfo = glXGetVisualFromFBConfig(dpy, fbconfigs[i]);
                if (!visinfo) continue;
                pictFormat = XRenderFindVisualFormat(dpy, visinfo->visual);
                if (!pictFormat) continue;
                printf("%d %d %d\n", numfbconfigs, i, pictFormat->direct.alphaMask);
        }

When playing around with attributes and looking for matching FB visuals, there are usually one or more matches and only the last one listed has an alphaMask of 255, all others are 0.

Now it appears that on my system the only FB config available matching Minecraft's requested attributes is the one with alphaMask of 255, i.e. its alpha value *is* passed to the compositor.

Now my guess is that Minecraft simply isn't expecting that, so the alpha bit contains a random value (typically 0) which is then accidentally used by the compositor.

So, to support my theory one would need to check if the issue is simply Minecraft/LWJGL now selecting an RGBA visual with the alpha channel interpreted by the compositor whereas before that was not the case.

I'll try to hack Minecraft to set the alpha value to 1 in the meantime to see if it helps. I am just wondering whether this is standard or nonstandard and Minecraft/LWJGL is supposed to handle this correclty or not.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

This bug isn't limited to Minecraft or LWJGL. Minetest (not Java) and many other games also exhibit the same behaviour.

[Jana Saout (jana-h)]

Ok, so this proves my point. The unwanted "change" somewhere in the X/GL stack is that the visual with the composite alpha channels is now "accidentally" chosen by default whereas the applications expect the alpha channel to be ignored.

I just decompiled Minecraft and hacked the calls to glClearColor to set the alpha value to "1.0" and this "corrects" the output (at least for Minecraft...).

gcc -o test test.c -lX11 -lXrender -lGL && ./test

Prints:

visual 0: alphaMask = 255
visual 1: alphaMask = 0
visual 2: alphaMask = 0
visual 3: alphaMask = 0
visual 4: alphaMask = 0
visual 5: alphaMask = 0
visual 6: alphaMask = 0
visual 7: alphaMask = 0

Which means that the first visual proposed contains the alpha mask causing unwanted alpha compositing.

[Jana Saout (jana-h)]

Googling around I found those recent two patches:

http://patchwork.freedesktop.org/patch/20458/
http://patchwork.freedesktop.org/patch/20464/

[Mesa-dev] glx: Fix the default values for GLXFBConfig attributes
[Mesa-dev] glx: Fix the GLXFBConfig attrib sort priorities

Mightbe related...

[Sascha Biermanns (skbierm)]

I have the same bug running two machines with trusty ... a ASUS F55A-091D and Lenovo Edge e420s.

[Maarten Lankhorst (mlankhorst)]

This should have been fixed by the commits jana-h mentioned, is this still an issue?

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Are those in trusty? Because on my up to date and clean booted trusty laptop I still see the issue.

[Ryan Finnie (fo0bar)]

Minecraft is now working for me, on a machine last upgraded Saturday.

ii xserver-xorg 1:7.7+1ubuntu8 amd64 X.Org X server
ii xserver-xorg-video-intel 2:2.99.910-0ubuntu1 amd64 X.Org X server -- Intel i8xx, i9xx display driver

[Justin Welenofsky (welenofsky)]

I am currently not running Ubuntu but I am experiencing this issue exact issue in ArchLinux. Intel GFX card and also running Gnome with latest updates.

[Arthur McLaren (uniquesnowflake)]

Same Issue here, 14.04 amd64 with updated everything. I'm running a Lenovo Thinkpad T420s, Intel i5-2520m processor, screen resolution 1600x900, HD3000 graphics, kernel 3.13.0-23-generic.

[Ryan Finnie (fo0bar)]

Never mind on Comment #32, it's still a problem for me.

[Maarten Lankhorst (mlankhorst)]

I can reproduce this with minecraft, seems to be the case indeed.

The same binary on saucy on a snb:
visual 0/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 1/4d: 32 depth, RGB: ff ff ff alphaMask = ff
visual 2/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 3/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 4/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 5/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 6/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 7/51: 24 depth, RGB: ff ff ff alphaMask = 0

trusty:
visual 0/4d: 32 depth, RGB: ff ff ff alphaMask = ff
visual 1/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 2/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 3/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 4/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 5/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 6/51: 24 depth, RGB: ff ff ff alphaMask = 0
visual 7/51: 24 depth, RGB: ff ff ff alphaMask = 0

[Maarten Lankhorst (mlankhorst)]

Not setting GLX_DEPTH_SIZE appears to fix the order.

BTW your test program garbles the id's, they're not identical. ;-)

saucy:
visual 0/47 fbconfig 8b
visual 1/82 fbconfig 8f
visual 2/ac fbconfig 94
visual 3/48 fbconfig 9d
visual 4/b0 fbconfig a1
visual 5/b3 fbconfig a6
visual 6/aa fbconfig 90
visual 7/b1 fbconfig a2

trusty:
visual 0/82 fbconfig 8f
visual 1/ac fbconfig 94
visual 2/47 fbconfig 8b
visual 3/b1 fbconfig a2
visual 4/b3 fbconfig a6
visual 5/aa fbconfig 90
visual 6/b0 fbconfig a1
visual 7/48 fbconfig 9d

Visuals:
0x047 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x048 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x0a7 24 tc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None
0x0a8 24 tc 0 32 0 r . . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None
0x0a9 24 tc 0 32 0 r . . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x0aa 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 Slow
0x0ab 24 tc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 4 1 None
0x0ac 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 4 1 None
0x0ad 24 dc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None
0x0ae 24 dc 0 32 0 r . . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None
0x0af 24 dc 0 32 0 r . . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x0b0 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x0b1 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 Slow
0x0b2 24 dc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 4 1 None
0x0b3 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 4 1 None
0x082 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None

GLXFBConfigs:
0x083 0 tc 0 16 0 r y . 5 6 5 0 . . 0 0 0 0 0 0 0 0 0 None
0x084 0 tc 0 16 0 r . . 5 6 5 0 . . 0 0 0 0 0 0 0 0 0 None
0x085 0 tc 0 16 0 r y . 5 6 5 0 . . 0 16 0 0 0 0 0 0 0 None
0x086 0 tc 0 16 0 r . . 5 6 5 0 . . 0 16 0 0 0 0 0 0 0 None
0x087 0 tc 0 16 0 r y . 5 6 5 0 . . 0 24 8 0 0 0 0 0 0 None
0x088 0 tc 0 16 0 r . . 5 6 5 0 . . 0 24 8 0 0 0 0 0 0 None
0x089 24 tc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None
0x08a 24 tc 0 32 0 r . . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None
0x08b 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x08c 24 tc 0 32 0 r . . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x08d 0 tc 0 16 0 r y . 5 6 5 0 . . 0 16 0 0 0 0 0 0 0 None
0x08e 0 tc 0 16 0 r y . 5 6 5 0 . . 0 16 0 16 16 16 0 0 0 Slow
0x08f 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
0x090 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 Slow
0x091 0 tc 0 16 0 r y . 5 6 5 0 . . 0 0 0 0 0 0 0 4 1 None
0x092 0 tc 0 16 0 r y . 5 6 5 0 . . 0 16 0 0 0 0 0 4 1 None
0x093 24 tc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 4 1 None
0x094 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 4 1 None
...

[Maarten Lankhorst (mlankhorst)]

So all things being equal, 8f and 8b differ only in depth, and since you set GLX_DEPTH_SIZE..

"GLX_DEPTH_SIZE: Must be followed by a nonnegative minimum size specification. If this value is zero, frame buffer configurations with no depth buffer are preferred. Otherwise, the largest available depth buffer of at least the minimum size is preferred. The default value is 0."

I guess it works as intended...

[Jana Saout (jana-h)]

I'm confused... so, you're essentially saying it's the fault of the application, choosing the wrong visual? So what exactly changed and why did it change and how is this "better" than before? I don't think the visual with a compositable alpha channel should be chosen as default by accident. (?) The behaviour might be correct for a certain point of view, but peeople would still like to know a solution, I guess?

[Maarten Lankhorst (mlankhorst)]

No, just that the test as you've written shows the correct behavior. The old behavior didn't care about depth, and was wrong.

You would probably need to fix lwjgl instead to select a non-alpha channel, or have lwjgl handle the alpha bits correctly.

[zEn (der-eremit)]

I had same Problem with about any linux steam game i own, on different systems with intel graphics.
And in Unity and KDE.
With newest updates I now, can't reproduce it anymore.