video of the effect here: http://www.youtube.com/watch?v=zSP2EIAkkJg running Ubuntu 13.04 updated as of ~4am friday morning (GMT). `lspci -v` reports: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. Device 0102 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at a0000000 (64-bit, non-prefetchable) [size=4M] Memory at 90000000 (64-bit, prefetchable) [size=256M] I/O ports at 2000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 while the effect is visible (it appears to have subsided for now) I can stop it reliably by placing my finger over the gap between the monitor hinge and the f2/f3 buttons. Maybe related to the ambient light sensor (I don't know where that's located, and it's a guess that that's what I'm affecting with my finger). at first I thought it was maybe related to load on the system but this appears to be a misnomer. I also thought that network or ssd activity may be influencing matters, but again this appears not so. I'm at a loss as to explain why it was happening, or why now it isn't while I'm reporting this bug, or whether it will return after a reboot. OS X does not exhibit the erratic jittering that I've described and recorded above. As such I concluded that the issue lies in the Linux+software domain rather than hardware malfunction.
Just sounds like the firmware on you Macbook has a feedback loop that is disabled by OS/X. What you can try is enabling drm.debug=6 (on the kernel commandline) and see if there are any ACPI requests to change the backlight. If there are none, then it is entirely internal to the ACPI backlight controller - but if there are you have a chance to filter them out - whilst getting the opportunity to reverse engineer the firmware... I am 99% sure this is notourbug.
Created attachment 78897 [details] dmesg : Macbook retina monitor jittery display Environment: ----------------------- kernel: 80ad9206c0d863832bc5f6008c4d1868d1df8e70 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Apr 19 14:36:51 2013 +0300 drm/i915: Make struct dpll == intel_clock_t This allows unifying a bunch of the PLL calculations and whatnot. Description: ----------------------- I reproduced this issue on our MacBook too, the kernel is this round -testing kernel. The display shaked heavily, by the way, our system is Fedora 18. I append the dmesg here, I'd like to track this if anything needed.
Created attachment 78904 [details] dmesg: MacBook retina display better with other pipe plugged Description: --------------------------- When I plugged another pipe like mini-DP or DP, MacBook retina displayed better, it's not shaking heavily like that. I appended the dmesg which MacBook retina && mini-DP_to_HDMI simultaneously plugged.
Hmm, this patch may be relevant: https://patchwork.kernel.org/patch/2972111/ It only seems to be for LVDS, but still worth a shot.
(In reply to comment #4) > Hmm, this patch may be relevant: https://patchwork.kernel.org/patch/2972111/ > It only seems to be for LVDS, but still worth a shot. I don't have this equipment now, our newly macbook pro retina can display correctly.
Hi Daniel Llewellyn, can you help us to re-check it with Chris's patch? Thx.
I guess Daniel Llewelleyn just kept driving after reporting this one. :)
Hi, sorry for the delay in responding. Ubuntu 13.10 does not exhibit the behaviour I describe above from 13.04. The kernel I'm now running is from a copy of Ubuntu 13.10 which was installed fresh today and is fully-updated as of a few hours ago. uname -r reports the kernel is 3.11.0-13-generic which is from Ubuntu's standard "saucy" repositories. I believe the issue as originally reported only manifested itself when the wifi adapter (an integrated Broadcom BCM4331 802.11a/b/g/n) was set to enabled in the network-manager AND associated with a wireless network. Just being enabled was not enough to cause the problem, IIRC, but the problem immediately arose as soon as the wifi was associated with a base-station. lspci on Ubuntu 13.10 currently reports that the Broadcom wifi is using the wl kernel module, and Ubuntu's "Software & Updates applet -> Additional Drivers" says the wifi is using the bcmwl-kernel-source proprietary package. packages.ubuntu.com shows that the bcmwl-kernel-source has had a version change between 13.04 and 13.10 releases of Ubuntu, which may account for the different behaviour: * raring (13.04): 6.20.155.1+bdcom-0ubuntu6 * saucy (13.10): 6.30.223.141+bdcom-0ubuntu1
Display underruns. Paulo and Ville have fixed tons of bugs here, so I think we could actually call this fixed for real.
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.