For cases when EDID data doesn't work, monitors aren't connected at boot time, KVMs are used, etc, the Intel driver does not provide any method for specifying the standards 'NoDDC' or 'NoEDID' to specifically tell the driver what resolutions and modelines the attached screen supports. In my particular case, my monitor supports 1920x1080 @ 60Hz. GPU is listed as: 00:02.0 VGA compatible controller: 8086:a001 Intel Corporation Pineview Integrated Graphics Controller (rev 02) If I use VGA, EDID works, the monitor runs in 1920x1080. If I used the preferred HDMI connection, EDID returns nothing, and there is no way I can make the intel driver stop insisting that 1920x1080 exceeds my panel dimensions and just run the right resolution. It insists on 1366x768. I've specified panel size in xorg.conf, provided it specific horizsync, vertrefresh, modelines, option noedid, option noddc, etc, and nothing will convince it to just do as it's told. This would suggest a pretty serious bug to me.
Created attachment 57692 [details] /var/log/Xorg.0.log
Created attachment 57693 [details] /etc/X11/xorg.conf
I am having a similar problem after upgrading to Fedora 16 from Fedora 14. The first issue seems to be that 2 monitors are detected, LVDS1 and VGA1. These are desktop systems and only have a VGA port. The display is a TV monitor with incomplete EDID information. The display can and has run at 1360x768 quite successfully with Fedora 14. under Fedora 16, all attempts to ignore the EDID information appear to be ignored. Also, the EIDI information dump in the log appears to be missing. This is a great help when debugging these issues. I have attached the log file and the xorg.conf file.
Sorry, I should mention that the systems use the Intel N10 (Pineview) chip set.
commit da0df92b57311aa1b26a2a90599ed16e1e968b90 Author: Carsten Emde <C.Emde@osadl.org> Date: Sun Mar 18 22:37:33 2012 +0100 drm: allow loading an EDID as firmware to override broken monitor Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. This patch allows to specify an EDID data set to be used instead of probing the monitor for it. It contains built-in data sets of frequently used screen resolutions. In addition, a particular EDID data set may be provided in the /lib/firmware directory and loaded via the firmware interface. The name is passed to the kernel as module parameter of the drm_kms_helper module either when loaded options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel commandline parameter drm_kms_helper.edid_firmware=edid/1280x1024.bin It is also possible to restrict the usage of a specified EDID data set to a particular connector. This is done by prepending the name of the connector to the name of the EDID data set using the syntax edid_firmware=[<connector>:]<edid> such as, for example, edid_firmware=DVI-I-1:edid/1920x1080.bin in which case no other connector will be affected. The built-in data sets are Resolution Name -------------------------------- 1024x768 edid/1024x768.bin 1280x1024 edid/1280x1024.bin 1680x1050 edid/1680x1050.bin 1920x1080 edid/1920x1080.bin They are ignored, if a file with the same name is available in the /lib/firmware directory. The built-in EDID data sets are based on standard timings that may not apply to a particular monitor and even crash it. Ideally, EDID data of the connected monitor should be used. They may be obtained through the drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory of a correctly working graphics adapter. It is even possible to specify the name of an EDID data set on-the-fly via the /sys/module interface, e.g. echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware The new screen mode is considered when the related kernel function is called for the first time after the change. Such calls are made when the X server is started or when the display settings dialog is opened in an already running X server. Signed-off-by: Carsten Emde <C.Emde@osadl.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.