The test is flaky during the wait for Xephyr. Giving it more time should
hopefully make it more reliable.
The better way would be to switch to the command line argument
-displayfd pipeFd
unfortunately the Xephyr on the CI system does not yet support this
command line argument.
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
The new test does not cover ScreenEdges completely, so far the
following areas are handled:
* creating of the edges
* reserving of edges
* trigger callback
* cursor pushback
* blocking of edges for fullscreen active clients
The default was set that the grid size for one desktop is (1, 2)
which doesn't make any sense at all - it should be (1, 1).
This most likely only affects the unit test as in production the
default layout is taken fron NETRootInfo.
This is a very interesting auto test as Screens uses both Workspace
and Client. Thus it operates in the "impossible to mock" area.
The solution is to provide mock includes in autotests and ensure that
when building the auto-test the mock header includes will be picked
first. There is now a mock class for Workspace and Client providing
just the API pieces used inside Screens.
As Screens is abstract and we cannot properly interact with
QDesktopWidget there is also a MockScreens class inheriting from Screens
and mocking the required functionality (by just operating on a list of
QRects).
The auto-test itself is only performing checks on the abstract class.
The mock class is indirectly tested by Screens calling into the virtual
methods. The test case is not yet complete, but looking quite good
already.
So far the Seat interface is provided together with pointer and
keyboard. As always touch is not yet implemented. The pointer interface
is still lacking the set cursor callback. Keyboard on the other hand is
complete.
Both Keyboard and Pointer have the concept of a focused surface and only
to the bound interface belonging to the same client as the focused
surface events are sent.
The change comes with a set of new auto tests also verifying the client
side which wasn't possible before as we couldn't fake events.
ShellSurfaceInterface is not yet completely implemented. Several parts
are still TODO, e.g. move/resize is missing, setting to maximized is
missing and also flags for fullscreen are missing.
The surface test is extended as far as possible.
The Display provides a method to create the shm pool and a
BufferInterface class is added to the server module. It is created
from the SurfaceInterface when a buffer gets attached to the surface.
The BufferInterface can be referenced and once its unreferenced it
sends a buffer release to the client and destroys itself.
For the case that the buffer is a shm buffer the BufferInterface
provides a convenience method to turn it into a QImage.
The auto test for Surface is extended by attaching buffers to the
surface and verifying that the content is correct.
As far as it's currently possible to implement. CompositorInterface is
able to create a surface and emits the created SurfaceInterface. It
does not yet support regions.
The SurfaceInterface is already more complete. It keeps track of the
double buffered states and emits signals when one of the values are
changed after the committing. It supports frame callbacks and has a
hook to mark the frame as rendered.
What's still missing are the regions (as it's not implemented in
CompositorInterface) and attaching the buffer as we do not yet support
creating shm buffers and pools.
The client side test is changed to use our own server and extended to
test damage and frame callback. The test needs to be extended for scale
and transform, but that is still missing in the client side
implementation.
So far this new module contains:
* Display
* OutputInterface
Display manages the server socket and server event loop. In general it's
the entry point to any part of the server.
OutputInterface is the abstraction for the wl_output interface on server
side. An OutputInterface is created through the Display.
The auto tests for ConnectionThread and Output are adjusted to use the
internal server instead of starting Weston. Especially the Output test
could be extended to test much more as we have absolute control over
the server now.
Technically the Surface itself does not have a size, it's the
ShellSurface or the size of the FullScreenShell's Output. But it
simplifies a lot if we keep track of the size in the Surface as that
way we can hide the fact which kind of Shell is used.
The user of the Surface must connect either the FullscreenShell's
Output or the ShellSurface to set the size on the Surface.
The fullscreen shell is only provided with at least Weston 1.5.
It should be checked on runtime, but that's difficult as Weston doesn't
fail if it cannot find the shell.so. So we disable it based on the
assumption that if Wayland library is not 1.5 the Weston is also not 1.5.
A Surface class is split out which holds a wl_surface and supports
attaching a buffer, setting the damage and emitting a signal when the
frame callback got called.
It doesn't come with a unit test yet as it first needs the ShmPool
and Buffer properly split out to easily set it up.
New classes Shell and ShellSurface are created. Both are in shell.[h|cpp]
to indicate their close relationship with the Shell having to create the
ShellSurface.
WaylandBackend is adjusted to hold a Shell* and ShellSurface* instead of
the lower level structs. This also required adjustements to the creation
of the Backend as it now doesn't set a default size any more. Thus the
backendReady signal may not be emitted before the initial configure
event arrived. This also makes it easier to support either the fullscreen
shell or wl_shell at the same time.
Of course a unit test is added for the two new classes. This needs to
be extended once we have more control over the mock Wayland server.
At the same time adding an autotest for the Output, moving the listener
into the Output class and providing enums for Subpixel and Transform.
KWin now requires wl_ouput interface version 2 as that allows us to emit
the changed signal in a better way.
The unit test is not yet capable of testing everything, we need a mock
Wayland server which is more flexible.
The FullscreenShell is a Wayland protocol provided by Weston to have
exactly one surface per output. This is exactly what KWin needs. So
in case the Wayland server we connect to provides the FullscreenShell
we prefer it over the normal Shell and mapping our surface as fullscreen.
The protocol is not yet part of wayland-client library, so the header
and source file needs to be generated. This is done during the build
process using the external tool wayland-scanner. The protocol
description is copied from the Westion 1.5 sources.
REVIEW: 119839
The Wayland::Registry class wraps wl_registry handling. It keeps track
of the interfaces in the registry and emits signals whenever a known
interface gets announced or removed. So far it only tracks the interfaces
which are used and needed by KWin.
The Wayland event queue is moved into a dedicated thread and a
new class is created for just creating the connection and listening
for events. The WaylandBackend creates the thread and uses an event
queue for the main thread.
REVIEW: 119761
This restores the behavior on KWin4: if I set an X property that doesn't have any data on a window, it's still information, so this makes the Xcb wrapper return an empty QByteArray that is not null.
EffectWindow::readProperty() now returns an empty QByteArray constructed the same way as it was in KWin4.
REVIEW:118645
BUG:335446
This removes all the hacks to add kwin4_effect_ to the name of the Effect
and adjusts the desktop files of the effect configuration's parent
component.
Note: the scripted effects still start with kwin4_effect_ prefix.
REVIEW: 117367
The Xcb::Property can wrap the xcb_get_property call and provides
convenient access methods to read the value of the reply with checks
applied. For this it provides a templated ::value method for reading a
single value or reading an array. There's also a ::toBool and
::toByteArray which performs the conversion directly with default values
for the type and format checks.
Xcb::TransientFor is changed to be derived from Property instead of
Wrapper directly, so that the reading of the property value can be
shared.
Xcb::StringProperty is a convenient wrapper derived from Property to
handle the reading of a string property providing a cast to QByteArray
operator. This replaces the ::getStringProperty from utils. Though the
separator functionality from ::getStringProperty is not provided as that
is only used in one function and handled there.
All the custom usages of xcb_get_property or getStringProperty are
replaced to use this new wrapper. That simplifies the code and ensures
that all properties are read in the same way.
REVIEW: 117574
So far the effects could just use the connection() and rootWindow()
provided by kwinglobals. Thus an internal detail from KWin core is
accessed directly.
To be more consistent with the rest of the API it's wrapped through the
EffectsHandler and with a convenient method in Effect.
The connection() is provided as xcbConnection() to free the very generic
name connection which could create confusion once we provide a wayland
connection to the Effects.
The rootWindow() is provided as x11RootWindow() to indicate that it is
for the X11 world.
REVIEW: 117597
Let's use the available API instead of duplicating code.
Nice side effect: client_machine.cpp doesn't include utils.h any more
which simplifies the unit test.
REVIEW: 117473
This is a specialized subclass of AbstractEffectLoader to load binary
effect plugins. It used the KPluginTrader to find all candidates to load.
The loader is able to detect incorrect ABI versions through the
pluginVersion() and uses the methods exposed by the new
KWin::EffectPluginFactory to check whether the Effect is supported and
should be enabled by default.
The unit test for this loader comes with two plugins: one is able to be
loaded and provides a supported and enabledByDefault method which can be
tweaked during the test to get all the conditions we want to test for.
The second plugin uses an incorrect plugin version and thus cannot get
loaded.
This implementation of the AbstractEffectLoader is able to to load the
scripted KWin Effects. It uses KServiceTypeTrader to find all the
candidates to load.
Effect loading gets split by the kind of effects KWin supports:
* Built-In Effects
* Scripted Effects
* Binary Plugin Effects
For this a new AbstractEffectLoader is added which will have several
sub-classes:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
* EffectLoader
The EffectLoader will be what the EffectsHandlerImpl is using and it just
delegates to the three other types of loaders. Thus the handler doesn't
need to care about the different kinds of effects. The loading is
supposed to be completely async and the EffectLoader emits a signal
whenever an Effect got loaded. The EffectsHandlerImpl is supposed to
connect to this signal and insert it into its own Effect management.
Unloading is not performed by the loader, but by the EffectsHandler.
There is one important change which needs to be implemented: the ordering
cannot be provided by the loader and thus needs to be added to the
Effects directly.
So far only the BuiltInEffectsLoader is implemented. It's not yet
integrated into the EffectsHandlerImpl, but a unit test is added which
tries to perform the various operations provided by the loader and the
BuiltInEffects. The test should cover all cases except the Check Default
functionality which is only used by Blur and Contrast effects. This
cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
Only delegated to Cursor::pos() anyway, so let's just use that directly.
Fixes the annoyances of having to mock it in the unit tests which include
utils.cpp.
REVIEW: 116900
Used by Cursor to properly emit the mouseChanged signal which for
historic reasons includes the keyboard modifiers.
Again some fiddling around with the autotests and kcmrules needed to
make it compile. This needs improvement!
New inheriting class which uses the InputRedirection to track the cursor
position. It doesn't support warping of cursor.
This introduces a slight dependency loop in the startup. Cursor needs to
be created after the WaylandBackend to ensure that the operation mode is
set correctly. But the WaylandBackend itself is accessing Cursor. It
should be safe as inside the WaylandBackend it's only accessed after
callbacks.
