Created attachment 24702 [details]
output from xrandr --verbose
I'm attaching the output from xrandr --verbose. I tried doing `xrandr --output DVI1 --crtc 0` since I noticed in xrandr that the CRTC was 1 for both DVI1 and DVI2. However, this only made the DVI1 monitor go blank.
please tell your connection details: which display ports available on the board, and which ports you connected. The motherboard is a Gigabyte GA-EG45M-DS2H. It has three display ports: VGA, DVI, and HDMI. The DVI port and the HDMI port are each connected to a DVI monitor. I think Fedora 11 uses KMS. Fedora 11 indeed uses KMS. As I noted, I'm seeing this bug both with and without KMS. I found a workaround, which may help to show the actual cause of the problem. If I add the following lines to xorg.conf, then xrandr can correctly position the displays:
Section "Monitor"
Identifier "VGA1"
Option "Ignore" "true"
EndSection
This makes me think that the primary problem is that xrandr is reporting VGA1 as "connected" even though the VGA port is not actually connected.
the question is from driver's incorrect vga detection in kms, could you upload xog log file with modedebug option on in UMS? Thanks maling easiest way to verify is to grab a liveCD from distro that are using UMS to try on your machine, for example Ubuntu 9.04 beta... Created attachment 24790 [details]
Xorg.0.log with UMS and ModeDebug and without Ignore for VGA1
Created attachment 24791 [details]
Xorg.0.log with UMS and ModeDebug and with Ignore for VGA1
I have posted the requested information (xorg log file with modedebug option on in UMS) in two attachments: one with the Ignore option set for VGA1 and the other without. Note that VGA1 is incorrectly reported as connected in _both_ UMS and KMS. Thanks. By the way, if I am using UMS, the workaround (setting the Ignore option for VGA) does not work. Even though it stops VGA from appearing in the list of screens in xrandr, I still can't place the monitors at separate positions. the ignore workaround isn't in effect from the log for UMS - might because your xorg.conf isn't right. but the root cause should be the crt detection is wrong anyway... It sounds working with the driver shipped in F10. What's the version of the driver in F10? Are you able to help us do bi-sect using git? we don't have the exact HW.. Ling, we have a Gigabyte EG43M-SH which the closest to the bug reporter's environment. Pls ask Gordon. The Fedora 10 RPM containing the Intel driver is xorg-x11-drv-i810-2.5.0-4.fc10.i386, which is working. The first version I tested in Fedora 11 was xorg-x11-drv-intel-2.6.99.902-1.fc11, which was not working. I could probably try a few older Fedora 11 RPMs on Monday to help track down when the bug was introduced, but it might be a stretch to find time to do a git bisect (up to this point, I've been doing everything from RPMs). Anyway, I'll see what I can do. Thanks. Created attachment 25022 [details]
please try the patch on your machine in UMS, thanks
Hi Andrew,
According to spec the patch remove timeout option in detect function, please try it in UMS, then upload xorg.log with modedebug option on.
Thanks
maling
Created attachment 25050 [details] [review] please try the debug patch on your machine, thanks Ignore the attachment file 25022 in comments #15. Based on spec-"The CRT interrupt status bit #11 in the hot plug status register (61114) will get set the first time Force CRC detect trigger is used after reset. Software must reset status after a force CRT detect trigger." I did the patch, please try it on your machine. thanks maling I don't suppose there's an RPM with this, is there? I can roll my own, but it will take me a day or two. Thanks for working on this. Comment on attachment 25022 [details]
please try the patch on your machine in UMS, thanks
the patch is marked as obsolete
Created attachment 25066 [details]
Xorg.0.log with 21120_debug_v2.patch
I tried out the patch, but unfortunately the X server still seems to think that VGA is connected. I'm attaching the Xorg.0.log with ModeDebug enabled.
(In reply to comment #19) > Created an attachment (id=25066) [details] > Xorg.0.log with 21120_debug_v2.patch > > I tried out the patch, but unfortunately the X server still seems to think that > VGA is connected. I'm attaching the Xorg.0.log with ModeDebug enabled. > the patch is against UMS, but you were using KMS for testing from the log.. Ling, would you pls provide the KMS patch for Andrew to try? Or, andrew, could you pls test the UMS with the patch applied, and attach the xorg.log ( with modedebug on ) ? thanks. Created attachment 25078 [details]
Xorg.0.log with 21120_debug_v2.patch
I'm attaching an Xorg.0.log, this time with UMS.
we have another bug# 21210 which is also about a VGA detection failure on F11 beta. We've confirmed that it's doesn't exist in our latest code while indeed exist on the F11 beta. Are you able to get another distro ( liveCD ) to have a test as I suggested in comment# 8? In the mean time, Ling, would you pls test F11 beta on the Gigabyte EG43M-SH as I suggested in comment# 13? thanks. Created attachment 25170 [details] [review] please try the UMS patch on your machine, thanks. I tested our latest UMS driver on EG43M-SH only through DVI cable,but VGA always show connected. By the debug patch UMS driver can work normally for both DVI and HDMI, please try it on UMS mode. thanks maling (In reply to comment #24) > Created an attachment (id=25170) [details] > please try the UMS patch on your machine, thanks. > I tested our latest UMS driver on EG43M-SH only through DVI cable,but VGA > always show connected. By the debug patch UMS driver can work normally for both > DVI and HDMI, please try it on UMS mode. DVI and VGA :-) Does this make the previous patch obsolete? yes, please only try this one on your machine. thanks. Created attachment 25172 [details]
Xorg.0.log with the latest UMS patch
I applied the patch, and I'm posting the corresponding Xorg.0.log in UMS mode. It looks like that fixed it. Will there be a patch for KMS, too? Thanks.
Created attachment 25190 [details]
xrandr --verbose with the latest UMS patch
When I posted the feedback yesterday, I was connected into the machine remotely over ssh. Now that I've been here in person, I have a bit more information. When I run xrandr, it shows that VGA is disconnected (which is correct). However, it's still putting HDMI-1 and HDMI-2 on the same CRTC. This makes it impossible to do any dual-screen mode other than mirroring.
(In reply to comment #24) > Created an attachment (id=25170) [details] > please try the UMS patch on your machine, thanks. > > I tested our latest UMS driver on EG43M-SH only through DVI cable,but VGA > always show connected. By the debug patch UMS driver can work normally for both > DVI and HDMI, please try it on UMS mode. > > thanks > maling > Ling, are you able to try a F10 as Andrew to see if you can get the VGA detection correct?
> Ling, are you able to try a F10 as Andrew to see if you can get the VGA
> detection correct?
I tested with F10 in UMS, VGA is detected correctly-When I only connect HDMI monitor, it shows VGA and HDMI-2 are disconnected, HDMI-1 is connected. However in our latest master version, it shows VGA and HDMI-1 are connected. I will do bisect to try finding regression.
thanks
MaLing
Created attachment 25530 [details]
please try the debug patch on your machin in UMS mode. thanks
After comaring latest crt detect function with that of 2.5.0 ver, I found only one obvious difference, and I have tested the patch on my machine, it works now. please try the it on your machine, I will provide kms version soon.
thanks
Ma Ling
Created attachment 25531 [details]
please try the KMS version patch on your machine, thanks for your help.
The patch is for KMS version.
(In reply to comment #32) > Created an attachment (id=25530) [details] > please try the debug patch on your machin in UMS mode. thanks > > After comaring latest crt detect function with that of 2.5.0 ver, I found only > one obvious difference, and I have tested the patch on my machine, it works > now. please try the it on your machine, I will provide kms version soon. > > thanks > Ma Ling > could you pls do further debug print in the detection method to see which bit is causing this, with and without your patch? The hotplug_en &= ~CRT_HOTPLUG_MASK; looks decent... Created attachment 25535 [details]
please try the debug patch on your machin in UMS mode. thanks
This bit(CRT_HOTPLUG_ACTIVATION_PERIOD_64 (1 << 8)) is required by this platform to correctly detect vga, but from spect it is only useful for GM45 not for all G4x platforms.
I'm sorry--I'm a little confused by all of the different patches named very similar things (there are at least two named 21120_debug.patch, both of which are newer than the one called 21120_debug_v2.patch). The obsoleted UMS patch seems to be similar to the current KMS patch, but the current UMS patch is a different change. I'll plan on testing UMS, but which patch or patches should I try? (In reply to comment #36) > I'm sorry--I'm a little confused by all of the different patches named very > similar things (there are at least two named 21120_debug.patch, both of which > are newer than the one called 21120_debug_v2.patch). The obsoleted UMS patch > seems to be similar to the current KMS patch, but the current UMS patch is a > different change. I'll plan on testing UMS, but which patch or patches should > I try? hi Andrew McNabb please only try the UMS debug patch in comments #35, other patchs are obsoleted. Thanks Ma Ling (In reply to comment #35) > Created an attachment (id=25535) [details] > please try the debug patch on your machin in UMS mode. thanks > > This bit(CRT_HOTPLUG_ACTIVATION_PERIOD_64 (1 << 8)) is required by this > platform to correctly detect vga, but from spect it is only useful for GM45 not > for all G4x platforms. > sounds a reasonable spec problem. As one generation, it's likely they may share the same requirement of CRT_HOTPLUG_ACTIVATION_PERIOD_64 to be 1.. Could we verify this on other G4x we have to see if it will cause regression on them? If not, I think we may push the patch out. Created attachment 25591 [details]
Xorg.0.log with modedebug using the latest UMS patch
Created attachment 25592 [details]
xrandr.log with the latest UMS patch
This has the same effect as the previous UMS patch I tested. When I do xrandr --verbose, it correctly lists VGA as disconnected. However, it still puts HDMI-1 and HDMI-2 on the same CRTC, so they're forced into mirroring mode.
*** Bug 21712 has been marked as a duplicate of this bug. *** Pulled to 2.6.30: commit e92597cffffabe9a9a85db462045330970c498d0 Author: Ma Ling <ling.ma@intel.com> Date: Wed May 13 14:46:12 2009 +0800 drm/i915: Use the GM45 VGA hotplug workaround on G45 as well. Although spec say CRT_HOTPLUG_ACTIVATION_PERIOD_64 is only useful for mobile platform, it is also required to detect vga on G4x desktops correctly. Tested on G45/G43/Q45 platforms with no regressions. It fixed freedesktop.org bug #21120 and part of bug #21210 Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Sorry, I was out of the country and have been behind on things. I was wondering if the bug is really fixed. Since it's still putting HDMI-1 and HDMI-2 on the same CRTC, it seems like something is still thinking that VGA is connected. (In reply to comment #43) > Sorry, I was out of the country and have been behind on things. > I was wondering if the bug is really fixed. Since it's still putting HDMI-1 > and HDMI-2 on the same CRTC, it seems like something is still thinking that VGA > is connected. HDMI-1 and HDMI-2 share the same pipe, it is right when they are in clone state. If you hope to display different photo, please refer to --http://intellinuxgraphics.org/dualhead.html. thanks Ma Ling I think I'm miscommunicating what the problem is. I want to be able to do things like "xrandr --output HDMI-2 --right-of HDMI-1". In Fedora 10, this works. In Fedora 11 (and with the patches I have tested in association with this bug report), I get the strange behavior described in the original bug description. The only way I have been able to work around the bug is to add the following to xorg.conf:
Section "Monitor"
Identifier "VGA1"
Option "Ignore" "true"
EndSection
Section "Monitor"
Identifier "VGA"
Option "Ignore" "true"
EndSection
As I mentioned above in comment #1, when I don't do the above workaround, xrandr assumes that HDMI-1 and HDMI-2 (or DVI1 and DVI2) are on the same CRTC, even when it's not in mirroring mode. This is what makes me think that on some level the VGA connection is still incorrectly detected as connected.
copied from comment# 39 , after patch in comment# 42 applied... Both HDMI outputs are put in the same pipe. I think they shouldn't... (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output HDMI-1 is connected to pipe A (II) intel(0): Output HDMI-2 is connected to pipe A (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. track "both HDMI take one pipe issue"in bug# 22247 and close this one. |
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.
Created attachment 24701 [details] Xorg.0.log I've reported this on the Fedora bugzilla as bug #493457, but I'm reporting it here just to make sure it gets to the right people (there are 222 open Intel driver bugs in Fedora's bugzilla). Anyway, let me know if there's any other information I can provide in addition to this report: With Fedora 10, xrandr worked perfectly with Intel graphics. After reinstalling with Fedora 11 Beta (and also in Rawhide with xorg-x11-drv-intel-2.6.99.902-2.fc11.x86_64), xrandr stopped working correctly. It now fails to position monitors at different locations. Whenever one monitor is moved, the other moves, too. This problem happens both with and without KMS. When starting X, the two displays are in mirrored mode by default. When I specify "xrandr --output DVI2 --right-of DVI1", it puts both of the displays at the position 1920x0. Xrandr reports the resolution/position as "DVI1 connected 1920x1200+1920+0" and "DVI2 connected 1920x1200+1920+0". If I then do "xrandr --output DVI2 --left-of DVI1", then the resolution/position becomes "DVI1 connected 1920x1200+0+0" and "DVI2 connected 1920x1200+0+0". If I try to set the position manually, as in "xrandr --output DVI2 --pos 200x0", it moves both of the displays together, so that the new resolution/position is "DVI1 connected 1920x1200+200+0" and "DVI2 connected 1920x1200+200+0". It's probably not relevant, but I noticed that xrandr called the displays HDMI-1 and HDMI-2 in Fedora 10, but in Fedora 11 Beta they are now called DVI1 and DVI2.