Subject : i915: 2.6.36-rc2 wrong resolution on gdm start Submitter : Ivan Bulatovic <combuster@gmx.com> Date : 2010-08-24 1:00 Message-ID : 1282611655.2177.19.camel@localhost.localdomain References : http://marc.info/?l=linux-kernel&m=128261168202306&w=2 Handled-By : Chris Wilson <chris@chris-wilson.co.uk> This entry is being used for tracking a regression from 2.6.35. Please don't close it until the problem is fixed in the mainline. Caused by: commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Aug 18 13:20:54 2010 -0700 drm/i915: wait for actual vblank, not just 20ms Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling). This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> First-Bad-Commit : 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
I'm also hit by this bug, since 2.6.36-rc2 (+confirmed in 2.6.33-rc3) X.org incorectly reports TV1 output as being connected. I'm prepared to test your patches!
My Dell d340 also incorrectly reports TV1 output as being connected, resulting in a different screen resolution. I bisected-ed to comit 9559fcdbff4f93d29af04478bbc48294519424f5 drm/i915: fix vblank wait test condition
That commit should cause incorrect resolution when KMS starts, not spurious TV detection.
Maciej and Matej should check there dmesg. Mine has: [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 31. Console: switching to colour frame buffer device 106x30 which is registered as bugzilla 17021. During the bisect, a half framebuffer (30 line console) at startup coinsided with a connected TV1 out reported by xrandr. How do I tel gitt that I want to go to commit f4e385ccfc10f44364101b126d1ac52b4c806f1d which is just before 9599cfd... . I want to see if the dmesg *ERROR* line is there.
You can use git reset --hard f4e385ccfc10f44364101b126d1ac52b4c806f1d (This will modify the git HEAD reference and update your working tree: any changes not committed or referenced by something other than HEAD will be lost.)
(In reply to comment #4) > Maciej and Matej should check there dmesg. Mine has: > > [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect > flickering: entries required = 36, available = 31. > Console: switching to colour frame buffer device 106x30 > > which is registered as bugzilla 17021. This seems to be unrelated and should not have bad side-effects: http://marc.info/?l=linux-fbdev&m=128215880110324&w=2
git reset --hard f4e385cc.....: [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 31. Console: switching to colour frame buffer device 160x50 framebuffer ok, tv disconnected ok, FIFO *ERROR* not relevant. -- Hans
Created attachment 29202 [details] A collection of logs pre error at commit ffe3....
Created attachment 29272 [details] A collection of logs A collection of logs post error at commit 9559....
2.6.36-rc3-00396-gbe6200a solves the problem for me - e.g. TV is correctly detected as disconnected and native resolution of my LCD is choosen.
I also encounter this problem and it's caused by another commit. A git-bisect run shows that the first bad commit is the following: cb0953d734348e8862d6d7edc666cfb3bf6d8fae is the first bad commit commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae Author: Adam Jackson <ajax@redhat.com> Date: Fri Jul 16 14:46:29 2010 -0400 drm/i915: Initialize LVDS and eDP outputs before anything else If I revert it, the problem doesn't occur.
François can you double check your analysis? AIUI, that should have had an effect of the ordering of outputs in UI. 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 caused lots of varied and interesting confusion, so please do make sure you first test with the current Linus kernel. If indeed the regression stands, please do open a new bug report so we can address it separately. Thanks.