Summary:
Another regression from enabling touch support on X11.
The approach window for pointer input gets unmapped as soon as the mouse
enters the window. This ensures that mouse motion events are not stolen
from other applications. But with the touch events we did not even react
on the enter event if it's not activated for pointer. The result was an
area around the screenedge being blocked for pointer input.
This change only creates and maps the approach window if the edge is
activated for pointer input.
BUG: 378951
Test Plan:
Activated edges through pointer and touch, reconfigured and tested
motion events
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5528
Summary:
Grabbing the touch events seems to cause issues. It seems to also grab
pointer events from touchpad and breaks touch input on other events.
Also testing shows that we don't need it and get touch ownership events
for our screenedge windows reported.
BUG: 378951
Test Plan: Triggered touch screen edge, normal system usage on X11
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5520
Summary:
This change extends the XInputEventFilter to also listen for all touch
events on the root window.
The touch points are passed to the new gesture recognizer in screenedges.
Please note that I'm not using X11 and have hardly tested this change in
real world. To our X11 users with touch screen support: please test!
Test Plan: Can activate and deactivate the screenedge.
Reviewers: #plasma, #kwin
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5137
Summary:
Each Edge creates a SwipeGesture for touch activation. The swipe needs to
be a single finger starting from the edge into the screen for at least
20 %. The SwipeGesture and GestureRecognizer is extended to support the
use cases of the touch screen edge swipe.
New features supported by the gesture system are:
* minimum and maximum position
* a minimum delta for the swipe
* progress signal based on the minimum delta
* starting a swipe with a start point
The Edge has the progress signal connected to its approach signal, thus
visual feedback is provided through the screen edge effect.
The screen edge system supports touch only for the edges (corners are
too difficult to activate on touch screens). At the moment the following
features are supported:
* screen edge show/raise of windows (e.g. auto hidden panels)
* trigger the configured action
* trigger the configured callback function (e.g. script)
In future it might make sense to add a touch specific configuration
action to support different actions for screen edges activated by mouse
and touch.
BUG: 370323
Test Plan:
configured a screen edge and triggered through touch,
added an auto-hiding panel and triggered through touch
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5106
Summary:
The functionality regarding triggering modifier only shortcuts is moved
out of Xkb - where it doesn't belong to - and is turned into an input
event spy listening for the changes it is interested in. Previously
the state got queried by asking e.g. for the pressed buttons, now it's
tracked directly.
The X11 side needs a larger change due to that as now pushing the events
into Xkb does not trigger modifier only shortcuts any more. Instead the
"normal" way through the platform API needs to be used which triggers the
processing of filters and spies.
The problem here is that our redirections only process events if they are
inited and that only happens on Wayland. We cannot call init on them as
that would create all the Wayland filters and spies and processing would
probably break. As an intermediate solution the spies are now processed
and there we know that it won't matter. A future solution would be to
remove the init checks completely and just send through both filters and
spies and ensure that on X11 only the supported ones are loaded.
Closes T5220
Test Plan: Tested on Wayland and X11
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Maniphest Tasks: T5220
Differential Revision: https://phabricator.kde.org/D4578
Summary:
InputRedirection has a workaround to add a connect on a QAction which
is used for a global shortcut. This is specific to the X11 platform as
the xtime needs to be updated.
This change adds a new virtual method to the Platform and moves the
implementation into the X11 standalone platform. Thus it does no longer
gets called on Wayland.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4168
Summary:
It's only needed by the GLX backend, so only find if we have GLX at all
and only link where needed. As it was handled incorrectly before, it's
now using proper ifdef.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3448
Summary:
Instead of having the egl extensions in the global kwinglutils lib it
becomes private to the AbstractEglBackend. Just like on glx the
glxextensions are moved into the platform.
The extensions are queried from initEglAPI, that is as early as possible
after initializing the EGLDisplay. This ensures that any implementing
subclass can access the extensions early enough.
As a note: the EglOnXBackend had a potentially wrong sequence for
initializing the buffer age extension. It is now moved to the correct
place where the result is needed for the first time.
From the global API eglExtensions are removed from hasGLExtension and
the eglExtensions function is dropped. As by that initEGL did not do
anything it is also dropped.
Test Plan:
Tested nested kwin on Wayland, still works, extensions shown
in debug console
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3396
Summary:
A new virtual method is added to Platform:
startInteractiveWindowSelection
The interactive window selection enters a mode where the user can select
a window through the pointer or keyboard device. The cursor is turned
into a crosshair cursor, unless another cursor name is provided (e.g.
pirate for kill window).
Once a window is selected the provided callback method is invoked with
the selected Toplevel as argument. In case the user cancelled the
selection a nullptr argument is passed in.
Currently it's only implemented by the X11 standalone platform using the
logic from KillWindow. Just instead of killing the window the callback
is invoked.
KillWindow loses the X11 implementation and interacts with the new
functionality in Platform by providing a lambda function for the
killing.
Test Plan: Killing of X11 windows is still possible
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3363
Summary:
And finally nothing inside libkwineffects, libkwinglutils,
libkwinxrenderutils and kwineffect and kwin core uses KWin::display.
We are finally XLib free!
This change drops KWin::display and removes the include to QX11Info from
kwinglobals.h. And the libraries no longer need to link X11Extras. Due
to that removal a few seeming unrelated changes are required to add the
include where needed and linkage to X11Extras.
The biggest change is to x11 platform plugin which still needs the
display and caches it in the Platform and passes it to various places in
a way that the code doesn't need to be adjusted.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3337
Summary:
KWin still resolves some OpenGL function pointers. For that it needs to
use either eglGetProcAddress or glxGetProcAddress. With other words the
method to resolve needs to know whether it is egl or glx and needs both
a dependency to egl and glx. Especially the dependency to glx is ugly as
that pulls in XLib into our library.
The way so far was to pass an enum value to the initGL method to know
whether it's EGL or GLX. With this change the enum value is removed and
replaced by a function pointer to resolve the methods.
This simplifies the resolve code and allows to completely remove the glx
variant we still had in the library. Thus kwinglutils library is now glx
and XLib free.
Test Plan: nested KWin with OpenGL/EGL still works
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3336
Summary:
No need to resolve glx methods through the shared lib. At the moment
this duplicates some code, but will be cleaned up with a follow up
change.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3335
Summary:
Glx extensions are only interesting to the glxbackend. Given that
querying can be moved there.
In order to simplify the extensions can be stored in the OpenGLBackend
which also provides the convenience check as before.
The egl platforms should also be adjusted to query in that way and
remove it from the kwinglutils.
There is still a usage of the glxextensions inside kwinglutils to
resolve one function. That should also be moved into the platform.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3332
Summary:
Glx version is only required once in the standalone x11 platform. No
need to have that in the shared kwinglutils library.
Removes one xlib usage from shared kwin.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3329
Summary:
Some platforms support to hide and show the cursor. This will be needed
by e.g. the zoom effect which currently only provides this functionality
on X11.
This change introduces a new method in the Platform to hide and show the
cursor. The methods need to be called balanced and the implementation
takes care of only showing again if all hide got matched by a show.
The actual hiding and showing is performed in the platform plugins. So
far the DRM and X11/Standalone platforms implement the required
functionality, though other platforms probably could implement as well.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3119
Summary:
With nouveau driver it can happen that KWin gets frozen when first trying
to render with OpenGL. This results in a freeze of the complete desktop
as the compositor is non functional.
Our OpenGL breakage detection is only able to detect crashes, but not
freezes. This change improves it by also added a freeze protection.
In the PreInit stage a thread is started with a QTimer of 15 sec. If the
timer fires, qFatal is triggered to terminate KWin. This can only happen
if the creation of the OpenGL compositor takes longer than said 15 sec.
In the PostInit stage the timer gets deleted and the thread stopeed
again.
Thus if a freeze is detected the OpenGL unsafe protection is written into
the config. KWin aborts and gets restarted by DrKonqui. The new KWin
instance will no longer try to activate the freezing OpenGL as the
protection is set.
If KWin doesn't freeze the protection is removed from the config as
we are used to.
Check for freezes for the first n frames, not just the first
This patch changes the freeze detection code to detect freezes in the
first 30 frames (by default, users can change that with the
KWIN_MAX_FRAMES_TESTED environment variable). This detects
successfully the freezes associated to nouveau drivers
in https://bugzilla.suse.com/show_bug.cgi?id=1005323
Reviewers: davidedmundson, #plasma, #kwin, graesslin
Reviewed By: #plasma, #kwin, graesslin
Subscribers: luebking, graesslin, kwin, plasma-devel, davidedmundson
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3132
Summary:
There are several effects (screenshot, zoom) which need access to the
cursor image and cursor hotspot. So far these effects used X11
unconditionally to get the cursor which obviously does not work on
Wayland.
This change adds a new class PlatformCursorImage to kwinglobals which
wraps what a cursor is (image and hotspot) and adds a new virtual method
to Platform to provide such a PlatformCursorImage. By default it's the
cursor image the Platform tracks. On X11/standalone platform this new
virtual method is overriden and provides a PlatformCursorImage from X11
using the code previously used in screenshot effect.
Screenshot effect and zoom are adjusted to use the new API instead of
X11.
Test Plan:
Zoom effect tested on Wayland, now gets the proper cursor icon.
X11 functionality not yet tested.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3093
Summary:
The modifier-only-shortcuts break as soon as KWin grabs the keyboard
(e.g. alt+tab, present windows, etc.). The investigation shows that in
that case KWin does not get any raw key events any more and thus gets
confused about the state of the hold modifiers. E.g. alt+tab has the
alt key pressed, but we miss the release as the keyboard is grabbed.
This change addresses the problem by installing an additional event
filter for key press and release event which only filters for key events
on the root window. That way we can be sure that it only operates when
KWin grabbed the keyboard on the root window.
Note: the problem only exists when grabbing on the root window. If the
grab is on another window (e.g. moving a window) we still do get all
events.
The problem also seems to not happen if another application grabbed
keys on the root window. E.g. for key combinations grabbed by
kglobalaccel the correct sequence of key press/release as raw events
are reported. Also while the screen is locked the evemts are reported
and kscreenlocker grabs the keyboard on the root window.
Test Plan:
Used Alt+Tab and Present Windows and tried to activate launcher
afterwards.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2980
Summary:
The raw pointer button events intercepted in the XInput2 input filter
get sent through the Platform to the PointerInputRedirection. This
makes the PointerInputRedirection track the pointer button state and
emit the signals for button changed and axis changed.
These signals are used by the modifier-only shortcut detection to
determine whether the shortcut should trigger.
On X11 the "normal" input handling doesn't use the InputRedirection
and the emitted signals are not consumed by anything else. As
PointerInputRedirection is not inited the events are not forwarded
to the input filter, thus won't be processed by other parts and
won't interfere with the normal event processing on X11.
Given that it also doesn't matter that the input filter does not
apply the left-handed setting. The internal tracking will have a
wrong mouse button, but nothing is going to do decisions based on
the value of the pressed mouse button. For the moment all we are
interested in is that a button is pressed.
Test Plan:
Pressed meta, clicked, scrolled, released meta: launcher
did not open. Pressed meta, released meta: launcher opened
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2506
BUG: 367730
At the same time the xinput2 integration is split out of X11Cursor
and made a standalone part of the platform plugin. XInput integration
is nowadays not only used by the cursor position polling, but also
for modifier only shortcuts.
By splitting it out the modifier shortcuts start to work also when
one doesn't have anything requesting a mouse position polling.
This also simplifies the conditional builds: xinput integration is
only included if we have support for it at compile time without having
to have many ifdefs in the cursor implementation. For the inclusion of
cursor in the kcmkwin this also removes all the ifdefs.
The key events are only requested if we have xinput 2.1. Otherwise we
would not get all raw events if the input device gets grabbed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2473
By default the InputRedirectionCursor is created and only the X11
standalone platform creates the X11 specific cursor.
This is a preparation step for moving the X11 specific cursor
implementation into the x11standalone platform plugin.
Summary:
When closing a nested window kwin_wayland only terminates if the closed
window is the last output window. In a simulated multi-screen setup
closing a window results in the output being removed.
Test Plan: Closed windows, verified with xrandr
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2234
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
If the event processing is started before everything is fully started
it can happen that we have "evil" events which may crash either Xwayland
or KWin itself. E.g. if the nested window is too large, the window
manager on the host X-Server will request a resize. If the backend does
that it can happen that the wl_output gets destroyed while Xwayland tries
to bind to it and will crash. Thus let's delay all events till we are
ready to process them.
