Bug 14101

please attach your Xorg log and config to this bug (using the latest driver).

Created attachment 13757 [details]
xorg.conf and Xorg.0.log tar file using xf86-video-i810-2.2.0-r1.ebuild

Here are the xorg.conf and Xorg.0.log files as requested.

Many thanks

Created attachment 13868 [details]
xorg.conf file from Duncan

Created attachment 13869 [details]
xorg log file from Duncan

we prefer plain text attachment... thanks.

Would you please use a default Xorg.conf file 
(or remove the following options in your Device section
 Option      "NoDDC"         "True"
   #Option      "ShowCache"     # [<bool>]
    Option      "XvMCSurfaces"  "7"
    Option      "PageFlip"      "True"
   #Option      "AccelMethod"   "EXA"
    Option      "AccelMethod"   "XAA"
    Option      "TripleBuffer"  "True" 
 also remove the fbdev device section)
and enable modedebug option in your device section, and attach the xorg.log?

Thanks,
Hong

Created attachment 13923 [details]
Xorg.0.log for 2.2.0-r1 driver

As requested the driver section has been updated to:

Section "Device"
    Identifier  "Card0"
    Driver      "i810"
    VendorName  "Intel Corporation"
    BoardName   "82915G/GV/910GL Integrated Graphics Controller"
    BusID       "PCI:0:2:0"
    Option      "modedebug"     "True"
EndSection

and the fbdev section has been removed.

barebone system...

Yes, a Shuttle XPC SB83G5M (SL8U4)

http://www.linuxowl.com/ffs.html has the hardware description. The os is now Gentoo.

Would you please attach the output of #xrandr --verbose?

What's your monitor model?

So you can't change to higher resolutions with xrandr? Is there any reaction from the monitor when you try a higher resolution (the monitor display a mess or just blank)?

Thanks,
Hong

Created attachment 14013 [details]
xrandr --verbose output

My monitor is a Sony GDM-F520 and it's physical screen is 400mm x 300mm

xrandr --output VGA --mode 1600x1200
works fine and the display is then 1600x1200, just what I want.

Screen 0: minimum 320 x 200, current 1152 x 768, maximum 2048 x 2048
VGA connected 1152x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   2048x1536      75.0     75.0     60.0  
   1920x1440      85.0     84.9     75.0     60.0  
   1856x1392      75.0     60.0  
   1792x1344      75.0     60.0  
   1600x1200      85.0     85.0     75.0     70.0     65.0     60.0  
   1680x1050      61.1  
   1600x1024      60.0  
   1400x1050      74.8     60.0  
   1280x1024      84.8     85.0     75.0     60.0  
   1280x960       85.0     74.9     60.0  
   1152x864       84.8     75.0  
   1152x768       54.8* 
   1024x768       84.9     85.0     75.1     75.0     70.1     60.0     43.5  
   832x624        74.6     74.5  
   800x600        84.9     85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     75.0     72.8     75.0     72.8     72.8     75.0     66.7     60.0     59.9  
   720x400        87.8     85.0     70.1  
   640x400        85.1  
   640x350        85.1

So the problem is at X startup, the initial mode selected is 1152x864 while you want it to be 1600x1200?

Our driver can't probe the EDID data from your monitor, so there is no info of this monitor for driver to select a suitable initial mode.

Would you please try your machine with other monitors to see if we can probe EDID data, to make sure that EDID data probe is working on your machine?
And another test, try your Sony monitor with other machines to see if EDID data from this monitor can be detected.
You can verify by seeing raw EDID data from xrandr --verbose.

For now, you can add
    Option "PreferredMode" "1600x1200" to the monitor section of your xorg.conf to specify the user preferred init mode for the monitor.

Thanks,
Hong

Created attachment 14042 [details]
Xorg.0.log Type BMM Debug

> So the problem is at X startup, the initial mode selected is 1152x864 while you
> want it to be 1600x1200?

Exactly,

> For now, you can add
>     Option "PreferredMode" "1600x1200" to the monitor section of your 
> xorg.conf to specify the user preferred init mode for the monitor.

This *doesn't* work, the display locks up and a reboot is required to reset the screen.

