<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>