Summary:
- Actually use double layered compositing, previously both layers were
of type HWC_FRAMEBUFFER, instead of 2nd layer being
HWC_FRAMEBUFFER_TARGET. Thanks to @NotKit on telegram for pointing this
out.
- Use sourceCropf instead of sourceCrop, as sourceCrop is legacy option.
Test Plan: have to test on actual device, but test_hwcomposer does have similar code.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8587
Summary:
This change hooks up the bits for changing the mode when a request to
change mode from kscreen is received. This includes:
* setting new mode in DrmOutput
* creating new buffers in SceneQPainter backend
* creating new GbmSurface in SceneOpenGL backend
Room for improvement:
* detect whether the new mode works and go back to old one if it fails
Test Plan:
Started both a QPainter/OpenGL session. Used kcmshell5 kscreen
to modify the resolution. Saw that it got applied, maximized a window to
verify it's correct. Changed back to original resolution. Verified it looked
good by maximizing a window.
Reviewers: #kwin, #plasma, subdiff, sebas
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8398
Summary:
The SCHED_RESET_ON_FORK results in threads (not only processes) to have
the scheduling policy reset to default. This means that the libinput
thread is not real time, but this was actually intended.
To solve this problem KWin does start without the RESET_ON_FORK flag
during startup. Once createInput has been called the scheduling is
adjusted again and RESET_ON_FORK is added again. This results in the
libinput thread and all threads Qt starts in between (e.g. dbus) to gain
real time policy. But it is still not leaked to other processes or to
threads in KWin which don't need it.
Other options considered: just don't use RESET_ON_FORK and instead
manually reset on fork. This would mean all threads in KWin gain real
time, but we don't need this. It's only interesting for the main
(rendering, Wayland thread) and the input thread. Also the danger to
leak into another process is too high.
Keeping the capability till the libinput thread is created and adjust
the thread itself. This option was discarded as I don't want KWin to
have any capabilities when the QApplication is started.
Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8065
Summary:
Rendering subsurfaces in the OpenGL compositor has always resulted in
flickering when a subsurface gets repainted and there is a window on top
of it. Looking at the code this is rather obvious: the clipping of the
main window is ignored and the complete subsurface is rendered as is and
thus also rendering above windows where it should not render.
This change passes the clip region and whether hardware clipping is used
to the rendering of subsurfaces which in turn uses it for rendering the
texture.
BUG: 385924
FIXED-IN: 5.11.3
Test Plan:
Opened systemsettings, went to decoration KCM, put a window
partially above and scrolled. Without change: strong flicker, with change:
no flicker.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8369
Summary:
Under wayland we support high DPI putting by putting a separation
between the logical co-ordinate system and the resolution of rendered
assets.
I didn't include window decorations in the previous wayland scaling
patchset. They were drawn them at a standard resolution, which is
implicitly scaled up.
This uses the Qt scaling, meaning oxygen and breeze (and others) get
perfect high DPI support with zero client changes.
Like the window scaling this handles any combination of a 2x scaled
decoration being rendered on a 1x screen or vice versa.
CCBUG: 384765
Test Plan:
export KWIN_COMPOSE=Q
Had two screens of different scales
It was the right size on both (as before)
Was super-sharp on the fancy screen
Reviewers: #plasma, hetzenecker, graesslin
Reviewed By: #plasma, graesslin
Subscribers: ngraham, graesslin, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8504
Summary: D8479 fixes viewport for real hardware, but there is still problem with screenshots. This patch fixes that.
Test Plan:
- Have three monitors (like in bug 385655)
- Press PrtSc and then Enter
- Screenshot is ok
Before:
{F5450056}
After:
{F5450058}
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8485
Summary:
glScissor works on window co-ordinates. i.e not scaled by the viewport
We need to multiply by the scale there.
This fixes a minor visual glitch in animations when using hardware
clipping.
Test Plan:
Hardcoded my minimise animation to be really slow.
Now every frame looks perfect
Reviewers: #kwin
Subscribers: kpiwowarski, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8490
Summary:
We want to translate by the monitor position, so that needs to be
the negative of the position.
But Kwin/KScreen treats 0 as the top of all monitors. GL treats 0 as
bottom, so that all needs inverting.
Hence this should be a positive y value for the viewport.
BUG: 386099
BUG: 385655
Test Plan:
Had two monitors
Side by side was - fine
Stacked vertically - still fine
Modded X code to extend in y instead of x.
3 monitors worked fine.
Nested wayland only seems to support one screen?
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8479
Summary:
there is no need for createOutput to be static, make it non-static,
this also fixes the build failure introduced in commit
02d3daf28a.
Test Plan: builds
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8430
Summary:
On Wayland we have the sync disabled as it doesn't work properly. This
allows us to also move the sync event handling into the X11 standalone
platform.
The code is slightly refactored: instead of passing the event to each
Client, we search for the matching Client. For that the SyncAlaram struct
is added to public section of Client. The method to handle the sync
doesn't need the event any more and is moved from events.cpp to
client.cpp.
Test Plan:
Run Xephyr+kwin_x11, resized a window and verified through
gdb breakpoint that the sync still works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7942
Summary:
With the new try of all compositor types supported there is an automatic
fallback from OpenGL to XRender/QPainter in case OpenGL setup failed.
So there is no need to invoke a method to do just that.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8364
Summary:
The Compositor now tries to create a Scene not just once but every
type supported by the Platform till it finds one which works. The user's
configuration is only used as a preferred hint and tried first if the
platform supports it.
This brings as an advantage that on platforms such as framebuffer the
user does not need to specify which compositor to use: KWin uses QPainter
automatically.
Also we don't need to do the "translation" from XRender to QPainter any
more. XRender is not supported by any platform using QPainter, so the
user configuration is ignored anyway.
BUG: 350159
FIXED-IN: 5.12.0
Test Plan: Run on framebuffer, verified debug output.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8363
Summary:
The test DontCrashUseractionsMenu (Waylandonly) found an issue in our
screen handling implementation in the QPA. The code exposed a short time
frame between the dummy screen getting destroyed and the first screen
being added. This could result in a crash of KWin.
There is actually no need to implement Screen on top of Wayland screen.
KWin has all the knowledge, so we can also base this on top of the
Screens API.
Advantages:
* no delays due to Wayland roundtrips
* handle screen getting removed (was a TODO)
* handle resolution changes (was a TODO)
The new implementation has a disadvantage that it destroys and readds
all screens whenever something around the screen changes. This shouldn't
be an issue in practice as it's only for the internal QPA and thus only
affects KWin internal windows which is placed in global coordinates
anyway. If it turns out to be a problem we need to track better the
screen changes - so far those were not tracked at all.
Test Plan: Run a few unit tests which change screens
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8345
Summary:
Allows to share the implementation in a better way and is a requirement
to get the Screen implementation in the QPA plugin to be based on
KWin::Screens instead of KWayland::Output.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8344
Summary:
This change sets up ShellClient for supporting window rules by reading
in the rules once it gets created. As a first rule the Apply initially
rule for desktop is implemented.
Currently it is not yet possible to set window rules through the
configuration menu. So far only injecting rules through the test
framework (temporary rules) is implemented. The idea is to first
implement all rules then to expose them to the UI.
Test Plan: New test case
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8177
Summary:
This change adds a DBus API to query whether the virtual keyboard is
currently enabled and provides DBus methods to request that the virtual
keyboard gets enabled/disabled. This is useful for e.g. providing a
Plasmoid or for convertables where the tablet mode needs to be enabled.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8166
Summary:
So far KWin does not know which Compositors the platform actually
supports. This results in KWin happily trying to use the OpenGL
compositor on fbdev or the QPainter compositor on hwcomposer although
that is obviously going to fail as the platform doesn't support this.
By adding a pure virtual method all Platforms can define what they
support. In a later step the Compositor can use this to create an
appropriate scene and also perform proper fallback handling in case the
scene creation fails.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8316
Summary:
When clicking the maximize button without moving the mouse, the maximize
button stayed in hover state till the mouse moved. The reason for this
is that the PointerInputRedirection does not perform an update on the
geometry change of a window.
BUG: 385140
FIXED-IN: 5.11
Test Plan: Manual testing
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8016
Summary:
The Platform API is extended by a call to create the EffectsHandler. In
X11 standalone Platform a new EffectsHandlerImplX11 is added which
contains the X11 only parts of the EffectsHandler, such as grabbing the
X keyboard and the X11 mouse interception window.
The EffectsHandlerImpl gains some virtual methods for the parts which
are now done in the X11 specific implementation. In return we get rid of
lots of if-else structures checking for the operation mode.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7955
Summary:
In a bug report there was a reference that on multi-screen KSplash is
not placed correctly. I investigated and noticed that it is an OSD which
sets an own position. In KWin the events were processed correctly but
the position was off.
The problem is that KWin has code to correct the position of an OSD when
it's size changes. This happens also on first damage and then the window
gets incorrectly placed when the position is set. So honor that the
position is set.
Test Plan: Restarted the session, ksplash positioned correctly now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8268
Summary:
This fixes the following problem:
1. Have two windows maximized
2. Click minimize button on first window
3. Click minimize button on second window
What happened:
Second click was ignored as the pointer was not updated.
BUG: 378704
FIXED-IN: 5.11
Test Plan:
Nested KWin/Wayland, added two maximized windows, minimized
both without moving the mouse
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8145
