Put together the two methods about window properties and rules
into the same class, since they are tightly related and they seem
a bit out of place within RuleBookModel
Small refactor patch. No behavior changes
With the new interface, the compositor sends raw image data instead of
encoding it as a png image, which causes a lot of overhead on Wayland.
In addition to that, the new interface is more extensible, for example
we can add new options or change the written image data format, however
the latter is less likely to happen.
BUG: 433776
At the moment, the session code is far from being extensible. If we
decide to add support for libseatd, it will be a challenging task with
the current design of session management code. The goal of this
refactoring is to fix that.
Another motivation behind this change is to prepare session related code
for upstreaming to kwayland-server where it belongs.
When rules configuration is invoked from window `Alt+F3` menu,
we call a custom binary `kwin_rules_dialog` which currently provides
only the rule edition dialog by embedding `RulesEditor.qml` within a
QQuickView.
This MR changes that behavior to call the full KCM from the menu.
The code to match previous rules, or compose a new one based on window
properties has been ported to the KCM from the dialog, so the overall
interaction is similar.
It has several advantages:
- uses only one entry-point to the code
- adds discoverability to the full KCM (I guess many users know how to
create a rule, but not where to delete it later)
And a drawback:
- only one instance of the KCM can be called at a time, so it will show an
error when calling it from two different windows, or if the KCM is open
in System Settings
This drawback can be solved after adding argument passing via dBus in KCM
infraestructure.
BUG: 433837
CCBUG: 417923
This reverts commit ee54fa7898.
Unfortunately, this is not a totally correct fix. If there's no pointer,
we need to announce the wl_pointer capability anyway so clients that do
not support tablet input devices can still receive emulated pointer
events.
Otherwise drmModeAtomicCommit() in DrmOutput::doAtomicCommit() fails due
to unmatched buffer sizes.
While rendering continues working properly, this makes drm freak out and
try to go back to a previous state (see the test commit in
presentAtomically()) that in turn starts issuing screen events to every
process even though it's just to say the same thing. The fact that this
happens per frame makes the system unusable as soon as fullscreen starts
happening on a scaled display.
Another thing we could do is get EglGbmBackend::scanout() to take care
of the resizing.
Our wayland interface lifespan only needs to live as long as the window
is mapped.
Given this corresponds directly to the lifespan of AbstractClient we can
just set a parent and everything is handled implicitly.
Prevent KWin from synchronously autostarting kactivitymanagerd. Indeed,
kactivitymanagerd being a QApplication it will depend on KWin
startup... this is unsatisfactory dependency wise, and it turns out
that it leads to a deadlock in the Wayland case
We're now sharing most of the X11Client activity behavior accross all
clients. This allows to cleanup some of the existing virtuals and remove
quite a bit of code overalls.
Has to introduce an extra platform specific hook since X11Client
serializes the activity information in an atom and we will probably need
to do something similar on the Wayland platform at some point.
This allows us to start interacting with the activities with kwin
wayland. They are not restored properly accross sessions though since
nothing is really persisted and the session management still seems to
be amiss.
The Script class has a DBus API we want to export. At some point this
has got broken and the run method is not exported.
It's a bit messy with script subclasses also having other invokables
that we want to export to scripts, so an adaptor is used to keep things
separated.
The interface name has technically changed, but KWin was doing something
weird and using the same interface names for the manager. Fortunately
calling Plasma code doesn't specify an interface so this still works.
On Wayland, when the compositor sends a screenshot to the requesting
app, it encodes the screenshot as a PNG image and sends the encoded data
over the pipe. The requesting app (Spectacle) then needs to decode the
data.
The issue is that encoding PNG images is not cheap. This is the main
reason why Spectacle is shown with a huge delay after you press the
PrtScr key.
In order to fix the latency issue, we need to transfer raw image data.
Unfortunately, the current dbus api of the screenshot is too cluttered
and the best option at the moment is to start with a clean slate.
This change prepares the screenshot effect for versioned dbus interface.
Most of existing dbus logic was moved out in a separate class. In order
to schedule screen shots, the screenshot effect got some new API.
QFuture<QImage> scheduleScreenShot(window, flags)
QFuture<QImage> scheduleScreenShot(area, flags)
QFuture<QImage> scheduleScreenShot(screen, flags)
If a dbus interface needs to take a screenshot, it needs to call one of
the overloaded scheduleScreenShot() functions. Every overload returns a
QFuture object that can be used for querying the result.
This change also introduces "sink" and "source" objects in the dbus api
implementation to simplify handling of QFuture objects.
Note that the QFutureInterface is undocumented, so if you use it, you do
it on your own risk. However, since Qt 5.15 is frozen for non-commercial
use and some other Plasma projects already use QFutureInterface, this
is not a big concern. For what it's worth, in Qt 6, there's the QPromise
class, which is equivalent to the QFutureInterface class.
CCBUG: 433776
CCBUG: 430869
This provides the compositor a way to indicate what output is being
rendered. The effects such as the screenshot can check the provided
screen object in order to function as expected.
If the file descriptor of the DRM device is greater than FD_SETSIZE, the
stack will be corrupted. However, it is highly unlikely that we ever hit
this case because DRM devices are opened at startup of kwin, so the file
descriptors should small.
In order to prevent the potential stack corruption, this change replaces
the usage of select() with poll().
Unlike select(), the api of poll() is much more sensible. Back 20 or so
years ago the main argument against poll() was that it's not implemented
by all platforms. But, nowadays, it's supported on all major platforms.
This is a minor regression that was introduced with the refactoring of
Toplevel::opacity().
Previously, neither X11Client nor Unmanaged had to explicitly initialize
the opacity because it was queried from the net info object in
Toplevel::opacity().
With the refactored version, X11-specific opacity code was removed from
the Toplevel class. When starting to manage a window, the opacity must
be explicitly initialized.
BUG: 432744
-listen <fd> option is deprecated in favor of the -listenfd option. This
change makes kwin query whether Xwayland supports the -listenfd option
at build time. If the pkg-config file is missing, we'll use the old listen
option.
Some old platforms don't have atomic integer supports for 64-bit wise
integer.
As indicated in GPUVis:
// Erase all knowledge of this ctx so it can be reused
We can reuse numbers after end_ctx, so with we should be fine with
32-bit integer.
Let's use a 32 bit integer for context.
bind(2) expects its second parameters is a "const struct sockaddr*",
let's cast the "struct sockaddr_un*" to "struct sockaddr*" before
passing into bind(2).
SUN_LEN is a BSD extension that also implemented by GNU, let's define
_DEFAULT_SOURCE before including "sys/un.h".
When the monitor is created, the surface may already have child
sub-surfaces. The childSubSurfaceAdded signal won't be emitted for them,
we need to handle this case explicitly.
BUG: 433511
FIXED-IN: 5.21.2
In QJSEngine, QRect is an Object, which is correct. This means that we
cannot use simple assignment operator to copy geometries, we need to use
standard ways to copy Objects, such as Object.assign() or the spread
operator, which is not available in QJSEngine yet.
Summary:
QScriptEngine is deprecated for years and suffers bitrot.
Plasma hit one super major bug with it in 5.11.0 and has now ported
away.
Main porting notes:
- creating low level functions no longer exists
The old global functions are exposed on the ScriptedEffect instance
and then the QJSValue wrappers of the globalObject are modified to
trampoline the methods at a wrapper level.
- We can then use QJSEngine to automatically do argument error checking
rather than unmarshalling a QJSValue manually which significantly
reduces a lot of code.
- We can't make FPX2 a native type, so these are QJSValue args and
unboxed there.
Long term I want overloads for animate that take int/QSize/QPoint which
are native JS types, but that might be an API break.
Test Plan:
Hopefully comprehensive unit test which passes
Tested fade/fadeDesktop manually.
It's a very invasive change, so I expect some things will be broke
please help test any JS effects.
Reviewers: #kwin, mart, fvogt
Subscribers: fvogt, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14536
Otherwise if powerdevil for example is configured to turn screen off on
the power key press, we will turn it right back on when we get key
release event.
Suggested-by: David Edmundson <kde@davidedmundson.co.uk>
Currently, the wobbly windows effect assumes that the window data will
be updated on every repaint. However, there are legit cases when the
time diff between frames can be 0, for example when per screen rendering
is on.
If we are unlucky enough and the geometry of the window changes in that
very short moment, the mapping between window quads and the bezier
patch will be wrong. The window will most likely bounce back and forth.
In order to improve handling of that tricky case, this change makes the
computeBezierPoint() function take the "uv" coordinates rather than the
absolute "xy" coordinates of window vertices. This loosens the
connection between the real geometry of the window and the cached bezier
patch, and overall makes the effect's timing code more robust.
This can be also useful if the wobbly windows effect starts accumulating
time diffs and performing the integration step every N msecs with the
purpose of maintaining uniform "wobbliness" across different refresh rates.
BUG: 433187
