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
