Red Hat Bugzilla – Bug 229394
system-config-display stumbles when configuring "wide" displays.
Last modified: 2018-04-11 06:31:35 EDT
Description of problem:
I just got an opportunity to try with Samsung SyncMaster 244T.
This is 1920x1200 the current model LCD.
After X is started then the following shows up, among other things
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 154.0 MHz Image Size: 518 x 324 mm
(II) RADEON(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2080
(II) RADEON(0): v_active: 1200 v_sync: 1203 v_sync_end 1209 v_blanking: 1235
(II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz,
PixClock max 170 MHz
One option is to try to use "Generic LCD 1920x1200". Such option
is offered but the highest available resolution offered is,
surprisingly enough, "1600x1200". If one will accept that then
HorizSync and VertRefresh values written in a "Monitor" section
are not really correct but reasonable enough and in "Screen"
section shows up a long "Modes" line starting with "1600x1200"
and no "1920x1200" anywhere in sight.
The above clearly does not provide correctly configured display.
OTOH after "1920x1200" is added in front of "Modes" then this
works as expected.
Another configuration possibility in system-config-display is to
try Samsung SyncMaster 243T. Not entirely correct but close enough.
That does not write any "Modes" lines at all even if the highest
possible offered by s-c-d resolution, which happens to be 1680x1050,
is picked up. After starting X with that configuration one can
notice 1920x1200 on xrandr list but a display is in 1600x1200
with 1920x1200 serving as "virtual". xrandr will switch to a
correct resolution when asked. Also adding
in xorg.conf has a desired effect. An xrandr produced list does
not change but a mode used by default does.
BTW - 1680x1050 which showed up in s-c-d is not on that list at all.
Interestingly enough if instead of adding "Modes" like the above
one will copy from /var/log/Xorg.0.log to "Monitor" section a correpsponding
modeline then a display is again correct and xrandr produced list
is much longer now, while totally different, and with "right proportion"
entries like "960 x 600". That modeline happens to be:
Modeline "1920x1200" 154.00 1920 1968 2000 2080
1200 1203 1209 1235 +hsync -vsync
Version-Release number of selected component (if applicable):
Since this bugzilla report was filed, there have been several major updates,
which may have resolved this issue. Users who have experienced this problem are
encouraged to upgrade their system to the latest version of their distribution
Please, if you experience this problem on the up-to-date system, let us now in
the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as
INSUFFICIENT_DATA. Thank you.
> Since this bugzilla report was filed, there have been several
> major updates, which may have resolved this issue.
The catch is that currently I do not have a monitor with such
display proportions not mentioning 1920x1200 "native". When
I will stumble upon such beast then I can retry.
Wonderful, then although I have to close this bug as INSUFFICIENT_DATA, please,
reopen when you get your hands on that monitor again.