Red Hat Bugzilla – Bug 510142
gnome-display-properties handles geometry of rotated monitors inconsistently
Last modified: 2010-06-28 09:30:47 EDT
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090630 Fedora/3.5-1.fc11 Firefox/3.5
There are several bugs relating to gnome-display-properties and rotated monitors; I hope that clearing up this single bug may help to solve many others.
In "Drag the monitors to set their place", rotated monitors (portrait) appear rotated but in positioning them relative to another monitor are treated as though they have their unrotated geometry (landscape). and the images cannot be placed horizontally adjacent to another monitor.
This is *not* merely an issue with a graphical illustration! The result is an actual gap between the views, and objects can be lost in the gap between the screens, and windows that span the two monitors are only partly visible (in my case the gap is 50% the width of the "gnome-display-properties == Display Preferences" window.)
Furthermore the geometry errors give other difficulties in aligning the windows.
There seems to be some snap-to-grid action going on, and that grid seems informed by the wrong geometry. As a consequence it is easy to get an external monitor where the origin of the desktop is actually several cm into the monitor, and difficult to get things aligned in a reasonable way.
There are other problems which might be connected in some way with this inconsistency of rotated windows; see:
Bug 493069 - cursor isn't rotated in dualhead setup with one rotated and one normal display
Bug 510054 - Rotating external display crashes displays applet, can't rotate it back
Bug 510074 - rotated monitor display is offset
Bug 489923 - i965 multi-head rotating problem
Bug 494633 - gnome-display-properties: Rotation options for primary display are incorrect
Bug 474305 - gnome-display-properties does not expand desktop correctly when enabling second monitor with Intel 945 graphics
Steps to Reproduce:
1. Open gnome-display-properties.
2. Activate a second monitor.
3. Drag it around the first and notice how it snaps to be perfectly adjacent to the first monitor.
4. Now rotate the second monitor and notice how it behaves as though it wasn't rotated. Try to place the rotated second monitor immediately to the left of the first. Then move the properties window between the two monitors.
I am also experiencing this problem.
My setup is two rotatable 1600x1200 monitors. In portrait rotation (left) there is a horizontal space between the two monitors, both on the illustration and in "reality". As well, the monitors can then be placed on top of one another in the vertical direction (again both in the illustration and in reality).
I think that this bug is independent of the bugs above.
In my view this is a significant bug in the applet.
This appears to be fixed in the F12 RC as far as I can tell - I don't have an Intel 945 video setup.
I tried it out on a dual-screen machine (nvidia graphics card, nouveau driver). Everything appears to be working fine (almost!). Rotating the monitors allowed them to touch each other and the displayed geometry matched the actual geometry. The cursor also rotated correctly (although this may be particular to the graphics card / driver).
The only "glitch" is that initially side-by-side monitors don't touch on the display when one is rotated from horizontal to vertical, but moving one of them snaps them together. I don't view this as a significant problem, but it might be nicer to have the monitor snap together. The problem also works the other way - after a rotation to horizontal, one monitor may occlude part of the other. Both of these situations can result in artifacts in the actual display - accepting a separated or an occluded setup on the applet window results in separated or overlapped displays.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.