Bug 195272

Thanks for resubmitting the bug that got lost Tom.  Here's the second
comment from that bug, pulled from email...



------- Additional Comments From Tom.Horsley  2006-06-12 17:14 EST -------
I got this setup by adding the ModeLine:

ModeLine "1920x1080" 138.5 1920 1968 2000 2080 1080 1082 1087 1111

But I was totally bumfuzzled by the fact that I got all the parameters
from information the driver prints in the Xorg.0.log file which it obtains
from the monitor. If it gets everything it needs from the monitor, why
doesn't it take the microscopic additional step of just automagically
inculding that default native mode as an additional built-in
ModeLine to go with all the VESA ones it already has?

It's programs like this what cause unrest  :-) .

Add to FC6Destop tracker

Just added the following 1920x1080 CVT modes to the X server in the
1.1.1-12.fc6 build:

+# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
+Modeline "1920x1080"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync
+vsync
+
+# 1920x1080 69.92 Hz (CVT) hsync: 78.80 kHz; pclk: 204.25 MHz
+Modeline "1920x1080"  204.25  1920 2056 2256 2592  1080 1083 1088 1127 -hsync
+vsync
+
+# 1920x1080 74.91 Hz (CVT 2.07M9) hsync: 84.64 kHz; pclk: 220.75 MHz
+Modeline "1920x1080"  220.75  1920 2064 2264 2608  1080 1083 1088 1130 -hsync
+vsync
+
+# 1920x1080 84.88 Hz (CVT 2.07M9) hsync: 96.51 kHz; pclk: 253.25 MHz
+Modeline "1920x1080_85.00"  253.25  1920 2064 2272 2624  1080 1083 1088 1137
-hsync +vsync

One more thing, just FYI:

(In reply to comment #1)
> But I was totally bumfuzzled by the fact that I got all the parameters
> from information the driver prints in the Xorg.0.log file which it obtains
> from the monitor. If it gets everything it needs from the monitor, why
> doesn't it take the microscopic additional step of just automagically
> inculding that default native mode as an additional built-in
> ModeLine to go with all the VESA ones it already has?

There have been many people for years talking about improving the DDC
monitor detection, making the server internally generate VESA GTF
and/or CVT based modelines, and also having video modes provided via
EDID added to the mode pool.  You'd have to ask X.Org developers why
this is not yet being done in the X server, but their response will
probably be something akin to "nobody has written the code to make
it do that and submitted it as a patch to X.Org yet".

There have been some improvements made in 7.1 and since, but I don't
believe anyone has fully implemented dynamic CVT/GTF mode creation
yet.  The Red Hat rawhide X server does however contain EDID mode
injection, however I'm not sure how well tested it is.

Hope this helps shed some light...

I did find that with the radeon driver, I could turn on a DDC
option and I no longer had to specify the ModeLine, but I
still needed to add "1920x1080" to the list of modes for the
screen.

Don't know if the fglrx driver has a similar option or not.

(In reply to comment #5)
> I did find that with the radeon driver, I could turn on a DDC
> option and I no longer had to specify the ModeLine,

With rawhide X, that's expected I beleive, as the edid-mode-injection
patch is in rawhide.

> but I
> still needed to add "1920x1080" to the list of modes for the
> screen.

No matter what hardware you use, you always have to specify the mode(s)
you want in the screen section of the config file.

The modelines themselves only tell the X server how to program the hardware
for a given video mode, should that mode be needed.  The "Modes" line in the
screen section informs the X server which video modes you actually want to
use.  The first mode listed, is the default mode the server will use at
startup.  Any other modes, are available with the CTRL-ALT-(+/-) hotkey.

Our configuration tools preload the Modes list in the config file with
a number of standard modes.  You should rerun the config tool as:

system-config-display --reconfig

That generates a new config from scratch.  If the native mode of your
display is not in the config file as the first mode listed, file a bug
report against pyxf86config or system-config-display.


> Don't know if the fglrx driver has a similar option or not.

DDC is supported on most hardware by most drivers. Some are limited due
to VBE, while others directly use i2c to provide DDC.  I have no direct
knowledge of what the fglrx driver supports, but I'd be surprised if it
did not support i2c based DDC probing.