Bug 229394 - system-config-display stumbles when configuring "wide" displays.
Summary: system-config-display stumbles when configuring "wide" displays.
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-display
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-20 20:10 UTC by Michal Jaegermann
Modified: 2018-04-11 10:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-10-29 07:08:50 UTC
Type: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2007-02-20 20:10:59 UTC
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
in logs:

(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
h_border: 0
(II) RADEON(0): v_active: 1200  v_sync: 1203  v_sync_end 1209 v_blanking: 1235
v_border: 0
(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

                Modes "1920x1200"

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

Comment 1 Matěj Cepl 2007-09-12 00:34:30 UTC
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

Comment 2 Michal Jaegermann 2007-09-24 15:22:31 UTC
> 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.

Comment 3 Matěj Cepl 2007-10-29 07:08:50 UTC
Wonderful, then although I have to close this bug as INSUFFICIENT_DATA, please,
reopen when you get your hands on that monitor again.

Note You need to log in before you can comment on or make changes to this bug.