[ANNOUNCE] xf86-video-intel-1.9.92

[Pavel Troller]

Hi Keith!
> On Sat, 2007-03-17 at 07:13 +0100, Pavel Troller wrote:
> 
> >   Now, the negatives:
> >   - EDID still doesn't work reliably. I think that in RC1, it didn't work at
> >     all, so maybe there is a progress. Now it sometimes works (at about 30% of
> >     invocations) and sometimes not (at the rest). It causes different results
> >     for subsequent tests. For example, I cannot reach 1600x1200 mode without
> >     EDID being read, even with HorizSync set to 20 - 100 (which is more than
> >     my monitor accepts), but it still writes "horizsync out of range". I'm
> >     really curious what frequency does the mode require but with the standard
> >     driver it works perfectly.
> 
> Note that the 'default' monitor in the configuration file is ignored;
> you must (at least for now) use the 'option "monitor-VGA" "My Monitor
> Section"' to point the driver's VGA output at your monitor definition.
> Yes, we should fix this.
I know this, I passed this point during RC1 testing. Even with that it doesn't
work well, see below.
> 
> In any case, please send along the log file showing the EDID data
> working and then failing during an xrandr operation.
Please see the attached files. They contain the two above logs and also my
current xorg.conf.
  I was wrong telling that 1600x1200 works with EDID. It's vice versa. It 
works WITHOUT it. Although all seems to be OK, it tosses the mode because of
hsync out of range. 
  BTW to get 1600x1200 at all, I have to specify PreferredMode option in the
monitor section. Without it, it offers 1152xsomething as the default, even with
virtual desktop set to 1600x1200 and equally with and without EDID. Why ?
> 
> >   - When EDID works and 1600x1200 mode is reached, Xserver gives incorrect info
> >     about the screen geometry. It lies that the physical dimensions are over
> >     430x350 mm, while they are 320x250 mm (and it is written in the Monitor
> >     section, as well as read from EDID). It also sets DPI to 96,96, while it
> >     should be 123,121. Due to this, apps are confused, fonts are too small
> >     while windows are too big etc.
> 
> Are you sure gdm isn't specifying -dpi on the command line for the
> server? You can check just using ps to see what the Xorg command line
> looks like.
Yes I am, because it works and presents correct DPI values with the old driver.
I always let the server to compute DPI from the resolution and display size.
In the log you can see the correct values for both the cases, but kinfocenter
shows totally different ones.
> 
> >   - When RandR is used to resize the screen to lower resolution (i.e.
> >     1200x1024), it works. However, it cannot return the 1600x1200 mode back.
> 
> Presumably EDID is failing the second time around. A log file would
> clarify this.
Exactly! I ran xrandr a lot of times now and it printed two kinds of output.
One contained the fine modes and the other didn't. I didn't know that EDID is
read everytime the resolution is to be changed, or even only dumped. I thought
that it's read only once at the server startup time.
> 
> One thing we're tempted to try is cranking up the I2C timeouts for the
> DDC line. Those are in the function DDCRead_DDC2 in
> xserver/hw/xfree86/ddc/xf86DDC.c. You might make all of these 10 times
> longer than they are now and see whether that works at all.
I've played with it...

A code snippet from this file:
        dev->DevName = "ddc2";
        dev->SlaveAddr = 0xA0;
        dev->ByteTimeout = 2200; /* VESA DDC spec 3 p. 43 (+10 %) */
        dev->StartTimeout = 550;
        dev->BitTimeout = 40;
        dev->ByteTimeout = 40;
        dev->AcknTimeout = 40;

Which of the two dev->ByteTimeout assignents is correct ? I tried to comment
out the second one (with the lower value) and also increased all the values
up to four times. It looked that it helps, but then it turned out to be 
probably influenced by my mental power :-); after a lot of experiments, a
good/bad ratio returned to the value approximately the same as in the 
beginning.

> 
> -- 
> keith.packard at intel.com

                  With regards, Pavel Troller
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorg.logs.tar.bz2
Type: application/x-tar-bz2
Size: 14286 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070317/f80dba6f/attachment.bin>