Xwayland windows have two geometry types that are used during rendering
- wl_surface's geometry and x11 window's geometry. Unfortunately, it's
not possible just ignore the x11 window geometry because the window may
have a custom shape region. Pixels outside the shape region can have
arbitrary values; it's not guaranteed that the area outside the shape
region will be transparent.
In some cases, the x11 window geometry can be larger than the wl_surface
rect. That breaks repaint logic as the SurfaceItemXwayland can draw
outside the bounding rect.
Specifically, this issue can be seen while resizing Steam interactively.
Another example is where a video game enters fullscreen mode. I
occasionally see that Red Dead Redemption II window leaves a ghost after
itself when it switches to fullscreen mode.
It's not a perfect solution, but on the other hand, it doesn't look like
there's a better way to handle this due to the fact that there are two
conflicting geometry sources.
If a QObject is exposed to js using QJSEngine::newQMetaObject(), a new
instance of it can be made only with constructors exposed by Q_INVOKABLE
At the moment, QTimer's constructor is not Q_INVOKABLE, so code such as
`const timer = new QTimer()` will not work.
BUG: 439630
FIXED-IN: 5.22.4
If the client had created an xdg-toplevel-decoration and has called the
set_mode() request with csd before the initial configure event is sent,
we still need to send an xdg-toplevel-decoration configure event with
csd mode.
If the output transform changes, the geometry may change as well;
otherwise qpa may not call QWindowSystemInterface::handleScreenGeometryChange()
with the corresponding platform screen.
If the visiblityChanged signal is emitted and then the window is
immediately destroyed, the slot will still be executed because the
connection has type of Qt::QueuedConnection.
DrmPipeline is now what contains all the thing related to drm calls,
instead of DrmOutput. This allows for some more flexibility and tidies
the code up a bit. Additionally instead of rolling back changes if
presentation fails, changes are directly tested with atomic test only
commits.
In order to not make misdetections with sub-pixel movements the gesture
recognizer completely ignored those. This fails however when you move
your fingers very slowly, so instead accumulate the delta and only use
it for direction detection if it's high enough.
According to the spec, if the wl_subsurface.place_below request is
called with the parent surface, the sub-surface must be placed below the
parent surface.
BUG: 438808
While always calling showCursor isn't a problem for when there's no
pointing device as the cursor image is empty in that case, it can
cause a temporarily stuck cursor image when it's supposed to be
hidden because of touch input
Originally, only x, y, width, and height property setters were used. A
bit later "position" and "size" helper setters were added to simplify
code in SurfaceItem sub-classes. It seems like setX(), setY(), setWidth(),
and setHeight() are unused now, so remove them.
The tablet protocol offers us the cursor in a surface. This patch makes
sure we connect to the surface so that we can also refresh the
representation if the client submits a change.
BUG: 437777
The XDamageDestroy has a weird requirement saying that it can be called
as long as the X11 window is still valid. On the other hand, one could
argue that it is more intuitive if the damage handle becomes inert if the
associated window is destroyed. Unfortunately, that's not the case and
as git history shows, it's an easy way to shoot yourself in the foot, we
had the exact warning many years ago.
The problem with the XDamageDestroy API is that it is simply unreliable
given the asynchronous nature of communication between kwin and xorg.
Anyway, with X11 sunsetting, let's destroy the damage handle only when
the X11 window is unmapped and not bother too much about it.
If a wl_eglstream buffer is attached to a surface, but then later a different
type of buffer, such as a dmabuf, is attached to the same surface, kwin will
mistakenly keep trying to acquire frames from the EGLStream associated with the
previous buffer. This can happen if an Xwayland window is made full-screen
causing it to switch to the flipping presentation path, for instance. The
result is that the window contents will no longer be updated.
Instead, the eglstream backend's loadTexture and updateTexture functions should
first pass the buffer to eglCreateStreamAttribNV. If it fails with
EGL_BAD_STREAM_KHR, that indicates it is indeed a wl_eglstream, and that we've
already associated a server-side EGLStream with it in attachStreamConsumer, so
we can proceed as usual. If it fails with EGL_BAD_ACCESS, though, that
indicates it is not a wl_eglstream and we should fall back to the parent class
which handles attaching other buffer types. If it doesn't fail at all, that
means the client tried to attach a new wl_eglstream to a surface without first
attaching the stream consumer. There's not really a great way to handle this,
so just re-use the previous EGLStream.
This is to ensure that both kwin and Qt use the same EGLDisplay. Note
that the native context handle can have no display, however it's very
unlikely to happen.
There are EGL implementations that will refuse to create a context if
the share context belongs to other EGLDisplay. Currently, that's the
case on some platforms.
If eglGetPlatformDisplayEXT() is called with the same parameters, it'll
return the same EGLDisplay. The main motivation behind this change is to
ensure that both kwin and Qt share the same EGLDisplay, QtXCB calls
eglGetPlatformDisplayEXT() without any additional args.
If EGL_PLATFORM_X11_SCREEN_EXT is not specified via attrs, the EGL
implementation will use the default screen, which is the same as
m_x11ScreenNumber.
