xf86-video-intel - enforce a given resolution on the DVI port? [success!]
Dag Bakke
dag at bakke.com
Mon Feb 5 10:08:23 PST 2007
On 02/05/2007 06:07 PM, Barry Scott wrote:
> Keith Packard wrote:
>>
>> You'll need to construct a modeline on your own then, and then link it
>> to the DVI output with another monitor section linked to the DVI-1
>> output (mode line below computed with the 'cvt' program):
>>
>> Section "Monitor"
>> Identifier "TV"
>> ModeLine "1366x768" 85.25 1368 1440 1576 1784 768 771 781 798
>> -hsync
>> +vsync
>>
> Did you mean to use 1368 for the h usable size?
> Can the intel chips be programmed with 1366 to match the panel? or do
> they have a x8
> restriction like the EDID spec?
Looks like a limitation with cvt, the tool used to generate the modeline.
My current modeline looks like this:
Modeline "1366x768R" 72.25 1366 1416 1448 1528 768 771 781 790
+hsync -vsync
cvt put '1368' after 72.25, I just modified it manually. The TV accepts
either one. (X reports 1368x768 or 1366x768)
And so I have the resolution I want:
mediapc at mediapc ~ $ xdpyinfo | grep dimen
dimensions: 1366x768 pixels (542x406 millimeters)
And all is well. Almost. Note the dimensions? As the GUI of the
application I use isn't made for 16:9 *and* appears to care for dpi, the
error makes it stretched out over the entire screen. A useful sideeffect.
Still, Xorg.0.log states:
(II) intel(0): Max H-Image Size [cm]: horiz.: 71 vert.: 40
but later:
(==) intel(0): DPI set to (75, 75)
If I enforce the dpi with
DisplaySize 701 396
in the relevant "Monitor" section, X comes up with :
dimensions: 1366x768 pixels (713x401 millimeters)
resolution: 49x49 dots per inch
which may be closer to the truth in my case. Now, *I* assume square
pixels on my TV, but who told X to do so? :-) EDID data perhaps?
So one could say that there are possibly two bugs lurking here:
1. the dpi appears hardcoded. X does certainly not make use of probed
information.
2. if a corrected DisplaySize is provided by the user, X fixes it up so
it matches the given resolution with square pixels.
If either of these are considered bugs, I'll be happy to stuff them into
bugzilla. Let me know.
I have attached my current xorg.conf and the resulting Xorg.0.log for
the benefit of those struggling with the same problem. Google tells me I
am not alone...
Keith: thanks!
Dag B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorg.conf.gz
Type: application/gzip
Size: 1002 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070205/678a3d9c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log.gz
Type: application/gzip
Size: 12388 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070205/678a3d9c/attachment-0001.bin>
More information about the xorg
mailing list