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

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

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).

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

[This is an automated message]

Hi pitti,

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

[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

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.

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

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

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.)

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)

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.

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.

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.

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?

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.

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.

Hi Martin,

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

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.

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?

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.

 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.

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?

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.

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?

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?

> 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).

> 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
...

Indeed. Well, seems I was confused then.

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.

> 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.