For some reason with legacy the cursor gets an offset when changing the
image. In order to work around this, directly issue a cursor move with the
corrected position when changing the buffer
As we don't provide any ability for the user to configure the gestures yet,
the gesture for the desktop grid should stay as it was in the last release.
This commit swaps the gestures for desktopgrid and overview to achieve that.
At the moment, the data offer initializes supported and preferred action
to "none". But if the target doesn't accept anything the source
provides, the compositor may still need to send action events with "none"
This change makes data offer and data source provide dnd actions wrapped
in std::optional in order to indicate if they have been set explicitly.
SeatInterface emits dragEnded when the drag is dropped. The target may want
to interact with the data source after the drop happened, for example only
fetching data after the drop and not during the drag.
(Note that the Wayland protocol has the same
Xvisits are now not deleted prematurely but only when they are really finished.
(Note that the Wayland protocol has the same distinction between dropped and
finished so it maps nicely).
For storing previous visits the same code pattern as in the rest of the XWayland
DND code is used.
The SelectionSource is reset when the next Drag/Drop operation involving a X window
is started (see startDrag and doHandleXfixesNotify) or when the Wayland source is
about to be deleted.
BUG:450460
FIXED-in:5.25.0
Gesture recognition code doesn't handle correctly cancelling a touch
sequence. testTouchPoint in one of its tests simulates pressing the
screen with three fingers and cancelling the touch sequence.
Emitting the Workspace::windowAdded() signal before actually adding the
window to the Workspace is counter-intuitive and it can a source of
potential bugs as relevant window lists in Workspace don't contain the
window yet.
The features that this KCM lets you trigger barely work on X11 and
really only work properly on Wayland.
Unfortunately we don't have the ability to have separate settings
between X11 and Wayland, and for this reason we removed a default left
touch edge in 3df7985570 a year and a half
ago because it was too buggy on X11.
This commit takes the next step and hides the KCM entirely on X11, so
you can only use it on Wayland where it actually works properly.
One potential downside is be that any users who are actually using it
on X11 will lose the ability to use a GUI to configure these features
unless they go to the Wayland session to do it. However the number of
such users is likely small given how the feature does not really work on
X11.
However the upside is that Wayland users who can see the KCM can
actually use the features that it lets you configure because they work
properly there.
As it turns out, it's needed to ensure that the Workspace emits the
stackingOrder changed signal when a new window is added. It's also
implicitly needed to make sure that Window::stackingOrder() is updated.
Currently we guess the supported and preferred dnd actions in data offer
for version >= 3. This can create problems because kwin may not send the
right action events when the supported dnd actions actually change.
With this only the main and the libinput threads will use realtime
scheduling, so it will be harder to leak realtime scheduling to somebody
else.
The only caveat is that kwin would need to keep CAP_SYS_NICE around,
however on the other hand, it's needed to ensure that kwin_wayland is
able to get high priority EGL contexts with some drivers, e.g. intel.
QX11Info is used in `platform.cpp`, which is used by both
kwin_x11 and kwin_wayland. The latter only gets it implicitly
through KGlobalAccelPrivate.
Ideally, platform.cpp was split to not require QX11Info in
kwin_wayland in the first place.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
As a wayland compositor kwin can hold many open file descriptors and
therefore it's easier for it to hit the soft file descriptor limit. This
change makes kwin_wayland bump the soft file descriptor limit to the
hard limit. With systemd, it's usually 500K.
In order to prevent causing mess in child processes, pthread_atfork() is
used to register a handler which will be invoked in the child process
after fork() in order to restore RLIMIT_NOFILE to its original value.
Otherwise the build fails for me with the following error:
error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
Upstream does not appear willing to fix this issue, so we have to add a
define to avoid usage of this useless keyword.
See https://github.com/mm2/Little-CMS/issues/190 and
https://github.com/mm2/Little-CMS/issues/243.
Overview is quite polished now, enough that we have a default touchpad
gesture that opens it by default. It's time to move it out of public
beta and enable it by default, and this commit does that.
BUG: 446753
FIXED-IN: 5.25
It appears that importing gbm_bo's using eglCreateImageKHR() doesn't
work on nvidia.
Another issue is that Platform::createDmaBufTexture() uses
gbm_bo_create(). The nvidia driver doesn't like that, it's preferred to
use gbm_bo_create_with_modifiers().
In order to address those issues, this change refactors how gbm_bo
objects are imported and how gbm_bo's are allocated for dmabuf textures,
so the same code can be reused in EglGbmBackend::textureForOutput()
and Platform::createDmaBufTexture().
This makes it consistent with WindowView (and the panel window doesn't respond
to input anyways even if shown, which is misleading).
BUG: 444274
FIXED-IN: 5.24.6
This allows using global shortcuts while a move/resize is ongoing. Most
importantly, this allows moving a window to a different desktop by
picking it up and then using a global shortcut to move to a different
desktop.
BUG: 444696
The Workspace has two stacks - one with managed windows and deleted
windows, the other includes windows from the first stack + override
redirect windows.
This change merges both stacks. It has several benefits - we will be
able to move window elevation stuff to Workspace and streamline the
scene stuff, for example it will be possible to have a root item.
Another advantage is that unmanaged windows will have
Window::stackingOrder() property set, which can be useful in the future
in qml effects or (qtquick scene if we push harder in that front).
Another advantage is that kwin will make less X11 calls when restacking
managed windows.
WindowItem has proper visibility set now, so these two interim hacks can
be removed now.
Workspace::stackingOrderChanged still needs to be kept around as the
Scene has no root item which could track the order of its child (window)
items.