white screen on second session with compiz: pretends to have a second DRI capable head where it doesn't

Bug #269509 reported by Martin Pitt
44
This bug affects 4 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Medium
compiz (Ubuntu)
Fix Released
High
Michael Vogt
xserver-xorg-video-intel (Ubuntu)
Invalid
Low
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

Compiz recently started by default again, thanks to some fixes in gnome-session. Now the old problem of "second X session just has white screen" is back. Parrotting Michael, this is due to the X server pretending that it has two DRI capable screens, but it is a known problem that there can only be one compiz X.org at a time.

I'll attach glxinfo output from my primary session (with compiz running fine) and the output from the guest session (where I just get a white screen).

[lspci]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
 Subsystem: Dell Device [1028:0201]

Related branches

Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Michael Vogt (mvo) wrote :

I will add a workaround to the compiz wrapper that checks:
"""OpenGL renderer string: Software Rasterizer"""
in glxinfo.

Changed in compiz:
assignee: nobody → mvo
importance: Undecided → High
milestone: none → intrepid-alpha-6
status: New → Triaged
Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

I added a workaround in my bzr tree that will be part of my next upload (it will not start compiz with software rasterization).

Changed in compiz:
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.7.7+git20080807-0ubuntu8

---------------
compiz (1:0.7.7+git20080807-0ubuntu8) intrepid; urgency=low

  * debian/patches/046_compiz_manager_second_screen.patch:
    - add detection for software rasterizer and do not start
      compiz in this case (LP: #269509)
  * debian/patches/047_no_display_compiz_desktop.patch:
    - add NoDisplay=true to make it not appear in the menus

 -- Michael Vogt <email address hidden> Tue, 16 Sep 2008 10:11:04 +0200

Changed in compiz:
status: Fix Committed → Fix Released
Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automated message]

Hi pitti,

Please attach the output of `lspci -vvnn` too.

Changed in xserver-xorg-video-intel:
status: New → Incomplete
Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel:
status: Incomplete → New
status: New → Incomplete
Revision history for this message
Martin Pitt (pitti) wrote :

I'm on jaunty du jour (2.6.28-3-generic, -intel 2:2.5.1-1ubuntu7), and it got even worse.

Both the primary and secondary X session's glxinfo still say

  direct rendering: Yes

but now even the primary session says

  OpenGL renderer string: Software Rasterizer

I'm not actually sure whether that's true. glxinfo reports 65 FPS in default window size, which seems faster than software rendering, and compiz works fine, so I think glxinfo lies.

I attach both glxinfo outputs again, for current jaunty.

Changed in xserver-xorg-video-intel:
status: Incomplete → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks for testing; this should go upstream. Setting to Triaged for now.

description: updated
Changed in xserver-xorg-video-intel:
importance: Undecided → High
status: Confirmed → Triaged
Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Pitti,

The 'software acceleration only on second head' is a pretty well known issue and probably not worth reporting upstream since I'm sure they know about it already. However, if you're seeing it report 'software rasterizer' on the first head too, that does seem to be a legitimate bug. But I have some follow up questions...

First, can you reproduce this when booted into a single session? I.e. does it always show software rasterizer, or only when you have the guest session going? I tried reproducing it on my 965 box but couldn't, would you mind listing the exact steps to reproduce it?

Second, could you attach your Xorg.0.log and Xorg.20.log taken from when both sessions are up; upstream usually wants that.

Third, you mentioned that glxinfo reports 65 fps... did you mean glxgears? 65 seems like a pretty low framerate. Do you recall or could you test what you get when running the Intrepid LiveCD where the primary session is not showing up as software rasterizer?

Thanks ahead of time

Revision history for this message
Bryce Harrington (bryce) wrote :

Oh also, I meant to ask that with jaunty, on the second head are you seeing the originally reported issue of a white screen when compiz is running, or is that issue resolved now? (You mentioned that things are worse, so I assume the white screen problem is still there, but I'm wondering how you're getting the glxinfo data if that's the case.)

Changed in xserver-xorg-video-intel:
status: Triaged → Incomplete
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 269509] Re: white screen on second session with compiz: pretends to have a second DRI capable head where it doesn't

Bryce Harrington [2009-01-07 6:32 -0000]:
> However, if you're seeing it report 'software rasterizer' on the
> first head too, that does seem to be a legitimate bug.

I do.

> First, can you reproduce this when booted into a single session? I.e.
> does it always show software rasterizer

yes.

>, or only when you have the guest session going?

No, I first produced glxinfo.primarysession.jaunty.txt, then started
the second session, and then produced the other dump.

> I tried reproducing it on my 965 box but couldn't, would you mind
> listing the exact steps to reproduce it?

for glxinfo:
- boot
- log into GNOME
- glxinfo > glxinfo.primarysession.txt
- start guest session
- glxinfo > /tmp/glxinfo.guest.txt
- switch to primary session with ctrl+alt+f7 (since quitting the guest
  session kills all files of guest)
- copy /tmp/glxinfo.guest.txt to ~
- switch back to guest and close the session

