diff options
author | Roland Mainz <roland.mainz@nrubsig.org> | 2004-12-16 01:58:57 +0000 |
---|---|---|
committer | Roland Mainz <roland.mainz@nrubsig.org> | 2004-12-16 01:58:57 +0000 |
commit | 44c77bf413b480ac00bbdb707d9f3d135224fc4b (patch) | |
tree | b2977293323bc1bc9bb0c7495da1304ead480bf1 /src/radeon.h | |
parent | c6eb3a7378c9e82e389196de6c38c96e99fd8db4 (diff) |
//bugs.freedesktop.org/show_bug.cgi?id=1306) attachment #1292
(https://bugs.freedesktop.org/attachment.cgi?id=1292):
This patch should work around the panel timing params not being
initialized. Here's the problem:
Previously, the PanelXRes and PanelYRes were either read from the BIOS or
were left as 0 (if no BIOS was detected). Then, in
RADEONUpdatePanelSize(), the max panel size was found and the timing
parameters were initialized, which worked fine for this ppc system.
Now, the PanelXRes and PanelYRes are either read from the BIOS or are read
from the registers. Note that the other timing parameters (in
particular the DotClock) are not initialized when reading from the
registers. Then, when RADEONUpdatePanelSize() is called, the max panel
size is already set, so none of the other timing parameters are
initialized here either (or anywhere else for that matter), which
appears to be why the new code fails for this ppc system.
The patch changes the test from < to <= in RADEONUpdatePanelSize() and then
tests to make sure that only the first set of timings for the panel
size read from the registers will be used -- this mimics the way the
previous code worked. The only problem with this code occurs when the
registers hold invalid panel size params, which do not match any of the
monitor's DDC info. This should never happen; however, if it does, then
the only solution in this case is to explicitly set the panel size in
the config file.
Patch by Kevin E. Martin <kem@freedesktop.org>
Diffstat (limited to 'src/radeon.h')
0 files changed, 0 insertions, 0 deletions