Bug 493457 - xrandr with Intel graphics cannot put monitors at separate positions
xrandr with Intel graphics cannot put monitors at separate positions
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Jonathan Blandford
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-01 15:57 EDT by Andrew McNabb
Modified: 2013-04-02 00:22 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-06 15:45:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (219.01 KB, text/plain)
2009-04-01 15:57 EDT, Andrew McNabb
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 21120 None None None Never
FreeDesktop.org 22247 None None None Never

  None (edit)
Description Andrew McNabb 2009-04-01 15:57:39 EDT
Created attachment 337636 [details]

With Fedora 10, xrandr worked perfectly with Intel graphics.  After reinstalling with Fedora 11 Beta, xrandr stopped working correctly.  It now fails to position monitors at different locations.  Whenever one monitor is moved, the other moves, too.

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.  It may also be helpful to know that kernel modesetting is enabled in Fedora 11 Beta, but I was never able to enable it in Fedora 10.  I'm not sure if KMS is the culprit, but it might be relevant.

I am attaching my Xorg.0.log.  My xorg.conf is empty except for a snippet which sets DontZap to false.  Please let me know if any additional information would be helpful.
Comment 1 Andrew McNabb 2009-04-01 16:15:06 EDT
I've done a little more testing and have concluded that KMS isn't the culprit.  If I disable KMS, the displays get renamed from DVI1 and DVI2 to HDMI-1 and HDMI-2, and I have to add a "Virtual 3840 1200" directive to xorg.conf (as in Fedora 10).  However, xrandr still positions the two monitors at the same position, whether it's 0x0 or 1920x0.
Comment 2 Andrew McNabb 2009-04-10 17:23:07 EDT
I have installed a current version of Rawhide, which has xorg-x11-drv-intel-  The problem is still present in this newer driver.  Please let me know if there's any other information I can provide.  I have to switch back to Fedora 10 until this is fixed.  Thanks.
Comment 3 Zach Oglesby 2009-06-03 00:44:12 EDT
I am having the same issue, if I try to use xrandr nothing happens but if I log into gnome and use gnome-display-properties I can adjust my monitor.
Comment 4 Bug Zapper 2009-06-09 09:00:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 5 Andrew McNabb 2009-06-09 11:25:38 EDT
By the way, this is still a problem in Fedora 11 final.
Comment 6 Jehudi Castro Sierra 2009-06-15 09:43:21 EDT
it works for me on Fedora 11 final, just the name of the devices has changed so update your scripts, ie.  LVDS is now LVDS1 and DVI1 also used to have another name...

now works fine but it send some kernel oops: http://www.kerneloops.org/submitresult.php?number=452540
Comment 7 Andrew McNabb 2009-06-15 12:04:24 EDT
Jehudi, your problem must be different.  You should probably open a new bug report.
Comment 8 Andrew McNabb 2009-06-15 12:45:23 EDT
This bug has been split into two separate bugs upstream: 21120 and 22247.  Applying the fixes from both bug reports seems to solve the problem.  The fix from 21120 was committed in e92597cffffabe9a9a85db462045330970c498d0, and the fix from 22247 will presumably be committed today or tomorrow.
Comment 10 Matěj Cepl 2009-11-05 13:24:27 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 11 Andrew McNabb 2009-11-05 17:40:28 EST
This appears to be fixed in Fedora 12.

Note You need to log in before you can comment on or make changes to this bug.