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.
NVidia GPUs can't render to linear buffers, so we can't force a linear modifier
for CPU rendering. The proprietary NVidia driver also can't map gbm buffers
with all formats and modifiers, so instead of mapping the gbm buffer, this
patch changes KWin to instead use glReadPixels for accessing the source
buffer
The main reasoning behind double buffering was to avoid InternalWindow's
copy of m_frontBuffer detaching. But it already detaches when the qpa
calls blitImage(). So remove double buffering to simplify the backing
store.
While the GLFramebuffer::blitFromRenderTarget helper un-applies the transformations
the rendertarget has, the effect is not written with that in mind. In order to keep
it working properly, blit without any transformations and only adjust the coordinate
system difference between texture and fbo
Previously, we showed the window switcher even if there was only one
window, or no windows.
Now, we show the window switcher only if there are two or more windows.
Note that "desktop" counts as a window when the switcher's "show desktop
mode" is enabled.
BUG: 370396
BUG: 419408
Previously, we always added the desktop to the client list when the list
was empty. We added it even if the switcher's "show desktop mode" was
disabled.
Now, we only add the desktop to the client list if the switcher's "show
desktop mode" is enabled.
There are use cases for the headers to be used, e.g. when implementing
wayland-specific workflows from an Effect.
In order to be able to use these, we also need to expose libkwin to be
imported as it carries the interfaces' symbols.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Frame extents are written out over the wire they should be in X11 native
pixels.
i.e if we are using 200% scaling, and have X11 clients scale themselves
then from the point of view of the client reading the properties the
window decorations are twice the size as normal.
BUG: 471132
