Created attachment 72653 [details] Photo of graphics artefacts described I'm using Ubuntu 12.10 on my Mac Mini Server 6,2. I have two Dell U2412M (1920x1200@60Hz) monitors. (Full system info is below.) I initially tried to connect one monitor over the Thunderbolt/Displayport output. But from the moment rEFIt hands over to GRUB, the graphics look quite poor. Gradients are rough or dithered (including the boot splash, greeter screen and desktop background), window title bars look awful, and there a number of other ugly artefacts (see first photo). The resolution itself, however, is fine. Taking a screenshot does not demonstrate the problem (it looks fine when it's opened on another OS), but a photo shows it. Connecting a monitor to the HDMI output (using a HDMI/DVI adapter) looks fine. Windows 7 and OSX look fine on the same monitor using the Displayport input. There's one other interesting thing: - If I boot Ubuntu with only one monitor attached via HDMI/DVI, wait until it gets to the login screen and THEN connect a second monitor to the Thunderbolt port, they both look fine. So it seems possible to have nice output over Thunderbolt/DP. - If I boot with two monitors (connected via HDMI/DVI and Thunderbolt/DP respectively), one looks poor and one looks fine... BUT when I disconnect the Thunderbolt one, the OTHER (HDMI/DVI connected) monitor blanks for a second and comes back on looking just as poor as the Thunderbolt/DP did before. The kernel is 3.5.0-19-generic. lspci tells me I have: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) I can't see any errors in Xorg.0.log, but I don't want to paste the whole file here unless someone asks for it. sudo lshw -C display gives: *-display description: VGA compatible controller product: 3rd Gen Core processor Graphics Controller vendor: Intel Corporation physical id: 2 bus info: pci@0000:00:02.0 version: 09 width: 64 bits clock: 33MHz capabilities: msi pm vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: irq:49 memory:a0000000-a03fffff memory:90000000-9fffffff ioport:2000(size=64) OpenGL info from glxinfo is: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL version string: 3.0 Mesa 9.0.1 lsmod shows that the i915 driver is loaded. I have attached photos of normal looking graphics and the poor looking graphics, as well as lspci and glxinfo output, and the xorg log.
Created attachment 72654 [details] Photo of normal-looking graphics for comparison
Created attachment 72655 [details] lspci output
Created attachment 72656 [details] glxinfo output
Created attachment 72657 [details] Xorg log
Should have mentioned: the logs I've attached are from a session where I've booted up with a single monitor connected over Thunderbolt/Displayport. See also this Ask Ubuntu question: http://askubuntu.com/questions/223232/why-the-poor-graphics-from-my-intel-vga-over-thunderbolt-displayport
Please boot with drm.debug=0xe and attach the complete dmesg. I suspect there's dp dithering gone wrong, for which we've implemented quite some fixes recently. Hence retesting with 3.7 (or even 3.8-rc) is the first step.
Created attachment 72692 [details] dmesg output after booting with drm.debug=0xe
Just tried it with the 3.7.2-030702-generic kernel (from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7.2-raring/), but the symptoms are the same.
Just checked your logs, we don't dither ... strange. Can you please test whether this quick hack here changes anything? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 1b63d55..bb3f9d5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -198,6 +198,10 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp, mode_rate = intel_dp_link_required(mode->clock, 24); max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes); + if (adjust_mode) + mode->private_flags + |= INTEL_MODE_DP_FORCE_6BPC; + if (mode_rate > max_rate) { mode_rate = intel_dp_link_required(mode->clock, 18); if (mode_rate > max_rate)
Can I apply that to the 3.5 kernel, or do I need 3.7?
Probably only applies to 3.8-rc kernels, maybe 3.7.
I tried your patch on the 3.8.0 kernel from Ubuntu's git repo (Ubuntu-3.8.0-0.4 under the raring repo), but it made no difference. Do you want the dmesg output again?
(In reply to comment #12) > I tried your patch on the 3.8.0 kernel from Ubuntu's git repo > (Ubuntu-3.8.0-0.4 under the raring repo), but it made no difference. Do you > want the dmesg output again? Yes please. There have been plenty of changes since 3.5, so it might be helpful.
Created attachment 73215 [details] dmesg output (with drm.debug=0xe) after applying patch
I booted up today, and for some reason the banding is now happening all the time — even over HDMI/DVI which was not the case before. I've tried to isolate a package upgrade or other change that triggered it, but can't find it. (I installed a bunch of libraries for building unrelated software before this happened, but I can't see how they would affect my graphics driver.) The i915 module is exactly the same version as before. This is still marked as "needinfo", so let me know if there's anything else I can do to debug this for you.
So that's not quite the whole story — it seems that now the "good" display output is the thunderbolt/DP one! In other words, it's spontaneously switched. I still can't isolate which change caused it.
Aha! I found that issuing this command seems to fix the problem: $ sudo intel_reg_write 0x70008 0xC4002000 I found it here: http://ubuntuforums.org/showpost.php?p=12523426&postcount=3 ...which references bug #46800: https://bugs.freedesktop.org/show_bug.cgi?id=46800 ...and this email: http://lists.freedesktop.org/archives/intel-gfx/2012-February/015395.html Hope that helps. I have no idea whether this is safe to do, though.
Please try the drm-intel-next-queued branch of http://cgit.freedesktop.org/~danvet/drm-intel/ which contains Ville's patches to fix bug 46800. If that does not work, please post the reg read result of the same register before issuing the write: (In reply to comment #17) > $ sudo intel_reg_write 0x70008 0xC4002000
commit 78114071ff9e3c2f6c1715bfb01ac8c0b3618e72 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jun 13 00:54:57 2013 +0200 drm/i915: set up PIPECONF explicitly on ilk-ivb
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.