Hello,
There're cases when EDID may be present, but be just severely (or seemingly) broken. Is it possible to completely and unconditionally ignore any EDID info for KMS, and instead use user-supplied parameters? I googled the following message: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg46741.html which suggested that it's possible, but I don't have any effect doing it myself.
It's also very hard to diagnose these issues. For example, mode selection is driven by EDID, but there're whole 0 occurances of that string in kernel dmesg. Passing drm.debug=1 starts to dump some internal registers, but still no hints which and why mode was selected.
My specific issue is that there's an LVDS (of MSI X410/X430 notebook) which has right dimensions and refresh rate, but wrong, if not say unrelated, clock settings. The end result is that there's tearing-off, broken sync like on an old dying TV. More details are at http://wwww.ubuntuforums.org/showthread.php?p=10120939 . That's on 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings on X which gave stable picture, but no luck persuading kernel to do the same (I used video=LVDS-1:1366x768M@60 param, also tried more conventional modes like 1024x768).
I'd appreciate any hints.
On Mon, Nov 22, 2010 at 11:02 PM, Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
There're cases when EDID may be present, but be just severely (or seemingly) broken. Is it possible to completely and unconditionally ignore any EDID info for KMS, and instead use user-supplied parameters? I googled the following message: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg46741.html which suggested that it's possible, but I don't have any effect doing it myself.
It's also very hard to diagnose these issues. For example, mode selection is driven by EDID, but there're whole 0 occurances of that string in kernel dmesg. Passing drm.debug=1 starts to dump some internal registers, but still no hints which and why mode was selected.
My specific issue is that there's an LVDS (of MSI X410/X430 notebook) which has right dimensions and refresh rate, but wrong, if not say unrelated, clock settings. The end result is that there's tearing-off, broken sync like on an old dying TV. More details are at http://wwww.ubuntuforums.org/showthread.php?p=10120939 . That's on 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings on X which gave stable picture, but no luck persuading kernel to do the same (I used video=LVDS-1:1366x768M@60 param, also tried more conventional modes like 1024x768).
I'd appreciate any hints.
Assuming your laptop contains a radeon, the panel timing comes from a table in the vbios. The timing problem is most likely not due to an EDID problem, but to pll dividers that that panel doesn't like. Try booting with radeon.new_pll=0 on the kernel command line or try kernel 2.6.37.
Alex
Hello,
On Tue, 23 Nov 2010 02:00:51 -0500 Alex Deucher alexdeucher@gmail.com wrote:
[]
My specific issue is that there's an LVDS (of MSI X410/X430 notebook) which has right dimensions and refresh rate, but wrong, if not say unrelated, clock settings. The end result is that there's tearing-off, broken sync like on an old dying TV. More details are at http://wwww.ubuntuforums.org/showthread.php?p=10120939 . That's on 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings on X which gave stable picture, but no luck persuading kernel to do the same (I used video=LVDS-1:1366x768M@60 param, also tried more conventional modes like 1024x768).
I'd appreciate any hints.
Assuming your laptop contains a radeon, the panel timing comes from a table in the vbios. The timing problem is most likely not due to an EDID problem, but to pll dividers that that panel doesn't like. Try booting with radeon.new_pll=0 on the kernel command line or try kernel 2.6.37.
Pure magic! ;-) Thanks for quick reply, that worked, even though I really thought that's a case of broken EDID, as X had the same behavior, which I could work around by setting CVT timing using xrandr (while nomodeset for kernel). Just for the info, that was for Radeon HD 3200, though the same issue was reported for Radeon X1250.
However, can you please elaborate about overring mode for KMS-based driver on the kernel command line? I studied kernel source more myself, and see that video= parsing for KMS is being performed by drm_fb_helper.c, and its routines seem to be called by the radeon driver. So, based on the code
DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n", drm_get_connector_name(connector), xres, yres, (refresh) ? refresh : 60, (rb) ? " reduced blanking" : "", (margins) ? " with margins" : "", (interlace) ? " interlaced" : "");
I set following kernel params:
drm.debug=7 video=LVDS-1:1366x768M@60
But expected output didn't appear in dmesg. I also tried "video=LVDS:1366x768M@60" with the same result. What could be wrong?
Alex
On Tue, Nov 23, 2010 at 3:38 PM, Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
On Tue, 23 Nov 2010 02:00:51 -0500 Alex Deucher alexdeucher@gmail.com wrote:
[]
My specific issue is that there's an LVDS (of MSI X410/X430 notebook) which has right dimensions and refresh rate, but wrong, if not say unrelated, clock settings. The end result is that there's tearing-off, broken sync like on an old dying TV. More details are at http://wwww.ubuntuforums.org/showthread.php?p=10120939 . That's on 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings on X which gave stable picture, but no luck persuading kernel to do the same (I used video=LVDS-1:1366x768M@60 param, also tried more conventional modes like 1024x768).
I'd appreciate any hints.
Assuming your laptop contains a radeon, the panel timing comes from a table in the vbios. The timing problem is most likely not due to an EDID problem, but to pll dividers that that panel doesn't like. Try booting with radeon.new_pll=0 on the kernel command line or try kernel 2.6.37.
Pure magic! ;-) Thanks for quick reply, that worked, even though I really thought that's a case of broken EDID, as X had the same behavior, which I could work around by setting CVT timing using xrandr (while nomodeset for kernel). Just for the info, that was for Radeon HD 3200, though the same issue was reported for Radeon X1250.
X using KMS and the console use the same code to set the mode. They both call into the radeon KMS drm. The modesetting paths in UMS are slightly different from KMS so likely a slightly different set of pll dividers was selected.
However, can you please elaborate about overring mode for KMS-based driver on the kernel command line? I studied kernel source more myself, and see that video= parsing for KMS is being performed by drm_fb_helper.c, and its routines seem to be called by the radeon driver. So, based on the code
DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n", drm_get_connector_name(connector), xres, yres, (refresh) ? refresh : 60, (rb) ? " reduced blanking" : "", (margins) ? " with margins" : "", (interlace) ? " interlaced" : "");
I set following kernel params:
drm.debug=7 video=LVDS-1:1366x768M@60
But expected output didn't appear in dmesg. I also tried "video=LVDS:1366x768M@60" with the same result. What could be wrong?
There's no way to override the panel mode on LVDS, the driver doesn't let you (same for UMS). The timing is too sensitive; the driver always uses the panel's native timing.
Alex
Alex
-- Best regards, Paul mailto:pmiscml@gmail.com
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Paul Sokolovsky