The value that the DrmCrtc::resIndex() function returns is better known
as "pipe index." This change renames the method to match the terminology
used by kernel developers and other compositor developers.
drmModeGetPropertyBlob() may return null and we should handle that. In
addition to that, m_conn is not initialized in DrmConnector so kwin will
crash whenever the connector info is accessed.
This introduces the markedAsZombie signal, which is emitted when the
window is about to become deleted. The X11SurfaceItem uses this signal
to determine when the damage must be destroyed.
Currently, dealing with sub-surfaces is very difficult due to the scene
design being heavily influenced by X11 requirements.
The goal of this change is to re-work scene abstractions to make improving
the wayland support easier.
The Item class is based on the QQuickItem class. My hope is that one day
we will be able to transition to QtQuick for painting scene, but in
meanwhile it makes more sense to have a minimalistic internal item class.
The WindowItem class represents a window. The SurfaceItem class represents
the contents of either an X11, or a Wayland, or an internal surface. The
DecorationItem and the ShadowItem class represent the server-side deco and
drop-shadow, respectively.
At the moment, the SurfaceItem is bound to the scene window, but the long
term plan is to break that connection so we could re-use the SurfaceItem
for things such as software cursors and drag-and-drop additional icons.
One of the responsibilities of the Item is to schedule repaints as needed.
Ideally, there shouldn't be any addRepaint() calls in the core code. The
Item class schedules repaints on geometry updates. In the future, it also
has to request an update if its opacity or visibility changes.
This makes the logic that determines when Xwayland windows can be marked
as ready for painting more robust.
At the moment, we call setReadyForPainting() when the surface is damaged,
but we want Toplevel stop managing damages.
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
There are a couple of reasons not to use the lambda:
* It is unnecessary. The DrmGpu has the DRM file descriptor
* If a crash occurs somewhere in the lambda, the backtrace will be hard
to read
* Instead of processing events in the destructor of the DrmBackend
class, we should keep dispatching events without involving
QCoreApplication::processEvents() until all page flips are completed.
There seems to be an interval between when you copy something from a Wayland
client and when you attempt to paste it into an X client where m_chunks.first().first
is empty, and trying to access its .data() will cause an assertion. While we can't
really gracefully handle this situation, we can at least terminate the function early
and turn the paste operation into a noop instead of a crash.
I just had that crash, this is what coredumpctl suggested it was
happening.
We don't need to make sure we're in dmabuf mode to remove the buffer.
Worst case scenario it won't remove anything. Check the spa_data before
querying in case it's null.
qEnvironmentVariableIntValue() will return 0 if the specified variable
is not set.
This means that swap events will be disabled on AMD GPUs unless the env
var is set explicitly to 1.
This is in a way working around bad protocol, input-method-unstable-v1
and also input-method-unstable-v2 does not have a way for input-method
to mark itself as "deactivated". This can happen when e.g. user closes
the virtual keyboard using swiping down or "close keyboard" button in
keyboard.
When this happens, the state between compositor, text_input and
input_method gets out of sync, compositor does not know that input
method got deactivated and hence it will continue sending various events
to it. The quick way around it is to change focus, which makes
compositor send deactivate request to input-method, that puts compositor
and input-method in sync again.
This patch aims to solve this by tracking the last state of input
method, If we know that input method is active and text input sends us
the show event, we toggle the input-method.
I will re-iterate that this is in no way proper solution, ideally
input-method-unstable-v3 or input-method-unstable-v2 even (since it is
not upstream anyway) gains the new request which essentially allows
input-method to sync enabled/disabled state with compositor.
The contents of the if branch is identical to the implementation of the
Toplevel::damageNotifyEvent() function and setReadyForPainting() will
never be called because m_syncRequest.isPending can be true only if the
window supports sync counters.
In case the compositor wants to cancel a touch sequence, we need to
ignore subsequent touch motion and touch up events until a new sequence
is initiated by the user.
Previously, it was implicitly handled by clearing the mapping table
between the touch slots and touch ids generated by kwayland-server.
At the moment, the display name might change between Xwayland restarts.
It is a problem because the session process (plasma) may have an
outdated value of the DISPLAY environment variable after a restart.
With this change, it is guaranteed that the DISPLAY and the Xauthority
file stay the same until the server is stopped explicitly.
Since QWindowSystemInterface::handleScreenRemoved would not be called in Integration::handleScreenDisabled, Qt apps would still reference disabled screens resulting in crashes.
Previously the text values were updated to the model after
`onEditingFinished()`, that is after losing focus, to prevent
erroneus updates.
This was making also the `needsSaving` signal fire only after
a focus change, which is not consistent with the behavior of
other KCMs.
Use `onTextEdit()` instead, so the model is updated as the user
types.
BUG: 431211
Currently the highlight is only for the items. KCModuleData will come in another MR.
This is more simple implementation than the one I previously made.
Some default value are hardcoded in the KCM such as Rows count (2) and the number
of virtual desktop, on revert to default, it keeps only the first one.
Since kwin runs as a normal user, it cannot create the X11 connection
socket directory because any user process can easily compromise the
security of the system by unsetting the sticky bit.
In order to guarantee the security of the system, the socket directory
must be created by root and have the sticky bit on.
This adds a command line tool which allows the user to set the window
decoration, and then that tool is used in the two knsrc files to allow
the user to switch window decoration directly from either a KNS dialog,
or from Discover.
Xwayland starts listening to -listenfd file descriptors after the WM_S0
selection is claimed. At the moment, it is claimed asynchronously by
kwin. First, we create a dummy window and change one of its properties
to get the timestamp. After the timestamp has been received, we actually
call xcb_set_selection_owner().
This provides kwin greater control over how X11 sockets are created for
Xwayland. For example, it can be used to ensure that the DISPLAY remains
the same across Xwayland server restarts or launching Xwayland on
demand.
Even though -listen <fd> option is deprecated, we still pass it because
older versions of Xwayland may not have the -listenfd option.
This renames updateXauthorityFile to writeXauthorityEntries as it doesn't
actually update (i.e. change) anything, it just writes new ones.
Error handling is introduced, to avoid that it continues silently without
entries, which would cause all connections to fail.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
