xserver-xorg-video-intel regression (Intel 945GM) [xorg-edgers]

> Grey tones now all render in pink, see attached screenshot.

That would appear to be a result of me playing with reducing the DefaultDepth to 16 on these bandwidth constrained devices. Hmm, if used a default depth of 15 that should prevent that discoloration. (It's been a useful exercise but I think there are too many bugs in the upper layers of the rendering stack for us to make the switch by default.)

>Upon login display no longer remains full screen. Display appears as static image in centre of screen rather than as full screen with working login animation.

This maybe unexpected. You have both a LVDS and DVI connected. So it is picking a mode common to both (1280x800) and cloning the desktop across. That will result in only the centre portion of the DVI output being used (if the monitor itself does not autoscale). I'm guessing this a bug in the display manager since monitors.xml says not to clone and to use native modes...

There will be an update in xorg-edgers in the next day or so that should fix up the discoloration - please let me know your opinion on the reduced depth rendering.

Sorry about the delay, its up in edgers now but will need about 4 hours to build because of the backlog.

Chris, Thanks for looking into this and also for your continued updates.

I pulled the changes down this afternoon and although they seem to have corrected the discolouration issue with my external monitor they have also introduced new regressions that have led to a loss of 3d rendering altogether meaning I am no longer able to use any of the desktops that require 3d acceleration (Unity, Cinnamon, Gnome-Shell).

I'm happy to provide logs & do any extra testing req to help get to the bottom of the issue, you'll just need to point me in the right direction.

Sounds like whatever was causing your setup to run in clone mode rather than as an extended desktop was also fixed (that should have been an issue caused by something other than -intel). However, libGL does not support hw acceleration to surfaces larger than 2048 on 945gm and so all the GL compositors fail miserably if you exceed that pixel count in any dimension. -intel handles it by using different functions on the GPU that can cope with the larger surfaces, or by splitting the operations into small enough chunks for the 3D pipeline - so that it just works.

Sorry, I should have added that lack of 3d acceleration is a problem no matter if I'm using my external monitor (which I usually use as single display with the laptop monitor off & not in extended or clone mode) or my laptop's built in display.

This means I've not been attempting to push 3d graphics to any area larger than the highest native resolution the external monitor supports, and in many cases the much smaller 800x600).

Further symptoms include a compete loss of graphics as soon as gnome loads when booting a 3.5.0 (Ubuntu) or 3.70 (edgers) kernel. The same is not a problem when booting a 3.8.0 custom compiled kernel.

Is this likely to a but in something other that -intel & should I be opening a new bug on these new issues with 3d acceleration?

My first thought is that it is still trying to use extended modes - can you attach your Xorg.0.log from a failed boot?

Sure thing, see attached.

This is getting weirder:

[ 16.025] (II) intel(0): switch to mode 1280x800 on crtc 4 (pipe 1)
[ 16.025] (EE) intel(0): get_fb: failed to add fb: 1280x800 depth=15, bpp=16, pitch=4096: 22
[ 16.025] (WW) intel(0): failed to restore desired modes on VT switch
[ 16.025] (II) intel(0): switch to mode 1280x800 on crtc 4 (pipe 1)
[ 16.025] (EE) intel(0): get_fb: failed to add fb: 1280x800 depth=15, bpp=16, pitch=4096: 22

Can you append drm.debug=6 to your kernel command line (grub) and then attach the dmesg from another failed boot.

Done

I don't see the telltale failure message in that dmesg. Do you mind recapturing it?

My mistake, turned the option on for the wrong kernel entry. This should be better.

This should handle the kernel regression more gracefully:

commit ef5edbf61686388126e62ce360a66dd8652b2493
Author: Chris Wilson <email address hidden>
Date: Sun Mar 3 09:29:53 2013 +0000

    sna: Probe for kernel support of framebuffer formats

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

When that pops up in xorg-edgers can you please test?

Thanks Chris, I'll keep an eye out for it and test when it comes down the pipe.

Oh well, it exposes critical bugs in mesa, so reverted. Yet again.

That's a shame, I've noted a couple of extra placed where regressions are making themselves known, though I'm not entirely sure if they're related 100% to this bug.

1. Flash video in Firefox is broken and does not render correctly. This is not the case in Google Chrome.
2. Transparent backgrounds render incorrectly.

Yes, those are symptomatic of the renders not being pixelformat-aware and just getting it wrong.

I finally got around to testing xserver-xorg-video-intel - 2:2.21.3+git20130308.78c75612-0ubuntu0sarvatt~quantal that was published in 08/03/10 and associated updates.

Happy to say that these seem to have pretty much resolved all issues that I've raised in this bug.

3d acceleration is back, flash videos play and colour depth is fine.

Thanks very much for your work on this Chris.

Now to fix the kernel oops that is described here https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1020393 and here.

Oh, here: https://bugs.freedesktop.org/show_bug.cgi?id=57495