starting X and then running xrandr --output VGA --mode 1600x1200 works and has a rock steady flicker free display, much better than driver version 1.7.4.

> Our driver can't probe the EDID data from your monitor, so there is no info of
> this monitor for driver to select a suitable initial mode.

This is what read-edid-1.4.1 reports:

        # EDID version 1 revision 2
Section "Monitor"
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        Identifier "GDM-F520"
        VendorName "SNY"
        ModelName "GDM-F520"
        # Block type: 2:0 3:fd
        HorizSync 30-137
        VertRefresh 48-170
        # Max dot clock (video bandwidth) 370 MHz
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:ff
        # DPMS capabilities: Active off:yes  Suspend:no  Standby:no

        Mode    "1280x1024"     # vfreq 85.024Hz, hfreq 91.146kHz
                DotClock        157.500000
                HTimings        1280 1344 1504 1728
                VTimings        1024 1025 1028 1072
                Flags   "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:ff
EndSection

I've no idea where it is getting 1280x1024 from, it is neither 1600x1200 nor 1152x768, except that this is the VESA mode of the frame buffer.

> Would you please try your machine with other monitors to see if we can probe
> EDID data, to make sure that EDID data probe is working on your machine?

From a old LCD I get this, starting X cause the display to say it is out of range, 
Section "Monitor"
        # Block type: 2:0 3:fc
        Identifier "566"
        VendorName "BMM"
        ModelName "566"
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
        HorizSync 31-60
        VertRefresh 60-75
        # Max dot clock (video bandwidth) 80 MHz
        # Block type: 2:0 3:fe
        # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

        Mode    "1024x768"      # vfreq 75.029Hz, hfreq 60.023kHz
                DotClock        78.750000
                HTimings        1024 1040 1136 1312
                VTimings        768 769 772 800
        EndMode
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fe
EndSection

> And another test, try your Sony monitor with other machines to see if EDID 
> data from this monitor can be detected.

The Sony monitor works well on other machines, as it is attached through a KVM switch to four machines. I'm not sure it it reads the edid data correctly as normally I use modelines to tune the position of the display on the monitor. I have tried connecting the monitor directly to the Shuttle box but it makes no difference.

HTH
Duncan

