Bug 16444

Summary:	[855GM] running X in 16bit mode causes compiz to fail (white screen)
Product:	xorg	Reporter:	Ilyes Gouta <ilyes.gouta>
Component:	Driver/intel	Assignee:	Michael Fu <michael.fu>
Status:	RESOLVED DUPLICATE	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	Keywords:	NEEDINFO
Version:	7.3 (2007.09)
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Ilyes Gouta 2008-06-20 08:29:05 UTC

Hi all,

I have been running X in 16bit mode on my laptop, which has an integrated intel 855GM, for a while and then decided to install compiz-fusion to try it. Whenever I enable it, the screen turns white and the desktop isn't useable anymore. Holding control and pressing on the mouse left button toggles on the Desktop 3D Cube correctly however all its faces are white. On the console I get the following message:

Warn: No GLXFBConfig for depth 32, repeadly.

Now, changing /etc/X11/xorg.conf and setting X's depth to 24bit fixes the issue, however the performance is kind of slow.

This seems like a failure or a limitation in the intel driver. Does the intel driver support all the OpenGL features required by compiz in 16bit mode? If not, could you please tell me the technical reasons?

Regards,
Ilyes Gouta.

Comment 1 Ilyes Gouta 2008-06-21 05:48:13 UTC

Hi,

Seems like this issue was reported in bug #15641 and bug #14441. In the respective attachments, it's reported that commenting:

pDRIInfo->texOffsetStart = I830TexOffsetStart;

in xf86-video-intel/src/i830_dri.c would actually fix the problem. However the latest git code still contains that line, but it's protected by a couple of #define(s):

#if DRIINFO_MAJOR_VERSION > 5 || \
    (DRIINFO_MAJOR_VERSION == 5 && DRIINFO_MINOR_VERSION >= 3)
      if (pI830->useEXA)
	 pDRIInfo->texOffsetStart = I830TexOffsetStart;
#endif

Would it be possible to resolve the problem by disabling EXA? What would be the impact on the overall 3D performance of the driver?

Regards,
Ilyes Gouta.

Comment 2 Michel Dänzer 2008-06-21 07:21:03 UTC

Beware also of bug 12385.

Comment 3 Ilyes Gouta 2008-06-21 08:06:58 UTC

Hi,

I changed my /etc/X11/xorg.conf file and added a couple of lines:

Option      "AccelMethod" "XAA"
Option      "XAANoOffscreenPixmaps" "true"

in Section "Device"

And these two lines actually fixed the issue, i.e no more white screens when running compiz in 16bit mode. The performance of compiz is really nice on my rather old 855GM part. The first option disables EXA thus pDRIInfo->texOffsetStart = I830TexOffsetStart won't be executed.

Now, I have emerald not drawing the window titles at all (window decorator) and I'm getting:

compiz (core) - Warn: No GLXFBConfig for depth 32

I'm getting really a lot of them. This suggests that the driver doesn't handle some kind of texture formats...

Any ideas?

Regards,
Ilyes Gouta.

Comment 4 Gordon Jin 2008-06-24 18:29:16 UTC

What's the driver version you are using? I can't reproduce on my 855GM with stable branch git.

Comment 5 Ilyes Gouta 2008-06-27 02:17:31 UTC

Hi,

So I gave this issue another shot, and I found that the white screen symptom happens only when running compiz without exporting LIBGL_ALWAYS_INDIRECT=1. It's not about EXA vs. XAA nor 16bit vs. 32bit X.

The remaining message:
compiz (core) - Warn: No GLXFBConfig for depth 32

Is caused by compiz/emerald explicitly creating 32bit pixmaps whereas I configured X to run in 16bit. And what happens is that GLX/DRI (the intel driver) isn't able to find a native match for 32bit visuals (glxinfo returns a list of visuals which are 16bit only). This causes bindPixmapToTexture to fail and emerald isn't able to provide the window decoration anymore.

So, this is *not* an issue with the intel drivers. Although I still have a small question: Why offscreen pixmaps can't be created using a 32bits color depth and bound to textures, when running X in 16bit? I guess that the 855GM is able to do format conversion when blitting to the screen...

Regards,
Ilyes Gouta.

Comment 6 Michel Dänzer 2008-06-27 03:06:13 UTC


*** This bug has been marked as a duplicate of bug 15477 ***

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.