The stream object was deleted from a slot connected to its stopStreaming
signal. This is unsafe and can lead to memory corruption and ultimately
crashes when PipWwire streaming is stopped. Use deleteLater instead.
BUG: 428268 435588
screen() only gets updated after AbstractClient::sendToScreen if invoked
by a shortcut or menu (as opposed to moveresize), so we can't use it in
AbstractClient::updateGeometryRestoresForFullscreen as it points to the
old screen.
With the introduction of stripped down window items, the WindowPixmap
objects no longer form a hierarchy. WindowPixmap::children() method was
removed.
Surprisingly, the removal of the children() method didn't result in a
compilation error because the QObject class has a method with the same
name.
Currently, a window pixmap will have no QObject children even if the
associated wayland surface has child sub-surfaces. This may result in
blank thumbnails of apps that use sub-surfaces, e.g. Firefox. In order
to fix that issue, we need to check if there are child items instead.
We'd always get "0x0: something" where the 0x0 is the xcb_window which
obviously doesn't translate.
Instead show the class name so we can easily track what kind of object
we are dealing with.
It's an easy way to show which shell it's using on Wayland, will be
useful in other cases as well.
If a decoration is created for an already mapped maximized window, check
the workspace position to ensure that the window still fits the maximize
area.
BUG: 432326
Currently, output properties are looked up either on the wl_output
object or the output device object. This puts a hard dependency on the
wayland server in the platforms.
This change intends to fix some flaws in the current output
abstractions, and allow creating/destroying wayland-specific globals as
we wish.
With the work done in this patch, the need for the AbstractWaylandOutput
class is unclear, and it might be a good idea to merge it with the base
AbstractOutput class.
This is to ensure that isNormalWindow() returns false for popups. One
could argue that we abuse netwm window types, on the other hand, we
don't know the exact type of popups and NET::Unknown is the closest type.
Re-use Qt's implementation of handling non-Latin layouts here
For full ASCII range support (Alt+`, etc.) Qt needs to be patched still,
see QTBUG-90611
BUG: 375518
I consider this a prerequisite commit to improving the quality of touchpad gestures provided by KWin.
In short, this breaks apart a weird all-in-one class into an std::variant for the different types
of shortcuts in order to make it easier to add new types of global shortcuts. For the byte shavers, this
roughly halves the size of the GlobalShortcut class as well. On top of all this, the code is about half
the size it was before, mostly due to newer C++ concepts being used that allow us to let the compiler
do more work for us.
Currently, we inhibit renderloops when switching to another TTY, and unhibit
when switching back. When we hotplug a display while switched to another TTY,
its renderloop isn't inhibited by default, yet when we switch back, we try
to uninhibit the fresh renderloop, which triggers an assert.
Inhibiting newly created outputs while switched to another TTY fixes this crash.
BUG: 435388
FIXED-IN: 5.21
The connector name is not relevant to applications or
users - expectation is that the same physical monitor always gets the
same name, regardless of how it's connected. If no serial is available,
fall back to the old scheme to prevent multiple connected outputs from
having the same name.
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.
