The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
On Wayland, a surface must be displayed the same way no matter how the
attached buffer is transformed. In order to guarantee that, we build the
surface-to-buffer matrix, which is used to compute the texture coords.
The surface-to-buffer matrix represents an affine transformation. Thus,
performing linear interpolation between texture coordinates won't end up
in corrupted rendered results. This is the main assumption that we make
during generation of contents window quads. After creating a sub-quad,
the new quad's texture coordinates are computed by interpolating between
the source quad's texture coords.
However, WindowQuad::makeSubQuad() makes a concrete assumption about the
order of texture coords, which might be false if the attached wayland
buffer is rotated 90 or 270 degrees.
This issue went unnoticed after merging the viewporter patches because
the developer who was working on it had been using primarily nested
kwin_wayland for testing purposes. And it appears like kwin schedules
full screen repaints even though it supports buffer age. It still needs
some investigation why that happens.
BUG: 428003
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
Summary:
This change adds detection support for virgl (Mesa gallium virtio guest driver).
Results in proper detection in supportInformation and debug console.
Test Plan: Modified test passes, run KWin_Wayland in kvm with virgl and verified supportInformation
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25056
Summary:
Currently, KWin is not able to detect Radeon GPUs with GCN architecture.
This patch tries to address that.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17715
Summary:
The redirect modes control behavior of the timeline when its direction
is changed at the start or target position. For example, consider the
following piece of code:
TimeLine timeLine(1000ms, TimeLine::Forward);
timeLine.setDirection(TimeLine::Backward);
What should happen when the direction of the timeline was changed to go
backward? Should the current value of the timeline go from 1 to 0, or
should the timeline stop its "execution"?
In the relaxed mode, the timeline will go from 1 to 0.
In the strict mode, the timeline will stop its execution.
Different effects may prefer different modes for source and target
positions. For example, most C++ effect would prefer relaxed mode for
source position, and strict mode for target position. On the other side,
scripted effects(AnimationEffect) would prefer strict mode for source
position, and relaxed mode for target position(because of set).
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16447
Summary:
Most effects use QTimeLine in the following manner
```lang=cpp
if (...) {
m_timeline->setCurrentTime(m_timeline->currentTime() + time);
} else {
m_timeline->setCurrentTime(m_timeline->currentTime() - time);
}
```
Because effects do not rely on a timer that QTimeLine has, they can't
toggle direction of the QTimeLine, which makes somewhat harder to write
effects. In some cases that's obvious what condition to use to figure
out whether to add or subtract `time`, but there are cases when it's
not. In addition to that, setCurrentTime allows to have negative
currentTime, which in some cases causes bugs.
And overall, the way effects use QTimeLine is really hack-ish. It makes
more sense just to use an integer accumulator(like the Fall Apart
effect is doing) than to use QTimeLine.
Another problem with QTimeLine is that it's a QObject and some effects
do
```lang=cpp
class WindowInfo
{
public:
~WindowInfo();
QTimeLine *timeLine;
};
WindowInfo::~WindowInfo()
{
delete timeLine;
}
// ...
QHash<EffectWindow*, WindowInfo> m_windows;
```
which is unsafe.
This change adds the TimeLine class. The TimeLine class is a timeline
helper that designed specifically for needs of effects.
Demo
```lang=cpp
TimeLine timeLine(1000, TimeLine::Forward);
timeLine.setEasingCurve(QEasingCurve::Linear);
timeLine.value(); // 0.0
timeLine.running(); // false
timeLine.done(); // false
timeLine.update(420);
timeLine.value(); // 0.42
timeLine.running(); // true
timeLine.done(); // false
timeLine.toggleDirection();
timeLine.value(); // 0.42
timeLine.running(); // true
timeLine.done(); // false
timeLine.update(100);
timeLine.value(); // 0.32
timeLine.running(); // true
timeLine.done(); // false
timeLine.update(1000);
timeLine.value(); // 0.0
timeLine.running(); // false
timeLine.done(); // true
```
Test Plan: Ran tests.
Reviewers: #kwin, davidedmundson, graesslin
Reviewed By: #kwin, davidedmundson, graesslin
Subscribers: romangg, graesslin, anthonyfieroni, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13740
Summary:
The renderer string does not contain "Gallium 0.4 on" anymore,
instead it directly contains the gallium driver's name.
So assume that every unknown renderer is a gallium driver.
Test Plan: Added a testcase, it succeeds only with this patch.
Reviewers: #plasma, graesslin
Subscribers: kwin, plasma-devel, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9495
Summary:
KWin was quite good in ensuring that you don't need to install by
passing paths to the tests. The new way is much nicer, so code is
adjusted for the new way. Also if we require a newer ECM in future we
need to support the new way.
No guarantee that the tests don't pick something up from the system env,
that needs more testing.
References: https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled
Test Plan: The tests which loaded helpers pass
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7543
Removes one of the last pure XLib usages and also means that in theory
we can detect the Xwayland version number. In practice that only works
when restarting the compositor as detect is invoked before the XWayland
connection is created.
Summary:
The Qualcom Adreno classes are recognized and a version detection
workaround is added for libhybris which only announces GLES version 2
although GLES version 3 is supported. KWin at least used to work with
GLES version 3 which gives us e.g. framebuffer blit.
Reviewers: #kwin, bshah
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2415
Example data harvested from bugs.kde.org: open bugs against kwin with
a comment containing supportInformation.
We can see that especially detecting modern radeon gpus is not working.
The new test can load "profiles" from kconfig files in the test data.
Based on that the glGetString return values are mocked and GLPlatform
can perform detect without having to interact with a real GL library.
That way we can verify that the detect code works correctly. As a first
test the settings of one Intel/IvyBridge is included. More tests can be
added easily (e.g. looking at various supportInformation output in
bugs.kde.org). Also this allows to more easily add detect code for GPUs
we do not know yet. And to simulate conditions where the detect code
failed resulting in no compositing at all.