For checking white screen:
 - edit /usr/bin/compiz and disable the abort_* thing in

        # check if we run with software rasterizer and if so, bail out
        if check_software_rasterizer; then
                verbose "Software rasterizer detected, aborting"
                abort_with_fallback_wm
        fi

Then start the guest session.

> Second, could you attach your Xorg.0.log and Xorg.20.log taken from when
> both sessions are up; upstream usually wants that.

Done.

> Third, you mentioned that glxinfo reports 65 fps... did you mean
> glxgears?

Yes, sorry. glxgears.

> 65 seems like a pretty low framerate. Do you recall or could
> you test what you get when running the Intrepid LiveCD where the primary
> session is not showing up as software rasterizer?

Will do in a minute and report back.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Revision history for this message
Martin Pitt (pitti) wrote :

Bryce Harrington [2009-01-07 6:36 -0000]:
> Oh also, I meant to ask that with jaunty, on the second head are you
> seeing the originally reported issue of a white screen when compiz is
> running, or is that issue resolved now?

It's still there.

> worse, so I assume the white screen problem is still there, but I'm
> wondering how you're getting the glxinfo data if that's the case.)

I did two tests, one with guest session and metacity (which works) and
one with guest session and compiz (which fails). See previous mail for
my reproduction steps.

Revision history for this message
Martin Pitt (pitti) wrote :

On the intrepid live CD (same system and hardware) I get 615 fps with glxgears (standard window size, using the mesa intel 945 driver). On my current jaunty I only get 105 fps, using the software rasterizer.

Revision history for this message
Bryce Harrington (bryce) wrote :

Ahh, okay so it seems there are two independent bugs:

I. Whitescreen on secondary session with compiz activated

II. Regression from Hardy to Intrepid: Software rasterizing instead of hardware rasterizing.

Thanks for the additional information.

Revision history for this message
Martin Pitt (pitti) wrote :

Bryce Harrington [2009-01-07 10:43 -0000]:
> I. Whitescreen on secondary session with compiz activated

Yes, due to second screen claiming "DRI: Yes" although it uses
software rasterizer. That's the original bug.

> II. Regression from Hardy to Intrepid: Software rasterizing instead of
> hardware rasterizing.

It's a regression from intrepid to jaunty. Shall I file a separate bug
for this?

Revision history for this message
In , Bryce Harrington (bryce) wrote :

https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/269509

[Problem]
On this hardware, starting a second session and activating compiz leads to a white screen, presumably because the second session is assuming DRI is present when it isn't.

[Discussion]
Ubuntu has a 'Guest session' feature which allows starting a second X session. It is said that DRI is not available for anything but the primary session, which is unfortunate but acceptable. However, when starting the xserver on a second session, it does not seem to be smart enough to realize it should not try using DRI, because it consequently presents a blank white, non-interactive screen.

Expected behavior would be for it to realize DRI is unavailable and load without DRI enabled.

Compiz currently works around this by including a check for 'Software Rasterizer' in its startup script. However, we'd like to not need to work around this issue like that, as it's kind of a hack.

[lspci]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
 Subsystem: Dell Device [1028:0201]

[Original Report]
Compiz recently started by default again, thanks to some fixes in gnome-session. Now the old problem of "second X session just has white screen" is back. Parrotting Michael, this is due to the X server pretending that it has two DRI capable screens, but it is a known problem that there can only be one compiz X.org at a time.

I'll attach glxinfo output from my primary session (with compiz running fine) and the output from the guest session (where I just get a white screen).

> I tried reproducing it on my 965 box but couldn't, would you mind
> listing the exact steps to reproduce it?

for glxinfo:
- boot
- log into GNOME
- glxinfo > glxinfo.primarysession.txt
- start guest session
- glxinfo > /tmp/glxinfo.guest.txt
- switch to primary session with ctrl+alt+f7 (since quitting the guest
  session kills all files of guest)
- copy /tmp/glxinfo.guest.txt to ~
- switch back to guest and close the session

For checking white screen:
 - edit /usr/bin/compiz and disable the abort_* thing in

        # check if we run with software rasterizer and if so, bail out
        if check_software_rasterizer; then
                verbose "Software rasterizer detected, aborting"
                abort_with_fallback_wm
        fi

Then start the guest session.

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=21852)
Xorg.log.primary

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=21853)
Xorg.log.guest

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=21854)
glxinfo.primarysession.jaunty.txt

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=21855)
glxinfo.guestsession.jaunty.txt

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Martin,

I've filed bug II upstream at https://bugs.freedesktop.org/show_bug.cgi?id=19492. Please subscribe to that bug in case they need further information or wish you to test something.

Revision history for this message
Bryce Harrington (bryce) wrote :

Bug I is upstream at https://bugs.freedesktop.org/show_bug.cgi?id=19493.

Since I think I can only link to a single upstream bug, and since this was the original, I'll link this LP bug to this fdo bug. If you think it worthwhile to have a LP/fdo link for bug II, it may make sense to file a new separate bug for that; your call. I think we have all the info necessary for both bugs, but we'll see what upstream thinks.

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Martin,

