All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 48880] Set mode has different timings than requested on VGA
Date: Thu, 19 Apr 2012 14:01:10 +0000	[thread overview]
Message-ID: <bug-48880-502-bpBDJSmbB8@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-48880-502@http.bugs.freedesktop.org/>

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #18 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 07:01:10 PDT ---
(In reply to comment #15)
> 
> Err, Alex, i think that it is the display engine, for a particular version and
> process, that has issues with certain divider combinations which should
> theoretically produce the same pixel clock, not the monitor.

I'm not so sure about that.  If I use the same divider combination on my
monitors, it works fine (both TMDS and analog).  It even works fine for Tvrtko
over TMDS.  It's possible the that due to a cable problem or a bad solder
inside that the pixel clock that eventually gets to the screen is in some cases
is too low and boosting the pixel clock slightly compensates for that.


(In reply to comment #16)
> 
> I don't take that as granted because monitor was reporting 175.9MHz in the
> broken case. You haven't said anything about that observation? Do you believe
> monitor is wrong there? Even though it correctly reports with other modes?
> 

I don't know why the monitor is reporting that or how the monitor calculates
the clock it's getting.  It could be something funky with the VGA cable you are
using or a loose connection on the VGA chain somewhere.  The exact same divider
combination works fine on DVI and on other monitors.


> > I'd be leery of changing the pll flags without a lot of thorough testing since
> > these change may break certain modes on other monitors.  Did you try
> > RADEON_PLL_USE_FRAC_FB_DIV?  It should help the driver get closer to the actual
> > pixel clock by allowing a finer grained fb divider, but once again, some
> > monitors are picky about certain divider combinations.  I'd be more inclined to
> > add this flag than the MINM_OVER_MAXP flag however.
> 
> I haven't tried RADEON_PLL_USE_FRAC_FB_DIV yet, but will now. What are the
> downsides of that one? I suppose there must be some since it is not enabled by
> default...

Once again, some monitors don't like the clock produced.  It took years of fine
tuning to get a pll algo that produces good results on a wide range of
monitors.  these options may fix this mode on your monitor, but they may also
break a bunch of modes on other monitors.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

  parent reply	other threads:[~2012-04-19 14:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 14:57 [Bug 48880] New: Set mode has different timings than requested on VGA bugzilla-daemon
2012-04-18 15:07 ` [Bug 48880] " bugzilla-daemon
2012-04-18 15:08 ` bugzilla-daemon
2012-04-18 15:18 ` bugzilla-daemon
2012-04-18 15:25 ` bugzilla-daemon
2012-04-18 15:25 ` bugzilla-daemon
2012-04-18 15:34 ` bugzilla-daemon
2012-04-18 15:38 ` bugzilla-daemon
2012-04-18 15:44 ` bugzilla-daemon
2012-04-18 19:04 ` bugzilla-daemon
2012-04-18 19:22 ` bugzilla-daemon
2012-04-19  1:47 ` bugzilla-daemon
2012-04-19  6:45 ` bugzilla-daemon
2012-04-19  7:51 ` bugzilla-daemon
2012-04-19 10:29 ` bugzilla-daemon
2012-04-19 13:37 ` bugzilla-daemon
2012-04-19 13:45 ` bugzilla-daemon
2012-04-19 13:59 ` bugzilla-daemon
2012-04-19 14:01 ` bugzilla-daemon [this message]
2012-04-19 14:02 ` bugzilla-daemon
2012-04-19 14:09 ` bugzilla-daemon
2012-04-19 14:20 ` bugzilla-daemon
2012-04-19 14:47 ` bugzilla-daemon
2012-04-19 15:15 ` bugzilla-daemon
2012-04-19 15:20 ` bugzilla-daemon
2012-04-20 10:01 ` bugzilla-daemon
2012-04-20 10:45 ` bugzilla-daemon
2012-04-30  9:53 ` bugzilla-daemon
2012-04-30 12:44 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-48880-502-bpBDJSmbB8@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.