SYSTEM ENVIRONMENT chipset: Intel Corporation 5 Series/3400 Series Chipset graphic card: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) system architecture: i686 xf86-video-intel/xserver/mesa/libdrm version: libdrm-2.4.23 xserver-xorg-video-intel-2.14.0 xserver-7.6 mesa-7.10.2 kernel version: 2.6.38-8-generic-pae Linux distribution: Ubuntu 11.04 beta 2 Machine or mobo model: Lenovo Thinkpad T410s 2901-ATU Display connector: VGA REPRODUCE STEPS 1 - I turn on the external lcd monitor; 2 - Plug the VGA cable of external lcd monitor in my graphic card; 3 - I see that image in lcd monitor is blurring; 4 - I cry! :S
Created attachment 46076 [details] Xorg.0.log
Created attachment 46077 [details] xrandr --verbose
Created attachment 46078 [details] intel_reg_dumper output
Created attachment 46079 [details] vbios.dump
A better description about my problem: the image of external monitor shakes!
This due to that we do not disable SSC when there is more than one output on the shared clock source. (Technically we we have both a SSC-capable output (LVDS, DP) and an non-SSC-capable (VGA)).
Created attachment 46112 [details] [review] Don't enable SSC on the common clock source when shared with a non-SSC output. Try this patch for starters.
Chris Wilson, I applied this patch in my custom kernel and it doesn't boot. The screen was black and my capslock button was blinking. Do you have another solution?
Sorry Chris Wilson, but I a newbie to compile kernel in debian distro. Compiling kernel with ou without patch I get kernel panic. lol I'm learning how compile kernel with your patch and I will answer you soon.
*** Bug 28306 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Created an attachment (id=46112) [details] > Don't enable SSC on the common clock source when shared with a non-SSC output. > > Try this patch for starters. Sorry for being probably complete n00b, but is there a way of testing this patch without compiling the whole kernel?
I have good news and bad news for you Chris Wilson. Good news: the patch was applied with success in kernel and it isn't generate kernel panic. Bad news: the patch doesn't solve the problem. Now I know how compile the kernel with kernel-package. :)
(In reply to comment #7) > Created an attachment (id=46112) [details] > Don't enable SSC on the common clock source when shared with a non-SSC output. > > Try this patch for starters. Chris, patch doesn't work for me. Is there any log you want?
*** This bug has been marked as a duplicate of bug 28306 ***
Created attachment 46702 [details] [review] Don't enable SSC on the common clock source when shared with a non-SSC output.
(In reply to comment #15) > Created an attachment (id=46702) [details] > Don't enable SSC on the common clock source when shared with a non-SSC output. I can't apply that patch in kernel-2.6.38. I get a hunk failed in drivers/gpu/drm/i915/intel_bios.c.
Created attachment 46770 [details] intel_bios.c.rej of kernel-2.6.38
(In reply to comment #17) > Created an attachment (id=46770) [details] > intel_bios.c.rej of kernel-2.6.38 It should be applied against kernel 2.6.39.
I provided a build for Ubuntu with this patch applied on the Launchpad bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/614238), and the feedback from testers looks somewhat mixed but generally positive. The wavy output seems to be gone, although most report that one or both displays are black when hotplugging an external monitor. Maybe that's an unrelated issue, I'm not sure.
Hrm, I guess I should be specific about what patch was applied to the test build. The build was essentially 2.6.39-rc7 plus the patch from comment #15.
(In reply to comment #15) > Created an attachment (id=46702) [details] > Don't enable SSC on the common clock source when shared with a non-SSC output. I tested this patch on the latest 2.6.39, debian version. The flickering is gone but it still allows to use one monitor at a time. Let me know if there's anything I can do to help.
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.