Created attachment 67492 [details] G45 xorg log I'm using the following sw versions: intel driver 2.20.8 xorg-server 1.12.2 libdrm 2.4.33 kernel 3.3.8 I cannot get EDID mode from two different monitors (Acer x223w and Asus VH222), using an Intel G45 video chipset. I didn't have this problem with previous sw version (intel driver 2.9.1 / xorg-server 1.7.7-r2/ libdrm 2.4.20-r1 / kernel 2.6.32). I got correctly EDID mode from the same monitors using the same sw versions above, on a different hw (Sandy Bridge based), so I think there is a specific regression on G45 chipset. I made some debugging on sna_output_attach_edid in sna_display.c code and I obtained (errno: Invalid argument) on call to function: drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPBLOB, &blob) I also had the same behaviour using UXA acceleration instead of SNA, in that case the function that is called is intel_output_attach_edid inside intel_display.c. I attach Xorg.0.log.
Right, that just means that there is no EDID assosicated with the connector. So the query goes to the kernel as to why it is not successfully retrieving the EDID. Can you post your dmesg and also if you still have it available, the xrandr and dmesg from the working kernel?
Created attachment 67500 [details] Sandy Bridge Xorg log
Created attachment 67501 [details] G45 dmesg
Created attachment 67502 [details] Sandy bridge dmesg
Created attachment 67503 [details] Sandy bridge xrandr
Ok, I was expecting to see a warning in the G45 dmesg. I was wrong. Can you please append drm.debug=6 to your kernel command line and attach the resulting dmesg after booting the G45?
Most likely fixed with commit f1a2f5b7c5f0941d23eef0a095c0b99bf8d051e6 Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Aug 13 13:22:35 2012 +0300 drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads Can you please try the latest 3.6-rc kernel?
Created attachment 67504 [details] G45 dmesg with drm.debug=6
(In reply to comment #7) > Most likely fixed with > > commit f1a2f5b7c5f0941d23eef0a095c0b99bf8d051e6 > Author: Jani Nikula <jani.nikula@intel.com> > Date: Mon Aug 13 13:22:35 2012 +0300 > > drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads > > Can you please try the latest 3.6-rc kernel? I tried 3.6_rc6 kernel, but I have the same behaviour. I attach dmesg (dri.debug=6) and Xorg.log.
Created attachment 67508 [details] G45 dmesg (kernel 3.6_rc6) with dri.debug=6
Created attachment 67509 [details] G45 xorg log (kernel 3.6_rc6)
Hm, it looks like we just can't read the edid. Two things to try: - Can you please test the gmbus-irq git branch from http://cgit.freedesktop.org/~danvet/drm - Can you please use the read-edid to check whether the edid can be read from a different i2c bus (sometimes oems wire things up the wrong way round). Also, what kind of outputs does your machine (physically) have?
(In reply to comment #12) > Hm, it looks like we just can't read the edid. Two things to try: > > - Can you please test the gmbus-irq git branch from > http://cgit.freedesktop.org/~danvet/drm > > - Can you please use the read-edid to check whether the edid can be read > from a different i2c bus (sometimes oems wire things up the wrong way round). > > Also, what kind of outputs does your machine (physically) have? I tested the same behaviour even with gmbus-irq git branch kernel. I attach Xorg.0.log e dmesg (drm.debug=6). I also attach get-edid output. The G45 chipset motherboard I'm using is an Intel DG45FC with onboard DVI-I and HDMI display ports. I dont' think that it has hardware issues, because I tested just this DG45FC motherboard, with older software versions (intel driver 2.9.1 / xorg-server 1.7.7-r2/ libdrm 2.4.20-r1 / kernel 2.6.32) reading correctly EDID data from the same display.
Created attachment 67615 [details] G45 xorg log (kernel gmbus-irq)
Created attachment 67616 [details] G45 dmesg (kernel gmbus-irq drm-debug=6)
Created attachment 67617 [details] G45 get-edid output
Random link: http://www.polypux.org/projects/read-edid/read-edid-i2c.tar.gz
(In reply to comment #17) > Random link: http://www.polypux.org/projects/read-edid/read-edid-i2c.tar.gz Thanks Chris. Marco, can you please re-run the edid reading with this tool, the previous one uses the wrong interfaces (sorry for the confusion, I'm currently travelling around and don't have my usual setup with me ...)?
(In reply to comment #18) > (In reply to comment #17) > > Random link: http://www.polypux.org/projects/read-edid/read-edid-i2c.tar.gz > > Thanks Chris. Marco, can you please re-run the edid reading with this tool, > the previous one uses the wrong interfaces (sorry for the confusion, I'm > currently travelling around and don't have my usual setup with me ...)? Ok, this is the output I get testing with the right command (read-edid-i2c): "Looks like no busses have an EDID. Sorry!"
Created attachment 67689 [details] [review] disable gmbus Can you please try this patch quickly (also with the read-edid-i2c too) please?
(In reply to comment #20) > Created attachment 67689 [details] [review] [review] > disable gmbus > > Can you please try this patch quickly (also with the read-edid-i2c too) > please? I tried it but I get the same message: "Looks like no busses have an EDID. Sorry!"
This is very strange, somehow we don't seem to be able to get at the right ddc bus to read the edid of your screen at all. Which is the first time I've ever seen this. I suspect your old setup still uses ums, which iirc uses the vbios to do edid readings. If you can dig out Xorg.log of the old working setup, that would be interesting (if just to confirm my theory). Also, is there any other gpu in your system or is there anything other special (all-in-one machine?) that could explain why your machine has a really unusual ddc setup?
(In reply to comment #22) > This is very strange, somehow we don't seem to be able to get at the right > ddc bus to read the edid of your screen at all. Which is the first time I've > ever seen this. I suspect your old setup still uses ums, which iirc uses the > vbios to do edid readings. If you can dig out Xorg.log of the old working > setup, that would be interesting (if just to confirm my theory). > > Also, is there any other gpu in your system or is there anything other > special (all-in-one machine?) that could explain why your machine has a > really unusual ddc setup? You're right, finally I found that using the adaptor DVI-I --> VGA (I tried 3 different adaptors all with all DVI-I pins and anyway I used it in all of these tests), causes the kernel not to get EDID data in this particular software/hardware case. Changing the adaptor/cable with a DVI cable, allow kernel to correctly read EDID data. I can see it from the Xorg.0.log and of course display resolution (if I use in this case the read-edid command you link me, I get anyway the same error message: "Looks like no busses have an EDID. Sorry!"). It's strange because using the same adaptor/cable/monitor with the same motherboard (Intel DG45FC) and the previuos software releases I get correctly EDID data. I attach the Xorg.0.log (kernel 2.6.32-r20) And it's also strange that using the same adaptor/cable/monitor with a new motherboard, also equipped with DVI-I port connector (Intel DH77DF with a Sandy Bridge CPU) and the current software releases, I get EDID data without any problem. Do you think there is no software issue even if restricted to the adaptor DVI-I VGA usage on G45 chipset?
Created attachment 67709 [details] G45 xorg log (kernel 2.6.32-r20)
On Wed, Sep 26, 2012 at 9:50 AM, <bugzilla-daemon@freedesktop.org> wrote: > Do you think there is no software issue even if restricted to the adaptor > DVI-I VGA usage on G45 chipset? Yeah, it looks like the edid is on another line pair than what the driver expects. And the tool doesn't seem to work. I'll look into this again once I'm back home next week, currently travelling.
*poke*
Hm, this bug was idling for a long time. Can you please retest on latest bits to check whether your issue still exists?
(In reply to comment #27) > Hm, this bug was idling for a long time. Can you please retest on latest > bits to check whether your issue still exists? Yes, you're right, I tested on kernel 3.8.13 + driver Intel 2.20.13 and it works correctly.
Cool. Thanks for reporting back and please reopen (or file a new bug) if something breaks again.
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.