n_datas must match the plane count in the graphics buffer. But apparently
pw buffers with wrong n_datas can still slip through somehow. It makes
the screen cast stream crash when filling in buffer data.
The crash is hard to reproduce, but on the other hand, according to
sentry, a substantial number of users is affected by this issue.
Taking the defensive approach is not great, there will likely be other
issues with screencasting, but it seems like the only feasible option
so far. Broken streams is better than kwin crashing. It also wouldn't
hurt to add some warning messages, that will be done in a follow up MR.
Otherwise the effect of night color is much bigger in larger colorspaces.
This is mostly a workaround, but the better solution (adapting the color
temperature of the colorspace instead) will have to wait for 6.1
BUG: 483801
FIXED-IN: 6.0.5
With multiple OpenGL render time queries, you can't just add the render
times together, because the GPUs execute commands asynchronously and you
may get a far too big result this way. Instead, this converts all timestamps
to steady_clock and correctly calculates the actual total time spent rendering
with the first and last timestamp.
The GL renderer currently doesn't apply any transformations except clipping,
so allowing direct scanout is okay as long as colorimetry and transfer
function match.
After porting to KConfigXT settings some time ago, there was still an
inefficient and error-prone codepath between the `RuleBook` (which keeps
the runtime list of `Rules`) and the `RuleBookSettings` (responsible for
config reads and saves), in the form of the `setRules()` method.
We can eliminate the `setRules()` codepath, reducing unnecessary
runtime process and file access operations, and instead:
- Keep track of the config `id` in the `Rules` objects
- Keep a single `RuleBookSettings` object as a member
- Modify or delete the discarded rules settings directly
- Save when necessary
This also fixes two bugs/pitfalls of the previous solution:
- the config group id for each rule is now preserved instead of creating
new ones
- no leftovers on the config file for the discarded groups and entries
Setting custom configs for the integration tests still works unchanged.
BUG: 446381
FIXED-IN: 6.1
Damage reported from the output is output-local and therefore doesn't
need to be translated.
I tested this with Chromium, where the damage region on my 3-monitor
setup was always -4k something on the right screen, -2k on the middle
one and correct on the left screen. With this change I can confirm that
the position is now correctly reported for the right screen.
Our connection to pipewire can go down if the pipewire service restarts, it's on us to tear down and reconnect.
To ensure Streams can tear down on their own properly, this patch leaves existing streams with a defunct connection
and creates a new connection for new streams, sharing the connection between them.
This also implicitly fixes the case for distributions without working socket activation.
BUG: 483137
Unless there is no focus window. Matches X11 behavior.
Otherwise (re)starting plasmashell would pull focus away from
whatever window is currently focussed.
To clarify that the toggle action merely temporarily disables the blue light filter, rather than turning the schedule off permanently like the "Disbaled" setting in the KCM does, use "suspend/resume" terminology instead of "off/on" in the keyboard shortcut and OSD.
Follow-up on plasma-workspace!4262
CCBUG: 486647
Include a warning if we are ever setting an invalid value, this can save
some of us quite some time in the future, since failing to fall in the
range makes the whole pipeline become rejected.
This is in part a workaround for an issue in Qualcomm drivers where the
range for alpha is 0-UINT8_MAX (255). We were setting a value too big
and this would make the whole pipeline fail.
Instead set the top of the property range which is what we were doing
after all, resulting in more explicit code to what we were trying to
achieve.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Deleted windows have frameId zero, which makes Xorg stack other windows
below the bottom-most window instead of the correct one. To avoid that,
filter out deleted windows in Workspace::propagateWindows.
BUG: 478556
There were two problems preventing it from working:
1. The placement tracker didn't handle them correctly; now it sets the custom tile mode
after moving the window to its location
2. The window code used `output()` instead of `moveResizeOutput()`, which means when KWin
just moved the window to a different screen and immediately changes the tile mode
afterwards, it would tile the window on the wrong output
There were two problems:
1. Workspace interacted with the tile mode of windows before inhibiting
the placement tracker, so the wrong window state was stored in the placement
tracker
2. Window::setQuickTileMode is unintuitive and has some undesired side effects,
meant to handle quick tiling with keyboard shortcuts and by dragging the
window with a mouse specifically. This commit just works around that by
un-setting the tile mode first
BUG: 461886
If the X11 socket directory has wrong permissions, XwaylandSocket will
refuse to create sockets. Crashing in that case is undesired, just continue
executing without X.
It seems that, on some systems (such as on mine), 1s is not long enough
for a spurious disconnect and reconnect to happen. 2s seems enough,
however, while still likely not being long enough to cause user
confusion.
BUG: 480026
Process the geometry update as usual but just avoid confuguring the x
windows. It simplifies the implementation of the move resize function
and makes it more refactorable.
GeometryUpdatesBlocker is unnecessary. One could just compute the
final geometry on a side and then issue one moveResize() rather than
call move(); resize(); moveResize() and so on in a sequence. The
advantage of the former approach over the latter is that the code
can be a bit more straightforward.
When a window is closed, its geometry should not change, so the geometry
updates blockers are not needed. There's also no code that could potentially
change the geometry in destroyWindow() or releaseWindow().
