The security context appId is set by the launching container (i.e
flatpak) and is therefore more trustworthy than any other source of
application ID.
Use this when looking up allowed wayland extensions.
This allows KWin to securely identify the client for a given connection,
without relying on the process name.
This patch does not do anything meaningful with the application ID other
than store it.
This first version does not support kwin restarts, it can come
afterwards.
Testing done:
With latest flatpak, running `WAYLAND_DEBUG=1 flatpak run org.telegram.desktop |& grep security`
shows that flatpak itself bound the security context, and the client did not see it advertised.
libkwineffects was introduced when kwin used to be an executable. It
provided an api to implement effects and shielded from the technical
quirks in kwin.
Over the time, kwin internals had been split and abstractions were
refactored so they can be consumed in scripts or plugins. Besides that,
new ways to implement extensions have been introduced, which use
kwin's internal abstractions.
On the other hand, effects continue using libkwineffects specific apis.
This has a few issues: qtquick effects use both apis and it bites us,
duplicating same apis.
The best solution so far is to merge libkwineffects with libkwin, and
replace libkwineffects abstractions with libkwin abstractions, e.g.
EffectScreen -> Output, etc. This change takes care of adjusting libs.
Obviously, the main disadvantage of doing so is that binary effects
have to be recompiled every time new libkwin is released. But it's
already the case with libkwineffects too.
Instead of an external service (like KScreen) storing and restoring output configurations,
with this commit KWin takes over that responsibility. This allows it to, among other things,
generate appropriate configs for new sets of outputs immediately, and take KWin-internal information
about outputs into account when generating them.
CCBUG: 474021
CCBUG: 469653
CCBUG: 466342
CCBUG: 470863
CCBUG: 466556
BUG: 466208
BUG: 455082
BUG: 457430
Instead of hardcoding ARGB8888 and using implicit modifiers, look through
the list of available formats and modifiers and pick a match that egl will
actually accept.
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();
}
}`
* 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
This allows us to avoid losing precision when updating surface pixmaps.
Surface damage needs special handling either way.
Another advantage from switching to buffer damage is that it lets us to
decouple surface textures from surface items, which is useful for making
surface helpers more reusable.
Currently, the render node is hardcoded. It works okay as long as the
main device and the hardcoded node are the same. But it breaks on multi
gpu setups where the render device is not /dev/dri/renderD128.
As a first step to move away from having an external service remember output settings
for KWin, this commit introduces an output manager that can load configuration files
and generate new output configurations.
At the moment, the buffers for wsi are allocated implicitly by the EGL
implementation, which is fine for "normal" use cases. But we start
hitting the ceiling the moment we need to something more advanced. For
example the EGL backend creates a dummy fbo object wrapping the default
framebuffer, meaning that we cannot pass it to qtquick (because it can
use its own opengl context).
Another reason for using explicit buffers is that it lets us to clean up
some output related abstractions.
The internal window doesn't gravitate the geometry during interactive
resize so it can produce unexpected results when dragging the top-left
window corner.
Right now this is marked as critical, but it's not a critical error.
Make it a debug to avoid spamming logs with not-very-actionable
information.
BUG: 463259
FIXED-IN: 5.27
* Allow to do quick tiling to custom tile geometries, windows will be snapped to tiles when dragged with the shift modifier pressed.
* Tile geometries are screen specific.
* The global shortcut Meta+T will trigger a fullscreen configuration ui as a QML effect for the tiles which allows to add, remove and resize tiles
* UI and behavior is a bit similar to the Windows Fancy Zones addon: https://docs.microsoft.com/en-us/windows/powertoys/fancyzones
* Its main scope is to help the workflow with very big monitors, especially ultra wide ones, where most application don't make sense maximized to the full screen (eventually also support games to be full screened to a given tile instead of the whole screen)
* it should get also some bindings for scripting, as its ain goal is not to replicate other popular tiling window managers, but should give the popular kwin tiling scripts to have a more robust infrastructure
* it will eventually get support for a set of predefined layouts, but this is for a second phase
BUG: 438788
