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
With high DPI we can't use the image size as a logical size directly.
The other change is use of QPainter::drawImage(QRect target, QImage
image, QRect source)
This slightly confusing method uses logical pixels for the target, but
the source rect is in native pixels of the source.
BUG: 422342
If the egl backend gets deleted this leaves a dangling pointer. In
order to prevent crashes with QPainter or EglStreams also don't try
to create dmabuf textures without a EglGbmBackend.
So far we had a composition setup within kwinrc and kscreen. This
produces flickering sometime and makes the state a bit more flimsy.
This patch changes the kwin's behaviour to use the files produced by
kscreen which are anyways available down the line.
THis simplifies our behaviour down to just one format that we write to
and feed from. This also allows us to leverage it further by using this
format for default setups (which consist in the right file in
~/.local/share/kscreen).
One of the scene redesign goals is to make wayland surface items
re-usable. So we have the same rendering path for drag-and-drop icons,
software cursors, and window surfaces.
The biggest issue at the moment is that window pixmaps are tightly
coupled with scene windows.
This change de-couples window pixmaps from scene windows. In order to
achieve that, some architecture changes were made.
The WindowPixmap class was replaced with the SurfacePixmap class. A
surface pixmap is created by a surface item.
Under the hood, a SurfacePixmap will create a PlatformSurfaceTexture
object, which contains all the information necessary for the renderer.
The SceneOpenGLTexture class was removed. However, the GLX and the EGL
on X11 backends still mess with GLTexture's internals.
As is, kwin with the drm backend results in the most pleasant user
experience on Wayland. Given that and the fbdev being about to be
dropped, making libdrm a required dependency seems a reasonable decision.
This feature was implemented in commit a66eb1a5b9 earlier
Double tap wake up is not a feature to be implemented at compositor
level but rather at the hardware/kernel level. Double tap timer here
means when screen is turned off, libinput will continue to poll the
touchscreen for new events.
double-tap-to-wakeup is generally interrupt at driver/hardware level
which have ability to wake system up even from the sleep.
Provide a option to disable the double tap timer on kwin side for
devices which makes use of suspend since when in suspend kwin can not
wake device up, and that provides confusing user experience.
When a GPU has no outputs attached we need to release all resources and
close the fd to allow the driver to completely power down the GPU. This
is also required to allow the driver to be unloaded for VFIO.
Platform::prepareShutdown() was introduced to work around the issue
where the platform accesses destroyed OutputDeviceInterface objects.
Since we no longer query OutputDeviceInterface for output info, the
Platform::prepareShutdown() function can be dropped.
When we release the buffers that also removes the drm fbs.
This causes failing atomic commits that the atomic code
doesn't (yet) handle correctly, the result is a black
screen when compositing is restarted.
Most wayland-native apps provide buffers that aren't suitable
for direct scanout; the message usually only spams the log full
without proper reason or useful information
In the few cases where the framebuffer is needed, we'd get problems
because ioctl(KWIN_FB_NO_VSYNC) fails.
This removes the code entirely to just use a timer to refresh.
BUG: 436053
QPainter::setWindow() doesn't work as we expect if the device pixel
ratio of the paint device is less than 1, for example 0.5 or 0.75.
QPainter only allows the effective device pixel ratios that are greater
than or equal to 1. This restriction probably has to be lifted.
For the time being, this change introduces a helper function that can be
used to determine the scale factor by which QPainter::window() must be
multiplied.
BUG: 432766
Instead of deleting all blob properties without a valid
blob check for the blob existing before using it. This is
necessary because some properties are needed even without
currently valid blobs.
BUG: 435786
While the session is inactive, the drm master permissions are revoked.
Therefore, we cannot perform things such as modesetting, etc. It also
makes no sense to create or destroy DrmOutput objects.
CCBUG: 435941
This reverts commit 5a22deda3b.
We still need more work to finish the DrmPipeline. At the moment, there
are a few major issues, e.g. some outputs not turning on, output
transforms not working correctly, a crash when changing dpms mode.
Let's merge this change back once all major issues are fixed and after
more testing.
We'd be relying on AbstractEglDrmBackend on calling cleanup but we'd be
doing it when cleanupSurfaces cannot be reached out anymore, turning it
into a half-baked cleanup.
Instead call cleanup from the leaf class destructors.
DrmPipeline is what now contains all the drm bits related to
modesetting and presentation, instead of that being in DrmOutput.
This gives a lot more freedom for managing drm resources and
enables far better usage of the atomic API with guaranteed
immutability for failed tests.
At the moment a streamed screen when the screen scale was differnt
buffer scale would render wrong. This change addresses it by
compensating it.
This change compensates it resizing the rendered viewport to their
difference.
BUG: 428594
The stream object was deleted from a slot connected to its stopStreaming
signal. This is unsafe and can lead to memory corruption and ultimately
crashes when PipWwire streaming is stopped. Use deleteLater instead.
BUG: 428268 435588
With the introduction of stripped down window items, the WindowPixmap
objects no longer form a hierarchy. WindowPixmap::children() method was
removed.
Surprisingly, the removal of the children() method didn't result in a
compilation error because the QObject class has a method with the same
name.
Currently, a window pixmap will have no QObject children even if the
associated wayland surface has child sub-surfaces. This may result in
blank thumbnails of apps that use sub-surfaces, e.g. Firefox. In order
to fix that issue, we need to check if there are child items instead.
Currently, output properties are looked up either on the wl_output
object or the output device object. This puts a hard dependency on the
wayland server in the platforms.
This change intends to fix some flaws in the current output
abstractions, and allow creating/destroying wayland-specific globals as
we wish.
With the work done in this patch, the need for the AbstractWaylandOutput
class is unclear, and it might be a good idea to merge it with the base
AbstractOutput class.
Currently, we inhibit renderloops when switching to another TTY, and unhibit
when switching back. When we hotplug a display while switched to another TTY,
its renderloop isn't inhibited by default, yet when we switch back, we try
to uninhibit the fresh renderloop, which triggers an assert.
Inhibiting newly created outputs while switched to another TTY fixes this crash.
BUG: 435388
FIXED-IN: 5.21
The connector name is not relevant to applications or
users - expectation is that the same physical monitor always gets the
same name, regardless of how it's connected. If no serial is available,
fall back to the old scheme to prevent multiple connected outputs from
having the same name.
The value that the DrmCrtc::resIndex() function returns is better known
as "pipe index." This change renames the method to match the terminology
used by kernel developers and other compositor developers.
drmModeGetPropertyBlob() may return null and we should handle that. In
addition to that, m_conn is not initialized in DrmConnector so kwin will
crash whenever the connector info is accessed.
Currently, dealing with sub-surfaces is very difficult due to the scene
design being heavily influenced by X11 requirements.
The goal of this change is to re-work scene abstractions to make improving
the wayland support easier.
The Item class is based on the QQuickItem class. My hope is that one day
we will be able to transition to QtQuick for painting scene, but in
meanwhile it makes more sense to have a minimalistic internal item class.
The WindowItem class represents a window. The SurfaceItem class represents
the contents of either an X11, or a Wayland, or an internal surface. The
DecorationItem and the ShadowItem class represent the server-side deco and
drop-shadow, respectively.
At the moment, the SurfaceItem is bound to the scene window, but the long
term plan is to break that connection so we could re-use the SurfaceItem
for things such as software cursors and drag-and-drop additional icons.
One of the responsibilities of the Item is to schedule repaints as needed.
Ideally, there shouldn't be any addRepaint() calls in the core code. The
Item class schedules repaints on geometry updates. In the future, it also
has to request an update if its opacity or visibility changes.
At the moment, the session code is far from being extensible. If we
decide to add support for libseatd, it will be a challenging task with
the current design of session management code. The goal of this
refactoring is to fix that.
Another motivation behind this change is to prepare session related code
for upstreaming to kwayland-server where it belongs.
Otherwise drmModeAtomicCommit() in DrmOutput::doAtomicCommit() fails due
to unmatched buffer sizes.
While rendering continues working properly, this makes drm freak out and
try to go back to a previous state (see the test commit in
presentAtomically()) that in turn starts issuing screen events to every
process even though it's just to say the same thing. The fact that this
happens per frame makes the system unusable as soon as fullscreen starts
happening on a scaled display.
Another thing we could do is get EglGbmBackend::scanout() to take care
of the resizing.
This provides the compositor a way to indicate what output is being
rendered. The effects such as the screenshot can check the provided
screen object in order to function as expected.
If the file descriptor of the DRM device is greater than FD_SETSIZE, the
stack will be corrupted. However, it is highly unlikely that we ever hit
this case because DRM devices are opened at startup of kwin, so the file
descriptors should small.
In order to prevent the potential stack corruption, this change replaces
the usage of select() with poll().
Unlike select(), the api of poll() is much more sensible. Back 20 or so
years ago the main argument against poll() was that it's not implemented
by all platforms. But, nowadays, it's supported on all major platforms.
Otherwise if powerdevil for example is configured to turn screen off on
the power key press, we will turn it right back on when we get key
release event.
Suggested-by: David Edmundson <kde@davidedmundson.co.uk>
There are a couple of reasons not to use the lambda:
* It is unnecessary. The DrmGpu has the DRM file descriptor
* If a crash occurs somewhere in the lambda, the backtrace will be hard
to read
* Instead of processing events in the destructor of the DrmBackend
class, we should keep dispatching events without involving
QCoreApplication::processEvents() until all page flips are completed.
I just had that crash, this is what coredumpctl suggested it was
happening.
We don't need to make sure we're in dmabuf mode to remove the buffer.
Worst case scenario it won't remove anything. Check the spa_data before
querying in case it's null.
qEnvironmentVariableIntValue() will return 0 if the specified variable
is not set.
This means that swap events will be disabled on AMD GPUs unless the env
var is set explicitly to 1.
Since QWindowSystemInterface::handleScreenRemoved would not be called in Integration::handleScreenDisabled, Qt apps would still reference disabled screens resulting in crashes.
This adds a command line tool which allows the user to set the window
decoration, and then that tool is used in the two knsrc files to allow
the user to switch window decoration directly from either a KNS dialog,
or from Discover.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
