At the moment we are getting the input method from the command line
which is not very handy (but very secure).
This patch changes it so it can be specified from a configuration
setting.
CCBUG: 427972
Currently, we estimate the expected render time purely based on the
latency policy.
The problem with doing so is that the real render time might be larger,
this can result in frame drops.
In order to avoid frame drops, we need to take into account previous
render times while estimating the next render time. For now, we just
measure how long it takes to record rendering commands on the CPU.
In the future, we might want consider using OpenGL timer queries for
measuring the real render time, but for now, it's good enough.
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
This reverts commit bcba2e252f.
This change broke a dozen of tests, most of which were fixed. However,
it made more clear that we need to re-evaluate if enabling this option
by default is a good idea.
Since some people apparently liked the old behavior of moving minimized
windows to the end of the focus chain, let's let them have it if they
set a hidden config option:
`MoveMinimizedWindowsToEndOfTabBoxFocusChain=true` in the `[TabBox]` group
of the kwinrc file.
We can add a UI for it later if needed.
BUG: 427840
FIXED-IN: 5.21
If the Xwayland process has crashed due to some bug, the user should
still be able to start applications in Xwayland mode. There is no reason
to restart the whole session just to be able to launch some application
that doesn't have native support for Wayland.
Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway.
BUG: 399375
Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland.
Summary:
e.g. "Vertically maximize" is more natural and expressive than "Maximize (vertical only)"
See D29671#inline-169882.
Test Plan: New strings appear in the KCM
Reviewers: zzag, #vdg, #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29729
Summary:
It doesn't belong with advanced compositing settings as it's quite user
friendly, and we also want to adjust other animation speeds. May as well
do it together.
In the current form all compositing is still completely reinitiliased
like with the previous slider. Change notifications come in the form of
KConfigWatcher rather than our own bespoke update interface.
Test Plan:
Moved new slider, minimised a window.
It still behaved as expected.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, broulik, anthonyfieroni, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22887
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
This hack seems to be deactivated by default nowadays and I did not find an
option in the KCMs to activate it. Git blame shows some last commits from
around 2012 to the functions, but they only deal with code style.
Also even if it would be enabled, in light of Wayland we don't want some
roque XWayland client go bonkers via this hack.
This patch removes the code path in order to decrease complexity and ease
future changes to the fullscreen handling overall.
Test Plan: Manually and autotests pass.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, graesslin, kwin
Tags: #kwin
Maniphest Tasks: T11098
Differential Revision: https://phabricator.kde.org/D18157
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
Summary:
From feedback we got it seems that not all users agree to games and
other applications blocking compositing. Some users prefer to have
compositing always on even if this gives a small performance penelity.
This change introduces a dedicated config option to specify whether games
are allowed to block compositing. By default this option is enabled.
The setting can be overwritten with a window specific rule. So usecases
like all windows except this very specific one are supported.
In the user interface the config option is shown where previously the
unredirect fullscreen option was shown.
Test Plan:
Run a game which should block compositing, verified it blocks.
Changed the setting, run the game again, verified it doesn't block. And
once more for with allowing to block.
Reviewers: #kwin, #plasma_on_wayland, #vdg
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2584
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
A new config option "GLPlatformInterface" is added to the Compositing
settings group. Valid values are "glx" and "egl". This config option is
honored by the Scene to decide which backend to create.
The setting gets sanitized by the operation mode (egl for Wayland),
the environment variable KWIN_OPENGL_INTERFACE and the compile time
support. These switches are removed from the Scene to not have them
duplicated.
For the time being the current design of Options is more or less kept to
not have to adjust KWin code all over the place. Also for some parts the
generated class from KConfigXT cannot be used due to inter-settings
dependencies defined in the setters.
Options now holds a pointer to a Settings object which is generated from
KConfigXT and uses it to read the default values and the individual
settings. This means the static default value methods are dropped and the
variables are initialized with a normal default value (all int 0, all
boolean false and so on) in the initializer list. Afterwards the values
are set to the correct default value through KConfigXT.
So far for the first step only Windows category is using KConfigXT.
REVIEW: 108572
Apparently it's not allowed to have two groups with the same entry names.
Parameterized groups are still a "TODO" and a group must have a name.
Looks like we won't be able to use KConfigXT for TabBox.
types for a lot of entries and it proly misses a few hidden entries, if you know
those please add those (you can use kcfgcreator if you want to do it quickly)
svn path=/trunk/kdebase/kwin/; revision=311445