(In reply to comment #12)

> 
> I've no idea where it is getting 1280x1024 from, it is neither 1600x1200 nor
> 1152x768, except that this is the VESA mode of the frame buffer.
> 
>

wait a minute. Duncan, do you have any fb kernel module loaded or compiled into your kernel? If yes, could you please remove it and re-test?

(In reply to comment #12)
> > For now, you can add
> >     Option "PreferredMode" "1600x1200" to the monitor section of your 
> > xorg.conf to specify the user preferred init mode for the monitor.
> 
> This *doesn't* work, the display locks up and a reboot is required to reset the
> screen.

It's weird. It seems the 1600x1200 X selects at startup is not the same with xrandr selects. Just a suggestion: you can check which 1600x1200 works (xrandr --verbose) and rename that mode to a unique name (f.e 1600x1200_OK) in xorg.conf and then prefer this mode.

With monitor2, our driver can get EDID data. Can you check our driver can get EDID data if directly connecting Sony with your machine?

From the data you get from read-edid, it seems even we can get edid data, the data is broken. So I am afraid you have to manually add working mode to make the monitor work.

Thanks,
Hong

Created attachment 14058 [details]
xrandr --verbose output direct connection

The good news is:

Booting without the frame buffer and a direct connection to the monitor reveal that the EDID data can be read, see attachment.

Starting X from the console it starts at 1280x1024

The "PreferredMode" "1600x1200" option also works and the screen initialised at 1600x1200.

The bad news is:
without the PreferredMode option X does not exit cleanly, the screen is blank and a reboot is required to get the console back.

with the PreferredMode option and running xrandr --verbose, X locks up completely. The X process is still running and taking all the CPU.

So far the best solution is using the frame buffer, starting X and then using xrandr to set the 1600x1200 mode.

Created attachment 14059 [details]
Xorg.log Type Sony Debug

(In reply to comment #15)
> Created an attachment (id=14058) [details]
> with the PreferredMode option and running xrandr --verbose, X locks up
> completely. The X process is still running and taking all the CPU.

This probably is a X server bug we already fixed, would you please try a newer X server version?

Thanks,
Hong

(In reply to comment #15)
> Created an attachment (id=14058) [details]
> xrandr --verbose output direct connection
> 
> The good news is:
> 
> Booting without the frame buffer and a direct connection to the monitor reveal
> that the EDID data can be read, see attachment.
> 

(In reply to comment #15)
> Created an attachment (id=14058) [details]
> xrandr --verbose output direct connection
> 
> The good news is:
> 
> Booting without the frame buffer and a direct connection to the monitor reveal
> that the EDID data can be read, see attachment.

Duncan，

We won't accept any "framebuffer driver coexist" bug. So far, this is a known issue. So, please obsolete your logs with framebuffer kernel module loaded. it only create confusing message.

Also please make sure the monitor is directly connected with the machine, rather than via a KVM switch.


> 
> Starting X from the console it starts at 1280x1024
> 
> The "PreferredMode" "1600x1200" option also works and the screen initialised at
> 1600x1200.
> 
> The bad news is:
> without the PreferredMode option X does not exit cleanly, the screen is blank
> and a reboot is required to get the console back.
> 
> with the PreferredMode option and running xrandr --verbose, X locks up
> completely. The X process is still running and taking all the CPU.
> 
> So far the best solution is using the frame buffer, starting X and then using
> xrandr to set the 1600x1200 mode.
> 

As Hong suggested, please try the git tip to see if this bug still exist. If it still bother you , please open a new bug specifically for this issue. thanks.

In order not to mess up the bug description, I'm going to mark this bug as NOTOURBUG.

> We won't accept any "framebuffer driver coexist" bug. So far, this is a known
> issue. So, please obsolete your logs with framebuffer kernel module loaded. it
> only create confusing message.

That's fair enough, if it is a known problem then it will get fixed one day. However, this is a small problem for me as I need both a framebuffer and an X for my Freevo development work.

> Also please make sure the monitor is directly connected with the machine,
> rather than via a KVM switch.

I have been trying the various things that you have suggested with the monitor directly connected. The driver still doesn't work as it should. With the BMM LCD it has a "out of range" message on the monitor and with the F520 I'm getting 1280x1024 which is too low for a 21" monitor.

> > with the PreferredMode option and running xrandr --verbose, X locks up
> > completely. The X process is still running and taking all the CPU.
> > 
> > So far the best solution is using the frame buffer, starting X and then 
> > using xrandr to set the 1600x1200 mode.
> > 
> 
> As Hong suggested, please try the git tip to see if this bug still exist. If
> it still bother you, please open a new bug specifically for this issue. 

I'm using the latest Xserver that Gentoo has an ebuild for, would you like me to try the latest server from the git repository, this wasn't clear from Hong's message.

I think that the real problem is that the driver is ignoring the mode lines in the xorg.conf. Which confuses things for a dumb user like me but I think that this is also a known problem. It would be good if the man page for the i810 driver had a big warning saying that the modes and mode lines are ignored.

> In order not to mess up the bug description, I'm going to mark this bug as
> NOTOURBUG.

It's only partly "Not our bug" in that the Xserver does not reset the console at exit. The ignoring of the modes in the screen->display and the modelines is a driver problem.

Would you like me to open a bug with a title "i810 driver ignores display modes and modelines"?

BTW the xorg log reports that it is not using certain modes because bad mode clock but it doesn't say which modes are not being used, eg I have a list of five modes for 1600x1200 that are not being used but no idea what the (bad mode clock/interlace/doublescan) are.

(In reply to comment #19)
> I have been trying the various things that you have suggested with the monitor
> directly connected. The driver still doesn't work as it should. With the BMM
> LCD it has a "out of range" message on the monitor and with the F520 I'm
> getting 1280x1024 which is too low for a 21" monitor. 

Please attach xorg log for these two monitors (with modedebug turned on).

> I'm using the latest Xserver that Gentoo has an ebuild for, would you like me
> to try the latest server from the git repository, this wasn't clear from Hong's
> message.
> 
> I think that the real problem is that the driver is ignoring the mode lines in
> the xorg.conf. Which confuses things for a dumb user like me but I think that
> this is also a known problem. It would be good if the man page for the i810
> driver had a big warning saying that the modes and mode lines are ignored.

X server will try to filter out unsupported modes. If you don't want certain modes not to be filtered out, you may need to enlarge the HorizSync/VertRresh for this mode (if the probed EDID data is not corrected).
 
> It's only partly "Not our bug" in that the Xserver does not reset the console
> at exit. The ignoring of the modes in the screen->display and the modelines is
> a driver problem.
> 

Can you switch console (Ctl+Alt+F1..) when X is active?
Would you please open a new bug for this problem?

> Would you like me to open a bug with a title "i810 driver ignores display modes
> and modelines"?
> 

No, you can workaround it with xorg.conf option as I said above. This should not be a bug.

> BTW the xorg log reports that it is not using certain modes because bad mode
> clock but it doesn't say which modes are not being used, eg I have a list of
> five modes for 1600x1200 that are not being used but no idea what the (bad mode

Usually it is because the clock of the mode > max pix clock, then the mode is filtered out. You can increase the max pix clock by adding
option "maxclock" "xxxMHz" to your monitor section.

Thanks,
Hong

Hi Hong,

(In reply to comment #20)
> (In reply to comment #19)
> > I have been trying the various things that you have suggested with the monitor
> > directly connected. The driver still doesn't work as it should. With the BMM
> > LCD it has a "out of range" message on the monitor and with the F520 I'm
> > getting 1280x1024 which is too low for a 21" monitor. 
> 
> Please attach xorg log for these two monitors (with modedebug turned on).

Already done, just renamed them so that it is clearer.

I did something stupid here I forgot to add a monitor section for the BMM monitor, I will test this again with the correct xorg.conf.

> > I'm using the latest Xserver that Gentoo has an ebuild for, would you like me
> > to try the latest server from the git repository, this wasn't clear from Hong's
> > message.
> > 
> > I think that the real problem is that the driver is ignoring the mode lines in
> > the xorg.conf. Which confuses things for a dumb user like me but I think that
> > this is also a known problem. It would be good if the man page for the i810
> > driver had a big warning saying that the modes and mode lines are ignored.
> 
> X server will try to filter out unsupported modes. If you don't want certain
> modes not to be filtered out, you may need to enlarge the HorizSync/VertRresh
> for this mode (if the probed EDID data is not corrected).

The values are correctly reported in the logs.

> > It's only partly "Not our bug" in that the Xserver does not reset the console
> > at exit. The ignoring of the modes in the screen->display and the modelines is
> > a driver problem.
> > 
> 
> Can you switch console (Ctl+Alt+F1..) when X is active?

Yes but nothing is displayed and the monitor switches off, Alt-F7 restores X

> Would you please open a new bug for this problem?

Will do

> > Would you like me to open a bug with a title "i810 driver ignores display modes
> > and modelines"?
> > 
> 
> No, you can workaround it with xorg.conf option as I said above. This should
> not be a bug.

IMHO If there are modes set-up in the xorg.conf they should override the defaults. The PreferredMode from the monitor section should be used first, then the modes from the screen section for the default depth. If these are *not* correctly configured for the driver then X should exit with a message. If they have not been specified then the EDID data should be used and if there is no EDID data available then some low resolution (800x600) should be used.

> > BTW the xorg log reports that it is not using certain modes because bad mode
> > clock but it doesn't say which modes are not being used, eg I have a list of
> > five modes for 1600x1200 that are not being used but no idea what the (bad mode
> 
> Usually it is because the clock of the mode > max pix clock, then the mode is
> filtered out. You can increase the max pix clock by adding
> option "maxclock" "xxxMHz" to your monitor section.

I get this, but I was wondering which were being filtered out, like for example 1600x1200@90Hz.

Added this anyway, it was correctly detected in the EDID section.

But just to sum up, the main problem is that when X exits the console does not recover. The second problem is that the modes are ignored in the xorg.conf and the last problem is that the driver doesn't work with a framebuffer.

I can workaround the last two problems with the PreferredMode or using xrandr. xrandr even works with the framebuffer running.

Cheers,
Duncan