<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - resolution 1040x1050 not supported on Thinkpad R52 with ATI Radeon Mobility X300 (M22) 5460 (PCIE)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91401#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - resolution 1040x1050 not supported on Thinkpad R52 with ATI Radeon Mobility X300 (M22) 5460 (PCIE)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91401">bug 91401</a>
from <span class="vcard"><a class="email" href="mailto:iordanov@gmx.de" title="Ognjan Iordanov <iordanov@gmx.de>"> <span class="fn">Ognjan Iordanov</span></a>
</span></b>
<pre>(In reply to Alex Deucher from <a href="show_bug.cgi?id=91401#c6">comment #6</a>)
<span class="quote">> Any chance you could bisect?</span >
After bisect I've found this:
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[dafffda023b04f87e695dfcf5448e4da964d2e95] drm/info: Remove unused code
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[abc0b1447d4974963548777a5ba4a4457c82c426] drm: Perform basic sanity checks on
probed modes
Bisecting: 0 revisions left to test after this (roughly 1 step)
[05acaec334fcc1132d1e48c5042e044651e0b75b] drm: Reorganize probed mode
validation
abc0b1447d4974963548777a5ba4a4457c82c426 is the first bad commit
commit abc0b1447d4974963548777a5ba4a4457c82c426
Author: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>>
Date: Wed Dec 17 13:56:23 2014 +0200
drm: Perform basic sanity checks on probed modes
Make sure the timings of probed modes at least pass some very basic
sanity checks.
The checks include:
- clock,hdisplay,vdisplay are non zero
- sync pulse fits within the blanking period
- htotal,vtotal are big enough
I have not checked all the drivers to see if the modes the generate
might violate these constraints. I'm hoping not, because that would mean
either abandoning the idea of doing this from the core code, or fixing
the drivers.
I'm not entirely sure about limiting the sync pulse to the blanking
period. Intel hardware doesn't support such things, but some other
hardware might. However at least HDMI doesn't allow having sync pulse
edges within the active period, so I'm thinking the check is probably
OK to have in the common code.
Signed-off-by: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>>
Reviewed-by: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>>
Signed-off-by: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>>
:040000 040000 ff2bab0e9a547755015e7b01560baf3605acd877
46c30fe9db7cb878d967cfaafc98cc2af9a152c9 Mdrivers
:040000 040000 af6a775d10e6af6e31efd465f9eb15e61532b0c9
fadb2a79569c8ceb25af9ea4d0944630d444cf19 Minclude</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>