Created attachment 38853 [details] Xorg.0.log Chipset: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller Arch: x86_64 libdrm: 2.4.21, Mesa: 7.8.2, X Server: 1.9.0, xf86-video-intel: 2.12.0 kernel: 2.6.36-rc4-00214-g2422084 Distribution: Gentoo Linux Machine: MSI PR-200 laptop Connection: DVI (via HDMI-to-DVI cable, i.e. the laptop has HDMI output). Problem description: after upgrading to 2.6.36-rc4, the text on the external screen is blurry, but only at the middle of the screen. At the top and at the bottom it is quite crisp. Connecting the laptop with the VGA cable or reverting to the old kernel fixes the problem. I will try to connect another LCD display later today and report back. I'm attaching two photos to prove my point -- I filled the whole screen with letters and took photos with a digital camera at the very top and at the middle of the screen. The kernel that works OK is 2.6.35-gentoo-r5 manually patched with this patch (http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg00835.html). Without the patch, the kernel crashes when I try to put the external display into its native resolution.
Created attachment 38854 [details] dmesg
Created attachment 38855 [details] xorg.conf
Created attachment 38856 [details] xrandr --verbose
Created attachment 38857 [details] vbios.dump
Created attachment 38858 [details] Picture of the screen at the middle of the screen
Created attachment 38859 [details] Picture of the screen at the top of the screen
Created attachment 38860 [details] intel_gpu_dump
With a bit of luck, there will be a clue in the modesetting registers. Can you grab *intel_reg_dumper* (you might have to build it from source from xorg/apps/intel_gpu_tools) and capture the output from a working kernel and current? Thanks. My first instinct says panel fitting or dithering...
Created attachment 38862 [details] regs dump for 2.6.35-gentoo-r5 (i.e. good)
Created attachment 38863 [details] regs dump for 2.6.36-rc4-00214-g2422084 (i.e. bad)
Right, intel_regs_dumper :) Done
The difference appears to be in the sync bits: good: DVOB: 0xc000009c (enabled, pipe B, no stall, +hsync, +vsync) bad: DVOB: 0x8000008c (enabled, pipe A, no stall, +hsync, -vsync) (or the switch from pipe B to pipe A...) Can you try: xrandr --newmode "1680x1050_bug30314" 59.0 1680 1728 1760 1840 1050 1053 1059 1080 +hsync +vsync xrandr --addmode DVI1 1680x1050_bug30314 xrandr --output DVI1 1680x1050_bug30314 (That should switch to a new mode identical to the preferred mode in all but the vsync bits and set the registers the same as for the good kernel.)
First of all, it does solve the problem. Second, the actual line I had to use was xrandr --newmode "1680x1050_bug30314" 120.0 1680 1728 1760 1840 1050 1053 1059 1080 +hsync +vsync (note the clock argument). For some reason, when using 59.0 as an argument would produce the following mode: h: width 1680 start 1728 end 1760 total 1840 skew 0 clock 32.1KHz v: height 1050 start 1053 end 1059 total 1080 clock 29.7Hz So I took twice the wanted mode. I have to say, I have absolutely no idea what it all means.
Ah yes, I mistook the first parameter for the vrefresh and not the dotclock, which wants to be 119.0. The bad news is that your EDID is incorrectly reporting the sync flags on the native mode, and you will have to manually override using a modeline. I don't think this is our bug. :(
Seems like you are right, I verified it with read-edid. Just one more thing, what is a correct way now to override modeline? I have two monitors (built-in and external), so I need a way to override one of them.
Disregard the last question, I'm just confused. Added modeline into xorg.conf, everything works. Thanks!
Sorry, I'm reopening this bug. EDID reports "-HSync +VSync" (attaching get-edid output), while xrandr reports "+HSync -VSync". If I manually create a modeline from EDID report, everything is crisp, as expected.
Created attachment 38874 [details] get-edid | parse-edid
Created attachment 38875 [details] a new xorg.conf
Created attachment 38876 [details] new xrandr --verbose
Now, that is interesting! Thanks for digging deeper.
Can you attach the original edid, using /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DVI-1/edid ?
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 5881fad..e2e11d7 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -53,8 +53,8 @@ struct std_timing { u8 vfreq_aspect; } __attribute__((packed)); -#define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1) -#define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2) +#define DRM_EDID_PT_HSYNC_POSITIVE (1 << 2) +#define DRM_EDID_PT_VSYNC_POSITIVE (1 << 1) #define DRM_EDID_PT_SEPARATE_SYNC (3 << 3) #define DRM_EDID_PT_STEREO (1 << 5) #define DRM_EDID_PT_INTERLACED (1 << 7)
My references (wikipedia, the shame) tell me the kernel/parse-edid (Adam Jackson) is right, and read-edid is incorrect.
14:49 < ajax> the edid spec says: byte 17 of the detailed timing byte defines sync features 14:50 < ajax> digital sync is indicated by bit 4 (ie, 1 << 4) being set. 14:50 < ajax> if digital, bit 3 indicates digital separate sync. 14:51 < ajax> if separate sync, bit 2 means vsync positive and bit 1 means hsync positive * proof by authority.
Created attachment 38878 [details] cat /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DVI-D-1/edid
Chris, I'm sorry for being slow. First, you commited a change and then said that kernel is right. :) So, will you commit this fix or not? By spec at wikipedia, by EDID reads "-HSync +VSync", so the fix seems to be correct.
> By spec at wikipedia, by EDID reads ... _my_
(In reply to comment #27) > Chris, I'm sorry for being slow. > First, you commited a change and then said that kernel is right. :) So, will > you commit this fix or not? > By spec at wikipedia, by EDID reads "-HSync +VSync", so the fix seems to be > correct. Sorry, you are right, "+H -V".
I was suggesting that patch to bring the kernel into line with read-edid. But the kernel does match the EDID spec, so the bug does not seem to be in the interpretation of the flags. Only recently did the driver actually honour the sync flags (hence the change in behaviour) and I've just rechecked our programming of the registers against the specs. Hence why at the moment I think the fault lies in the EDID rather than the code...
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.