Currently, there are a couple of issues with output querying on X11:
(a) if an output is changed, for example its transform has been changed,
then all outputs will be destroyed and created again
(b) it's possible to encounter the case where the platform has no
outputs. The X11Platform destroys all outputs, then queries new
outputs. The Workspace and AbstractClient sub-classes handle having
no outputs very poorly! It's even possible to hit a crash.
With this change, outputs will be queried similar to how it's done on
Wayland.
It's confusing to have globalPos() and geometry() as both can return the
same information.
This change drops globalPos() function as it's not used outside the
AbstractWaylandOutput class and renames setGlobalPos() to moveTo() to
avoid having a setter without matching getter.
IN_FORMATS contains information about which buffer formats can be
scanned out with a given drm plane. Using these plane-specific
format+modifier combinations as well as explicit modifiers in
general can yield bandwidth and performance improvements,
especially in multi-gpu systems.
We use surfaceless contexts with internal windows. We also require
the EGL_KHR_surfaceless_context extension for making context current
without outputs.
Arguably, we could use pbuffers, but since mainstream drivers (Mesa and
NVIDIA) support surfaceless contexts, the extra complexity doesn't buy
us anything.
In a recent refactor screens are only created when our xdg_surface has
been acked. This leaves a window where m_waylandCursor is null and
events are still being processed.
This further decouples scene items from scene windows. The SurfaceItem
still needs to access the underlying window, I would like to re-iterate
over that later.
With this change, it will be possible to introduce WindowItem factory
function in the Toplevel class.
toplevel.h is included in many places. Changing virtualdesktops.h may
trigger rebuild of all kwin.
With this change, only cpp files that use virtualdesktops.h will need to
be recompiled.
SceneOpenGLShadow::prepareBackend used to use QImage::Format_Indexed8,
plus a special code path in GLTexture, to create single-channel OpenGL textures.
Now that Qt supports QImage::Format_Alpha8, this workaround can be removed.
Currently, a vertex coordinate is transformed first, then mapped to
the global screen coordinates. This causes a problem if a transform
is applied to the top-most item and child items are not at (0, 0).
For example, scaled windows may have popping out sub-surfaces, etc.
With this change, the item transforms will be computed differently. For
example, if the parent item is transformed, a child's transform will
look as follows
[Parent's translation][Parent's transform][Child's translation]
instead of
[Parent's translation][Child's translation][Parent's transform]
In the future, I'd like to get rid of the Item::setTransform() call in
OpenGLWindow::performPaint() and have either AnimationEffect or
libkwineffects call Item::setTransform().
BUG: 440201
As per the xdg-shell specification, the compositor can only attach
a wl_buffer to an xdg_surface once the compositor has sent an
xdg_surface.configure event. Previously, there was a race condition
in which WaylandOutput objects were added/enabled on creation, making
it possible for the EglWaylandOutputs to be set up and for
EglWaylandBackend to draw a frame (thereby attaching a buffer), all
before the xdg_surface.configure configure event was received.
Compositors other than kwin would then send an unconfigured buffer
error and close the connection.
This commit avoids the problem by not marking the WaylandBackend
ready for use until all the output surfaces constructed at startup
have received their initial configure event. (In practice, this
takes one additional roundtrip.)
Blending is quite expensive especially with software rendering.
In the case of Firefox on Wayland, it uses a ARGB8888 buffer but marks the
entire surface as opaque, so the alpha channel can be ignored.
CCBUG: 440386
When the last output gets disconnected, create a virtual output as a
placeholder until we have access to a physical output again. While
this placecholder never gets rendered to, with virtual outputs in
general that is possible (with gbm and qpainter atm) and can be done
for future use cases like wireless displays.
CCBUG: 420160
CCBUG: 438839
https://invent.kde.org/plasma/kwin/-/merge_requests/1220
This reverts commit 44ad9437c4 because it
breaks build:
platforms/x11/common/eglonxbackend.cpp:224:66: error: cannot initialize a parameter of type 'EGLNativeWindowType' (aka 'unsigned long') with an rvalue of type 'xcb_window_t *' (aka 'unsigned int *')
surface = eglCreateWindowSurface(eglDisplay(), config(), &window, nullptr);
^~~~~~~
Makes it possible to apply the dpms settings per screen instead of
applying it to all of them, which is wrong at many levels.
Will be even more important with other effects like rotation.
Currently, the entire screen will be repainted when using the qpainter
render backend. With this change, kwin will repaint only the dirty parts
on the screen.
A better alternative is to return the damage region in the beginFrame()
function. This way, the render backend can force full screen repaints or
indicate what parts of the buffer needs to be repainted (for buffer age)
The main motivation behind the split is to simplify client buffer code
and allow adding new features easier, for example referencing the shm
pool when a shm buffer is destroyed, or monitoring for readable linux
dmabuf file descriptors, etc.
Also, a referenced ClientBuffer cannot be destroyed, unlike the old
BufferInterface.
If window quads need to be generated after the wl_surface is destroyed,
the SurfaceItemWayland::mapToBuffer() function will return wrong values.
In order to fix that, we need to store the last surface-to-buffer matrix
in SurfaceItem.
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.
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
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.
Putting the OpenGL post processing rotation into its own class cleans
the EglGbmBackend code up a bit and adds post processing rotation for
the EglStreamBackend
Currently, if discard() is called, kwin will crash because
EglPixmapTexture does not override the discard method.
In principle, neither GlxPixmapTexture nor EglPixmapTexture should mess
around with internals of the GLTexture class. It is better to have a
wrapper texture with a bind method, which will re-bind the pixmap to the
opengl texture if necessary.
It seems like without a surface creation of the scene fails somehow. At
least until the exact problem is solved, update outputs for EglStream
gpus before creating the EglStreamBackend.
BUG: 438363
At the moment, we handle window quads inefficiently. Window quads from
all items are merged into a single list just to be broken up again.
This change removes window quads from libkwineffects. This allows us to
handle window quads efficiently. Furthermore, we could optimize methods
such as WindowVertex::left() and so on. KWin spends reasonable amount
of time in those methods when many windows have to be composited.
It's a necessary prerequisite for making wl_surface painting code role
agnostic.
Window quads need to be in some coordinate space. Since we want items to
be used not only for rendering windows, window-local coordinates do not
suffice.
This change makes scene items generate quads in the item-local coordinate
space.
The model matrix is used to map the quads to the global screen coordinate
system from the item coordinate space.
Since the quads are in the item local coordinate space, the mvp matrix
needs to be updated on every draw call. Given the render data, tracking
the last mvp matrix won't result in less glUniform calls. If this indeed
becomes a serious performance bottleneck, we can explore the possibility
of dumping mvp matrices in a UBO, which have been introduced in OpenGL
3.1.
The scene items depend on the scene windows for caching window quads.
The goal of this change is to move window quads management to item.
Merging window quads in one list and then splitting them is inefficient,
it will be highly desirable if window quads are removed from the public
api so we can optimize window quad management.
With this change, the window quad type becomes irrelevant to render
backends for the most part. Note that the Xrender backend is a bit
nitpicky about window quads, so the shadow item doesn't create generic
"WindowQuadShadow" quads anymore.
Drop-shadows with the software render backend impact performance quite
significantly. It also makes it easier to prepare render backends for the
item based design.
So far, we were creating a model view with the complete scene rendered
(even if we didn't render the windows themselves). This required us to
have a big glPerspective spanning the entire scene and we were just
cropping it as we rendered it into a smaller texture.
This changes our scenes so we have the correct matrix set up at all
times.
Specifically in the case of the Pinephone, this solves the following
issue where we were unable to connect external displays because it
exceeded GL_MAX_VIEWPORT_DIMS:
https://invent.kde.org/teams/plasma-mobile/issues/-/issues/11
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
We used to get a weird line around the window decoration because the
clamping would hit the outside of the rendered decoration.
To make sure we fall inside take the displayPixelRatio into account.
Also on non-integer scales, make sure we are actually falling inside.
It was needed to work around visual glitches in the wobbly windows
effect. Since the wobbly windows effect renders the animated window into
an offscreen texture, we don't need this workaround anymore.
Furthermore, rather than using half-pixel correction, it is more
desirable to use an offscreen texture as it results in simpler design.
Performance-wise, it's not that bad that we need to start looking for
other ways to get rid of the seams between window contents and deco.
The backend can now optionally wait for the scene to be created before
it updates its outputs, which is necessary for better atomic tests in
the DRM backend.
Currently, the implementation of the DecoratedClient and the decoration
renderer are strongly coupled. This poses a problem with the item based
design as the ultimate goal is to have scene items construct paint nodes
which are then fed to the renderer. The DecorationItem has to have
control over the decoration texture. Another issue is that the scene
cannot smoothly cross-fade between two window states if the decoration
is removed, e.g. from fullscreen mode to normal and vice versa.
This change moves the decoration renderer to the decoration item. With
the introduction of a generic scene texture atlas, we hope to get rid of
the decoration renderer altogether.
attachStreamConsumer and resetOutput are not called as part of the scene
render and as such the context might not be set.
All credit goes to Simon Spinner for his investigation.
BUG: 437573
