An EDID can contain zero or more detailed timing definitions, which can contain
more precise physical dimensions of the screen (in millimeters, as opposed to
centimeters).
The Xorg server has similar logic for determining the physical screen size from
the EDID: pick the first sane size from the detailed timing definitions, and
fall back to the screen size given in the "Basic Display Parameters & Features"
section.
BUG: 486585
Apparently people have differing ideas of what "vertically" and
"horizontally" mean, and some feel that this wording contradicts the
icon.
That's not accurate, but the wording is admittedly a little a bit
ambiguous. We can clarify this by using super duper explicit
terminology that always matches the icon.
BUG: 475103
FIXED-IN: 6.1
If the slow transition is scheduled slightly earlier before m_next.first,
don't skip the "m_prev.first <= todayNow && todayNow <= m_prev.second" branch.
Also explicitly handle the case when resetSlowUpdateTimers() gets called
after m_prev.second, i.e. the previous transition has finished running.
Due to QTimer sometimes firing a tad bit early, transitions get skipped, or we
end up in the "Error in time calculation" branch. This commit improves timer
handling to avoid this.
We do not snap to docks (i.e. panels) since the ones we
actually want to snap to (i.e. always visible ones) will
restrict the workspace area, and the window will snap to
that, effectively snapping to the panel too. Explicitedly
avoiding panel snapping solves any possible issue of
floating panels, since they change their size when a window
gets near them.
The communication between the compositor and plasmashell is asynchronous.
It's possible that plasma can call get_window_by_uuid before it is notified
that the window has been closed. There's no any way around with the
current design of the protocol. So printing a warning message is
unjustified. This fixes kwin's logs being full of "could not find window"
warning messages.
After receiving a drop a client should call data_offer.finish
to tell the source it's done using the drop.
A client could delete an offer after drop before calling finish.
This can happen with misbehaving/buggy or malicious Wayland clients.
A real case was found in the wild with Chromium, as described in the
linked bug.
In this situation we should let the source know the dnd is finished
as there are no other transfers than can take place.
We don't want to universally send this in all data offer destructors
only, offers that are deleted post drop so the flag on the source is
exposed.
BUG: 482142
Currently, the dmabuf format is hardcoded to DRM_FORMAT_ARGB8888, but
testCreateDmabuf() uses m_drmFormat.
Furthermore, if the shm buffers are used, it's preferred to use a buffer
format that's friendly to QImage and OpenGL, which is DRM_FORMAT_ARGB8888.
It appears like pipewire can ask kwin to allocate a drm buffer even
though m_dmabufParams has been reset. It's underspecified when pipewire
will start requesting new buffers after changing the stream params. So
use the last reported video info to allocate buffers. If even it is wrong,
then it's an issue somewhere in pipewire.
Right now the opening duration is 150ms, and the closing duration is
250ms. Neither are standard durations we use elsewhere, and it's also a
bit odd to be slower to close than to open--at least from a visual
perspective.
The average of these value happens to be 200ms, which happily is the
exact value of Kirigami.Units.longDuration.
As such, use that value instead, in the interests of visual consistency.
Enabling this feature makes Xwayland send xtest events via
the remote desktop portal and libei.
XWayland will create a new session for each X client (it keeps
contexts around and reuses them if the cmdline matches, so not
every xdotool invocation produces a new portal prompt).
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.
