This reverts commit fd04fe04c0.
This change wasn't technically wrong, but presents an awkward developer
API until the point where we can port *all* PlasmaComponents to their
upstream QQC2 versions, and as such, it was premature.
Basically:
- PlasmaExtras.Heading -> Kirigami.Heading
- PlasmaComponents3.Label -> QQC2.label
We can do this because these components only existed in the past to use
special Plasma colors, but no visual styling. And the color stuff is
obsolete because Kirigami colors work correctly in Plasma now.
Everything was tested with a dark Plasma theme and a light color scheme
to ensure no regressions.
At the moment, the SurfaceItem needs to track individual properties that
may contribute to the buffer source box. That's error prone.
To fix that, this change makes the SurfaceInterface indicate when the
source box has changed and the SurfaceItem should sync its source box,
discard quads, etc.
Pending buffers for drm planes and crtcs are no longer tracked in the planes
and crtcs themselves, but instead in a DrmCommit object that is used as
the user data for the pageflip handler. This way multiple commits can be
pending at the same time without causing conflicts, and the handling of
pending buffers is simplified as well.
With color management, the main framebuffer has values over 1. As the effect used GL_RGBA8 for its
fbos, all values in them got clamped to 1, making the result look much darker than it should be. To
fix that, this commit changes it to use the same format as the main framebuffer, ensuring that the
range of values that can be stored is the same
This separate thread submits commits as late as possible, so that until
immediately before vblank the cursor position can still be updated, reducing
its latency and opening the door for more optimizations.
Vscode starts with a valid source rect but it resets it eventually by
calling wp_viewport.set_source(-1, -1, -1, -1).
On the other hand, `current.viewport.sourceGeometryIsSet` would be true
if that happens.
SurfaceInterface::bufferSourceBox() should use the buffer size when the
source rect has been unset otherwise the damage handling code will be
confused and it's likely that the scene won't issue repaint requests.
At the moment, graphics buffers coming from wayland and internal windows
use different code paths to update textures. However, they don't have
to.
If the internal windows are ported to GraphicsBuffer, it will be
possible to unify SurfacePixmapInternal and SurfacePixmapWayland to make
pixmap logic a bit simpler.
The buffer source box is synchronized when the surface-to-buffer matrix
changes. However, when using 100% scaling, it's likely that the
surface-to-buffer matrix will be identity and therefore no corresponding
signal to indicate the change will be emitted.
To fix that, we need to update the buffer source box also when the
buffer size changes.
In some cases, it's desired to know what the inverse transform of a
given output transform is. It's possible to make it work by providing
helper functions, but we tend to avoid doing so.
This change converts the OutputTransform from an enum to a class so it's
possible to have both data + methods in the same type. Unfortunately,
unlike Rust, C++ provides no way to attach methods to enums, classes and
structs is the only way to go.
Being in the KWin namespace has a couple of advantages: the enum can be
forward declared, and the transform can be replaced with a slightly more
complex but useful type.
If the surface item's contents is scaled, i.e. its scale factor doesn't
match the output's scale, GL_LINEAR will be applied to smooth the
contents. The unfortunate thing is that it's possible some of the
changed pixels will bleed to the neighbor ones.
In order to handle that scenario better, this change makes the
SurfaceItem expand the damage if there's scale factor mismatch.
bufferSourceBox and bufferTransform properties were introduced to detect
if the surface contents is going to be scaled. bufferSourceBox covers
both crop transform from wp_viewport and scale factor from wl_surface.
bufferTransform is same as wl_surface's buffer transform property.
The bufferSourceBox provides a way to get the source region of the
attached buffer. It can be used to compute the effective scale factor
when using wp_viewport.
We want the platform cursor to have roughly the same lifespan as the
application.
By using QObject parent mechanism, this gets deleted after the
Application destructor in the QObject destructor.
This causes an issue that removing an event filter (used by the X11
cursor) calls into the application singleton which is no longer valid.
BUG: 465970
We only have one KWin script making use of this and that one is shown
regardless. The issue with this flag is that it will hide scripts from
the user without a possibility to see them.
For effects, we have quite a few internal ones and a possibility to show
even hidden ones. But we can not reuse this logic for the scripts.
BUG: 458572
FIXED-IN: 6.0
if usb device is the primaryGpu, the device unplug kwin_wayland exit
` } else if (device->action() == QStringLiteral("remove")) {
DrmGpu *gpu = findGpu(device->devNum());
if (gpu) {
if (primaryGpu() == gpu) {
qCCritical(KWIN_DRM) << "Primary gpu has been removed! Quitting...";
QCoreApplication::exit(1);
return;
} else {
gpu->setRemoved();
updateOutputs();
}
}`
With simpledrm, only linear modifiers are supported, but with llvmpipe, only
implicit modifiers are supported. As it's still possible to allocate linear
buffers without modififer support by using GBM_BO_USE_LINEAR, this commit fixes
that problem by adding linear modififers to the supported list.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
When streaming direct scan out we take the layers texture directly.
When setting the contentTransform we discard the mirrorY transform that
we know is set on DMA bufs. This results in recording being upside-down.
