Commit graph

5 commits

Author SHA1 Message Date
Thomas Lübking
7e72aee474 return sane screen geometry on missing randr
may help in the xinerama case, follow up to
https://git.reviewboard.kde.org/r/125074/

REVIEW: 125456
2015-10-05 23:40:57 +02:00
Thomas Lübking
0302b97aea prevent calling xrandr w/o extension available
BUG: 343844
FIXED-IN: 5.5
REVIEW: 125074
2015-09-29 23:02:41 +02:00
Thomas Lübking
3597959c0e add Screens::name(int screen); STUB but for XRandr
required to compare __GL_SYNC_DISPLAY_DEVICE and
later on to assign windows to an output rather than
a screen number
2015-05-15 23:55:27 +02:00
Thomas Lübking
c7f13c7266 add refreshRate to Screens. STUB but for XRandr!
the randr refreshrate is calculated from the current mode
2015-05-15 23:55:27 +02:00
Martin Gräßlin
2eb876743c [screens] Replace DesktopWidgetScreens by XRandRScreens
A new implementation of the Screens interface is added which uses XRandR
directly instead of relying on QDesktopWidget. The implementation is
provided in a new implementation file screens_xrandr.cpp.

XRandRScreens comes with a unit test. Unfortunately it's rather difficult
to provide a proper unit test against XRandR. Xvfb (which is obviously
used on the CI system) doesn't provide the XRandR extension. Also on a
"normal" developer system one would not want to just execute the test as
the results are not predictable (number of available outputs?) and the
test would mess up the setup resulting in nobody wanting to execute the
test.

As a solution to both problems the unit test starts Xephyr as a nested
X server. This allows to have at least some limited tests against XRandR.
Nevertheless there are a few things which I was not able to test:
* multiple outputs
* no output at all

The nested X Server approach makes the interaction rather complex. Qt
opens it's connection against the main X Server thus QX11Info provides
a wrong connection and also KWin::connection() which is heavily used by
xcbutils and thus all the RandR wrappers have the wrong connection. To
circumvent this problem the test is GUILESS. In case it would call into
any code using QX11Info, it would probably either runtime fail or crash.

REVIEW: 117614
2014-11-27 09:00:19 +01:00