$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1968, maximum 2048 x 2048
VGA1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
   1920x1200      60.0*+
   1600x1200      60.0  
   1680x1050      60.0  
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
LVDS1 connected 1280x768+304+1200 (normal left inverted right x axis y axis) 264mm x 159mm
   1280x768       59.9*+
   800x600        60.3  
   640x480        59.9  
TV1 disconnected (normal left inverted right x axis y axis)

It will be great if you can try the patch in
https://bugs.freedesktop.org/show_bug.cgi?id=22761#C8 on the xserver and attach
the output of xorg.0.log.

Created attachment 29224 [details]
Xorg.0.log

This Bugzilla is dropping attachments! I had attached this logfile right away when I opened the bugreport.

(In reply to comment #3)
> Created an attachment (id=29224) [details]
> Xorg.0.log
> 
> This Bugzilla is dropping attachments! I had attached this logfile right away
> when I opened the bugreport.
> 

andreas, is the log with patch yakui mentioned in comment# 2 applied?

@Michael: Yes - is there anything that makes you think otherwise?

thanks for the test.
From the test log it seems that the mode 1024x768 is marked as invalid by the xserver as the hsync frequency is beyond the hsync/vsync range, which is calculated by the mode returned by the linux kernel. 

When the UMS mode is used, the mode 1280x800 obtained from EDID is invalid. But it is still used to calculate the hsync/vsync range. In such case the mode 1024x768@60Hz won't be removed. 

In the KMS mode the mode 1280x800@60HZ is already deleted from the kernel mode list. In such case we will get the hsync/vsync range different with that in UMS mode. In fact this flowchart in KMS mode is more reasonable.

IMO this bug is not our driver bug.

 

(In reply to comment #6)

> IMO this bug is not our driver bug.

This is a bit frustrating to me, as 1024 x 768 is an important mode on a 1280 x 768 display. Can you point me to where I have to report this bug? I thought the kernel parts of the driver are also hosted here?

(In reply to comment #7)
> (In reply to comment #6)
> 
> > IMO this bug is not our driver bug.
> 
> This is a bit frustrating to me, as 1024 x 768 is an important mode on a 1280 x
> 768 display. Can you point me to where I have to report this bug? I thought the
> kernel parts of the driver are also hosted here?
On this box there exists the EDID for LVDS display device. In such case the mode of 1280x768@60 is returned by kernel driver in KMS mode.

If you think that the mode 1024x768 is important on 1280x800, you can add it manually. Of course you can add the hsync/vsync refresh range in xorg.conf to workaround this issue.

If you think that the 1024x768 should be added automatically, you can report this bug to xserver.

Thanks.

> 

Moving this bug to xserver.

@ykzhao: Note that the display in question is a 1280 x 768 display, _not_ a 1280 x 800.

As 1024 x 768 is the native 4:3 mode on that display, I consider it very important and I feel it should not be needed to configure such an important mode manually.

I think this mode might be present now by default, but either way it sounds like a core DRM or server bug.

Should be fixed in newer intel driver.