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