Upstream needs some further information. Please subscribe to the upstream bug and supply the requested information there.

Revision history for this message
Martin Pitt (pitti) wrote :

Thanks Bryce, I sub'ed to both upstream bugs and replied to upstream's questions. Looks as if 19492 might actually be a /dev permission problem.

Revision history for this message
Bryce Harrington (bryce) wrote :

Martin, ahh, yes I think we've had several bug reports about that.

What package is responsible for setting these permissions? hal? Can it be updated to set them more permissively?

If not, then it sounds like user accounts need to be set up to be included in the video group. I notice my current account has this group, but this system has been upgraded since hardy; perhaps fresh installs miss it?

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 269509] Re: white screen on second session with compiz: pretends to have a second DRI capable head where it doesn't

Hello Bryce,

Bryce Harrington [2009-01-19 1:04 -0000]:
> What package is responsible for setting these permissions? hal?

udev by default, but I guess this is a case for automatic ACLs via
hal/ConsoleKit. In fact I just saw that it already tries to do so, but
for some reason it does not work. I'll have a look at this.

> Can it be updated to set them more permissively?

Yes, it's a bug.

Revision history for this message
Martin Pitt (pitti) wrote :

 hal (0.5.12~rc1-0ubuntu6) jaunty; urgency=low
 .
   * Add 00git_fix_drm_acls.patch: Fix copy&paste error which assigned
     the wrong access_control.file for /dev/drm/card* devices. It
     previously copied "input.device", but should be
     "linux.device_file". This brings back hardware GL rendering,
     instead of always using the Mesa software rasterizer. (Part of
     LP #269509)

Fix committed upstream, too.

Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel:
status: Incomplete → Triaged
Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

Your second X Server wasn't using DRI, though you seem to suggest that it was somehow. Compiz apparently doesn't do well with the software rasterizer, which isn't surprising.

With KMS and the current driver, thanks to Dave Airlie, you'll get multiple servers with DRI support. Unless you intend this bug to be about software rasterizer issues with compiz, I think this is RESOLVED -> FIXED now.

Revision history for this message
Bryce Harrington (bryce) wrote :

Martin, upstream seems to think the problem is rather bugs in compiz when Software Rasterizer is being used. That seems plausible, but what are your thoughts?

Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

I tend to agree.

I think the basic "problem" here is that mesa became "too good" with emulating in the software rasterizer. :-) In other words, I think it's correct for compiz to check for the software rasterizer itself.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

Argh, please ignore my previous comment. Of course we aren't talking about "3D GL" capability here, but about "DRI", which should be something backed by hardware.

However, upstream says that it's fixed in the latest (development, I assume) version of -intel, so we should get that in Karmic?

Changed in xserver-xorg-video-intel (Ubuntu):
importance: High → Low
status: Won't Fix → Triaged
Revision history for this message
Bryce Harrington (bryce) wrote :

I interpret "With KMS and the current driver..." to mean, the -intel 2.6.3 driver when used with KMS (i.e. by flipping UXA on). But I could be wrong. If I'm right, it would be easy enough to test...

Note that "Software Rasterizer" is indeed provided by mesa, so by that you're right. Perhaps the root problem here is that compiz really wants to know if hardware DRI is available, but isn't considering that it could be provided by software. Perhaps it should exclude "Software Renderer" in its checking?

Revision history for this message
Martin Pitt (pitti) wrote :

> Perhaps it should exclude "Software Renderer" in its checking?

That's exactly what it does now.

So if the bug was solely about "compiz fails on second session", we could close this. However, it says "second X server pretends to be DRI capable", which mesa is clearly not. I don't mind if the -intel task gets closed as invalid, or whether you want to keep it around for the fact that -intel currently just supports one DRI capable head (this is an issue with e. g. having the gdm session and the user's session both use composite, which isn't possible with the current intel driver).

Revision history for this message
Bryce Harrington (bryce) wrote :

> However, it says "second X server pretends to be DRI capable", which mesa is clearly not.

Err... maybe I'm confused but I am not seeing that the X server is pretending to be DRI capable. From the guest Xorg.0.log it clearly says that DRI is disabled:

(EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.
...
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
...

Revision history for this message
Martin Pitt (pitti) wrote :

Indeed. Well, seems I was confused then.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Zaf (tommyboy14482) wrote :

Hi, I'm sort of a noob when it comes to these sort of things (bugs and fixes) but I'm having the white screen problem on my computer when trying to log back on to my first session while compiz is activated. Now apparently this bug is considered fixed so can someone explain to me what I need to do ? I'm running Jaunty and here's my glxinfo if that helps :

http://pastebin.com/m5e1b4c58

I would be very grateful for any help fixing this while being able to still use compiz.

Revision history for this message
Bryce Harrington (bryce) wrote :

> Hi, I'm sort of a noob when it comes to these sort of things (bugs and fixes)

Hi Zaf, tip #1 is that if the bug you think you have is closed, then it's likely you have some unrelated bug that just happens to have similar symptoms. See http://wiki.ubuntu.com/X/Reporting for tips on creating your own bug report.

Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.