Avoid using Window::frameGeometry() because its position is invalid.
In the future, the XdgToplevelWindow would need to run the placement
code before updating the Window::frameGeometry(). In order to prepare
for that, this change also makes placeSmart() pull the window size from
a cached QSizeF() object.
Avoid using Window::frameGeometry() because its position is invalid.
In the future, the XdgToplevelWindow would need to run the placement
code before updating the Window::frameGeometry(). In order to prepare
for that, this change also makes placeCascaded() pull the window size
from a cached QSizeF() object.
The main motivation behind this change is to ensure that every placeXyz()
function issues only one move() or moveResize() function so the placement
code is more refactorable, and in general, it's a good idea to avoid
changing the geometry until the final geometry is finally known.
Note that it changes the behavior of placeOnMainWindow() and
placeUnderMouse(). Those methods will not anymore potentially resize
the window. It was done to avoid a flicker glitch on Wayland. This is
the responsibility of the caller (X11Window) to further inspect whether
the window needs to be resized. However, for now, let's keep things
simple and revisit this if somebody actually complains about it.
Workspace::cascadeOffset() can be called by placement code before the
frame geometry has a valid position. That is wrong. In order to avoid
that, use the placement area that we are given.
When the user closes the active window, with separate screen focus disabled, a
window on the other screen might get activated, which also switches the active
screen to the other one. As this is quite unintuitive, and in my testing having
separate screen focus enabled didn't have any other unintuitive side effects,
this commit enables separate screen focus by default
Instead of just clipping when HDR content is brighter than the maximum luminance the
screen can show, when HDR metadata indicates this could happen, KWin now
- converts the rgb colors to ICtCp, to split luminance and color
- applies a tone mapping curve that maps the intensity component from
- [0, reference] to [0, newReference] linearly
- [reference, max content luminance] to [newReference, max display luminance] nonlinearly
- converts the resulting ICtCp color back to rgb
The result is that HDR content looks much, much better on SDR displays, at least when decent
HDR metadata is provided.
As wrong metadata could cause this tone mapping to wrongly kick in in games for example, the
environment variable KWIN_DISABLE_TONEMAPPING is provided to disable tone mapping and fall back
to clipping again instead.
If effects->grabKeyboard() fails and effects->ungrabKeyboard() is called
later, kwin will crash due to an assert in the ungrabKeyboard() function.
This matters only on X11.
It's more readable and it also makes code more refactorable. For example,
if somebody makes Workspace::stackingOrder() return a normal QList, KWin
won't crash at this code.
The synthetic ConfigureNotify event is not sent when the stack mode is
TopIf and BottomIf, i.e. the way the restackWindow() function handles
the "send_event" argument is inconsistent.
And the window manager doesn't have to send a synthetic configure event
when processing a _NET_RESTACK_WINDOW client message. It must do it only
after handling a ConfigureRequest request, which
the X11Window::configureRequestEvent() function already does.
So rather than fixing the handling of the "send_event" argument, this
change removes that boolean trap instead.
The first item in the `chain` list corresponds to the last item in
the focus chain. The last item in the `chain` list corresponds to
the first item in the focus chain.
Given that, we need to traverse the list from the start to the end in
order to find the first window owned by the same app as `reference`.
Whenever tearing is desired, this does an atomic test to figure out if the current
configuration can do tearing - if not, the backend just transparently falls back to
synchronous commits.
As the kernel (as of Linux 6.9) rejects all commits that are both async and modify
more than the primary plane FB_ID property, this disables the cursor plane and
IN_FENCE_FD usage, to make it more likely for the atomic commit to succeed.
Once these restrictions are loosened, these checks can be removed as well.
Boolean traps are a code smell that makes code harder to read and it
also usually makes the api more difficult.
The force == false is used by two places:
- in Workspace::restackWindowUnderActive()
- and in X11Window::restackWindow()
Technically, the restackWindow() function doesn't need the force == false
behavior because the stackBelow() function is used in code paths where an
explicit sibling is provided.
The restackWindowUnderActive() function is trickier, it is used in the case
when kwin rejects to raise a newly mapped window, so for that purpose, I
changed the function so it picks the lowest window that belongs to the same
application as m_activeWindow.
The result of this change is that the stackBelow() is simpler and its
behavior is much more predictable, which is important when analyzing the
code that updates the stack.
Above and Below modes should be handled as follows:
if (sibling) {
workspace_stack_below/above(window, sibling);
} else {
workspace_lower/raise(window);
}
But with the current code, it's difficult to see. This change rearranges
the code in the restackWindow() so it's more clear how the Above and the
Below modes are implemented.
It also moves workspace()->findClient(Predicate::WindowMatch, above); to
the top because all branches have it.
There are several ways how a window can be restacked relative to another:
either by placing it below the reference window or above the reference
window.
Currently, the restack() function places the given window below the
refererence window. But it's hard to decipher from the name, one needs
to take a look at the argument names to understand what's going on.
Another reason to rename is that it could be useful to have a stackAbove()
function to make X11Window::restackWindow() implementation simpler and
more straightforward.
The shape region is used to clip the window contents. But, in practice,
it's used by a few applications. The most notable is xeyes.
The APIs that the shape region requires are manageable, but it would be
much preferred if we had a much simpler design.
In terms of the shape region support on Wayland, it's not widely
supported across all wayland compositors, to my knowledge, only two
support it, some compositors even want to disable XSHAPE extension at all.
This change makes the Xwayland windows ignore the shape region to see if
any real world applications are affected by it. If not, then we could
safely simplify the scene bits later.
The Xorg session is unaffected by this change.
It's used only by the decoration renderer, but even it doesn't need it
because the atlas parts are padded.
From the API point of view, it's worth looking for alternative solutions,
like integrating the render target clear step in the render passes. And
texture uploading code usually doesn't need to clear the texture because
it is going to overwrite its contents anyway.
The shared memory buffer may need to install a SIGBUS handler if the
compositor _may_ access the data outside of the buffer.
However, signal handling requires great care. For the simplicity sake,
only one shared memory buffer is allowed to be accessed at the time.
But such a restricted access policy is inconvenient and requires us
making client buffer contents copies.
This change eases the restrictions on map() and unmap() functions so
several buffers can be accessed simulatenously.
Note that atomic pointers are used because a signal handler can be
invoked at any point in the main thread's execution. Even though
"a = b" is a single operation from the developer's pov, it can take
several steps for the CPU to store a new value to the variable. The
atomic pointers ensure that assignments to the next and s_accessedBuffers
happen atomically.
Also keep in mind that we cannot start removing copy() calls yet
because the ShmClientBuffer life time management requires further
changes, which I believe, are out of the scope of this patch.
ShmClientBuffer needs to hold a reference to the old memory
map while the buffer is mapped. Currently, it's not a problem
because unmap() must be called soon after map(). But in case
we relax that constraint, shm_pool.resize() can change the
memory map in the ShmPool with a new one, which can cause issues
for the SIGBUS handler because it won't be able to find the
right mapping object.
This is needed to ensure that the values passed to GL_UNPACK_ROW_LENGTH
are reasonable. It's not described in the spec but wlroots already does
the same.
The main motivation behind this change is to make the ItemRendererOpenGL
use a homogeneous coordinate space for texture coordinates in order to
simplify rendering code.
The device pixels have been chosen because they are more agnostic about
the graphics api.
The main motivation behind this change is to make the ItemRendererOpenGL
use a homogeneous coordinate space for texture coordinates in order to
simplify rendering code.
The device pixels have been chosen because they are more agnostic about
the graphics api.
On X11, the stack order of a window can be changed in multiple ways:
- Opposite
- TopIf
- BottomIf
- Above
- Below
You would pass either of those modes plus maybe the above window id. For
this crash, the relevant mode is Above.
Since the Workspace only has one restack function that places the given
window right under the reference window, the Above stack mode
implementation performs a quirk: it walks through the stack in order to
find a window right above the reference window and pass it to the
restack() function.
However, it could be that the window that wants to be restacked is already
above the reference window, so that same window would be passed as the
"under" window to the restack() function.
It's nothing but a miracle that we have not received major complaints
about this issue until now.
The restack() function doesn't like `window` and `under` to be the same
because of code like
unconstrained_stacking_order.removeAll(window);
unconstrained_stacking_order.insert(unconstrained_stacking_order.indexOf(under), window);
The removeAll() function would effectively remove both `window` and `under`
from the unconstrained stack, which breaks the next line because the
indexOf() would return -1, i.e.
unconstrained_stacking_order.insert(-1, window);
This is the reason why the unconstrained_stacking_order contains strange
values such as `0xe`.
In order to fix the crash, this change adds some code to short-circuit
the restack() function if the passed in window and the reference window
are the same. It would be great to clean up X11Window::restackWindow()
and also add ergonomic restack functions in the Workspace, but this can
be done later. The major blocker is lack of proper test coverage of
X11 bits at the moment.
Last but not least, I would like to express my profound gratitude to
Peter Strick for filing the crash report AND providing a VM image that
helped massively with reproducing the crash and finally fixing it.
BUG: 491618
It's leftover after the Deleted type. The unmanaged window will be
removed from the stack when all its references are dropped and
Workspace::removeDeleted() is called.
CCBUG: 491618
The image stride can be other than "width * bpp". In order to properly
handle such a case, we need to set GL_UNPACK_ROW_LENGTH to skip the right
amount of pixels between consecutive rows.
Co-authored-by: Gabriel Souza Franco <gabrielfrancosouza@gmail.com>
Some clients have two or more completely opaque surfaces stacked on top of each other,
optimizing the lower ones out makes direct scanout happen more often and more efficiently
when multiple planes are involved
