MacMini with 1080p is working

[billyx at gmx.at]

Hello!

The good news:

After many hours of work it is running: My MacMini (CoreDuo with i945gm) at
a Xoro 3742w with 1080p (1920 x 1080 @ 60 Hz). There are no special settings
in xorg.conf necessary.

The bad news:

All settings has to be hardcoded into the source of xorg-server and
xorg-video-intel. (Have I already mentioned that xorg is crap?)

Some points:

* Why the hell is the 1080p not in extamodes? Is this not a standard?

Modeline "1920x1080" 148.5 1920 1960 2016 2200 1080 1082 1088 1125 -hsync
+vsync Is working for me, is listed at
http://www.mythtv.org/wiki/index.php/Modeline_Database
<http://www.mythtv.org/wiki/index.php/Modeline_Database>  ATSC Standard
Modes

* In xf86Crtc are some interesing options e.g. "PreferredMode" defined, but
they are not documented yet.

* Modes configured in xorg.conf seems are ignored completely.

* The display mode choosen depends on the calculated dpi of the modes
(happens in xf86DefaultMode)!!!! The mode nearest to 96dpi is choosen. Much
more debug output in xf86DefaultMode is neccesary. 

* Why do i get this in xf86InitialConfiguration before setting the
target_mode:

(II) intel(0): Target Mode: 1920x1080 (real size 708x398, enabled 0,
hasPrefered 0)

(II) intel(0): Target Mode: 1920x1080 (real size 0x0, enabled 1, hasPrefered
1) I have only one screen and it is on pipe A The log statement:

/*

* Let outputs with preferred modes drive screen size

*/

for (o = 0; o < config->num_output; o++)

{

xf86OutputPtr output = config->output[o];

xf86DrvMsg(0, X_INFO, "Target Mode: %dx%d (real size %dx%d, enabled %d,
hasPrefered %d)\n", width, height, output->mm_width, output->mm_height,
enabled[o], xf86OutputHasPreferredMode (output, width, height));

 

 

* What happend to my DisplaySize defined in xorg.conf??? It seems to be sent
to /dev/null. Instead for calculating the dpi the size reported by EDID and
lost/replaced by 0 and finally set to the default of 203mm is used to
calculate the dpi and choose the resolution. What a wunderful solution!

* xf86PruneInvalidModes gives to less information. Suggestion for a patch: 

if (verbose)

xf86DrvMsg(pScrn->scrnIndex, X_INFO,

"Not using %smode \"%s\"(%3.1f Hz %3.1f kHz %d Clock, %s)\n", type,
mode->name, xf86ModeVRefresh(mode), xf86ModeHSync(mode), mode->Clock,

xf86ModeStatusToString(mode->status));

else 

xf86DrvMsg(pScrn->scrnIndex, X_INFO,

"Not using %smode \"%s\"(%s)\n", type, mode->name,

xf86ModeStatusToString(mode->status)); 

 

* Why are the HorizSync and VertRefresh configured in xorg.conf missing in
xf86ProbeOutputModes? At a earlier point xf86DDCMonitorSet I get the output:

Using hsync ranges from config file

Using vrefresh ranges from config file

In xf86ProbeOutputModes the hsync and vrefresh are set to default values.

* There is the need for mor debug output in xf86ProbeOutputModes. I suggest
this before the xf86ValidateModesSync-calls:

if(config->debug_modes) {

int i;

for (i = 0; i < mon_rec.nVrefresh; i++) {

xf86DrvMsg(scrn->scrnIndex, X_INFO, "VRefresh-Range %3.1f-%3.1f Hz\n",
mon_rec.vrefresh[i].lo, mon_rec.vrefresh[i].hi);

}

for (i = 0; i < mon_rec.nHsync; i++) {

xf86DrvMsg(scrn->scrnIndex, X_INFO, "HSync-Range %3.1f-%3.1f kHz\n",
mon_rec.hsync[i].lo, mon_rec.hsync[i].hi);

} 

}

* in i830_crtc_mode_set it should be xf86PrintModeline(pScrn->scrnIndex,
adjusted_mode); instead of the 2nd xf86PrintModeline(pScrn->scrnIndex,
mode);

 

Cheers

Bernhard Mähr