Created attachment 90401 [details] dmesg of booting vanilla v3.7 kernel Hi, I found that a quirk merged in v3.6-rc4 distorts the image displayed on my external vga monitor. This symptom begins as soon as the kernel takes over control over the graphic stack. The symptom is that the image which is displayed on the external VGA (an ASUS V222U) is 1 inch too big on either side of the display. As if it was zoomed in on the center. (The image is more pixely than normal too, as a result of the 'zooming') Reverting the commit commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b Author: Paul Menzel <paulepanter@users.sourceforge.net> Date: Wed Aug 8 23:12:19 2012 +0200 drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S fixes the issue. I attach dmesg with drm.debug=6 and xorg.0.log from v3.7 kernels with and without the revert.
Created attachment 90411 [details] xorg.0.log of vanilla v3.7
Created attachment 90421 [details] xrandr verbose on vanilla v3.7
Created attachment 90431 [details] v3.7 with offending commit reverted
Created attachment 90441 [details] xorg.0.log of v3.7 with offending patch reverted
Created attachment 90451 [details] xrandr --verbose of v3.7 with offending patch reverted
That commit changes the timings, which means that on analog outputs you need to recalibrate the image. If that doesn't help, we need to revert that quirk - the description in 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b sounds more like an underrun issue papered over by the reduced dotclock ... Ajax, got ideas here?
Daniel, thank you for commenting. (In reply to comment #6) > That commit changes the timings, which means that on analog outputs you need > to > recalibrate the image. Florian, if it is not clear, there should be a button on the monitor to calibrate the monitor. It should be the one on the left [1] I believe. […] [1] http://www.asus.com/Display/LCD_Monitors/VW222U/
Florian, the model name should be V*W*222U, if I am not mistaken. Could you please update the bug title as I am not allowed to do that.
Paul, can you please attach a drm.debug=0xe dmesg to your original bug report at https://bugs.freedesktop.org/show_bug.cgi?id=17629 ? I'm leaning towards this being just another incarnation of the DSPARB bug we need to fix on gen3 (which includes your i910 chipset) and reverting the edid quirk ... dmesg without the patch should be enough to tell.
(In reply to comment #9) > Paul, can you please attach a drm.debug=0xe dmesg to your original bug report > at https://bugs.freedesktop.org/show_bug.cgi?id=17629 ? This will take some time (months). :( > I'm leaning towards this being just another incarnation of the DSPARB bug we > need to fix on gen3 (which includes your i910 chipset) and reverting the edid > quirk ... dmesg without the patch should be enough to tell. Should I sent the revert to the list? I guess we will be able to fix this with the other monitor/TV I have access to, too. Chris, also wanted to set up one of his test system as far as I remember.
(In reply to comment #10) > Should I sent the revert to the list? I guess we will be able to fix this > with > the other monitor/TV I have access to, too. Chris, also wanted to set up one > of > his test system as far as I remember. Yeah, that sounds like the best course of action - I'll reopen your fdo bug meanwhile. And since your other monitor clearly shows the DSPARB bug we should be able to fix things.
On Mon, 7 Jan 2013 09:41:32 +0000 (UTC) bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=52281 > > > > > > --- Comment #7 from Paul Menzel <paulepanter@users.sourceforge.net> > 2013-01-07 09:41:32 --- > Daniel, thank you for commenting. > > (In reply to comment #6) > > That commit changes the timings, which means that on analog outputs you > need to > > recalibrate the image. > > Florian, if it is not clear, there should be a button on the monitor to > calibrate the monitor. It should be the one on the left [1] I believe. > > […] > > [1] http://www.asus.com/Display/LCD_Monitors/VW222U/ > I'm away from the monitor for about 12 days... but even having to press that button would be a regression in my point of view. I also think that I tried turning the monitor on and off at least once. Could that trigger a recalibration too? One thing I found last weekend: My login screen (gdm) seems to get the size of the screen right. (I tested with trying to move the mouse beyond the monitor edge.) The kernel framebuffer console and my kde session: not so much. Regards, Flo
Revert submitted: https://patchwork.kernel.org/patch/1971831/
A patch referencing this bug report has been merged in Linux v3.9-rc1: commit db3985e5ca8f50fc17606855ba394783d11683a5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Feb 13 20:37:48 2013 +1000 Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"