It makes it very hard to debug any use-case that isn't a strip of
outputs and even then, we should have other mechanisms to arrange
outputs properly (i.e. through kscreen).
Instead of using a DmaBufAttributes instance to communicate the settings
to create a new dmabuf, use a smaller DmaBufParams class that only
contains the information we need after destroying the BO.
At the moment, dmabuf importing is scattered all over the place in kwin.
It would be great if we had one function that takes dma-buf attributes
and returns an EGLImage if successful.
As the first step, make linux-dmabuf-v1 implementation provide dmabuf
attrs compatible with KWin::DmaBufAttributes.
There are a few benefits to using smart pointers from the standard library:
- std::unique_ptr has move semantics. With move semantics, transfer of ownership
can be properly expressed
- std::shared_ptr is more efficient than QSharedPointer
- more developers are used to them, making contributions for newcomers easier
We're also already using a mix of both; because Qt shared pointers provide
no benefits, porting to standard smart pointers improves consistency in
the code base. Because of that, this commit ports most of the uses of QSharedPointer
to std::shared_ptr, and some uses of QScopedPointer to std::unique_ptr
Makes sure disabled outputs are reported as such, leaving behind the
assumption that all outputs are always enabled.
Ensures the corresponding outputEnabled/Disabled signals are emitted.
Updates the window title to reflect the output state.
In response to a XCB_CONFIGURE_NOTIFY on the output window, the new size
is set as mode and the output layer buffer is recreated.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2459>
Under kwin_wayland `kwinApp()->connection()` is for communicating with
XWayland, but in X11Windowed backend we need to talk to the host XServer.
Restore `XRenderUtils::init` and set it accordingly based on
whether we're running standalone or windowed, so that `kwin_wayland`
works running nested in an X session again.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Tested-by: Merge Service <https://invent.kde.org/plasma/kwin/-/merge_requests/2457>
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2457>
The XRender backend has been removed, leaving most of KWinXRenderUtils unused.
The few features that are still used, notable `XRenderPicture` and pict format
are moved into the x11/common directory.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
For some reason with legacy the cursor gets an offset when changing the
image. In order to work around this, directly issue a cursor move with the
corrected position when changing the buffer
With this only the main and the libinput threads will use realtime
scheduling, so it will be harder to leak realtime scheduling to somebody
else.
The only caveat is that kwin would need to keep CAP_SYS_NICE around,
however on the other hand, it's needed to ensure that kwin_wayland is
able to get high priority EGL contexts with some drivers, e.g. intel.
It appears that importing gbm_bo's using eglCreateImageKHR() doesn't
work on nvidia.
Another issue is that Platform::createDmaBufTexture() uses
gbm_bo_create(). The nvidia driver doesn't like that, it's preferred to
use gbm_bo_create_with_modifiers().
In order to address those issues, this change refactors how gbm_bo
objects are imported and how gbm_bo's are allocated for dmabuf textures,
so the same code can be reused in EglGbmBackend::textureForOutput()
and Platform::createDmaBufTexture().
It can happen that a gbm implementation does not support modifiers, while
the drm driver does. To prevent that from breaking KWin, fall back to creating
a gbm surface without modifiers when creating one with modifiers fails.
BUG: 453320
The first time the GBM backend's EGL context is made current after
creation, both the read and draw surfaces are set to EGL_NO_SURFACE.
This will set the GL read and draw buffers to GL_NONE in accordance with
the EGL spec.
When a real surface is later made current, however, the spec is arguably
unclear on whether the read and draw buffers should remain set to
GL_NONE or whether they should be restored to the default GL_BACK. The
Mesa driver does the latter, the NVIDIA driver does the former.
To work around this difference, Kwin has an explicit call to
glDrawBuffer in GbmSurface::makeContextCurrent. It does not have a
corresponding call to glReadBuffer, though, which can cause some desktop
effects such as background contrast to render incorrectly with the
NVIDIA driver. This change adds that missing call.
Releasing the buffers is necessary for example in the case of a GPU reset,
to make sure that the gbm surface is still properly destroyed and all buffers
with invalid content freed.
Instead of buffers being both drm framebuffers and gbm / dumb buffers, these
responsibilities are now split, which makes it possible to do zero copy
screen casting in the future.
Both framebuffers and gbm / dumb buffers also now always hold a valid underlying
resource, which simplifies code a bit.
libinput_device_get_user_data() can be used to get the associated Device
object with libinput_device. That way, we won't need to maintain a
private list of all input devices.
Format modifiers enable the graphics hardware to be much more efficient,
especially when it comes to multi-gpu transfers. With the issues regarding
bandwidth limits now solved, enable them by default to make all supported
systems benefit from them.
CCBUG: 452397
CCBUG: 452219
When explicit modifiers are used, it can happen that Mesa chooses modifiers that make
the display hardware hit bandwidth limits. In that case, atomic tests fail and the
outputs don't work, or KWin may even crash.
In order to work around that, DrmGpu now removes the used modifier whenever an atomic
test fails, and tries to find a working combination of outputs and modifiers.
While having all state be public is great for avoiding the boilerplate that
comes with setters and getters, it also exposes more state than necessary
to the rest of the backend and makes it more error-prone if more than one
part of the state needs to be changed at the same time.
Instead of passing all possible field values to the initialize()
function, pass all relevant data in a struct. With designated
initializers, it's more readable and makes code more comprehensible.
The general goal is to split Output's data in two categories - general
information about the output (e.g. edid) and mutable state (position,
mode, etc).
With this, the drm backend will be able to associate drmModeModeInfo
with Output's modes, which can be useful if there are several modes with
the same resolution and refresh rate but different flags.
This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
Instead of creating a gammaramp object with a fixed size, make the color
device create a color transformation object that can be used to construct
arbitrary LUTs. This is needed in order to support tiled displays well
and is useful for further color management work.
If the backend needs to apply custom logic when changing the transform,
it should override Platform::applyOutputChanges(); otherwise just update
the Output's internal transform state.
AbstractOutput is not so Abstract and it's common to avoid the word
"Abstract" in class names as it doesn't contribute any new information.
It also significantly reduces the line width in some places.
Input event flow has been refactored so all input events originate from
input devices.
The X11 backend uses InputRedirection so make it forward events to
relevant input device handlers.
Prefering alpha is needed for some interactions with video underlays; more
directly choosing formats with an alpha channel will be needed for overlay
planes, too.
The main motivation behind this change is to unify render target
representation across opengl and software renderers and avoid accessing
the render backend directory in order to get the render target.
GLRenderTarget doesn't provide a generic abstraction for framebuffer
objects, so let's call GLRenderTarget what it is - a framebuffer.
Renaming the GLRenderTarget class allows us to use the term "render
target" which abstracts fbos or shm images without creating confusion.
With these two actions being separate, RenderLoop can record the time spent
in endFrame (for example for multi-gpu transfers) without risking also recording
blocking swapbuffer calls, and endFrame can later be moved to output layer
In 5.24, the same code path is used for testing direct scanout, so that
causes false negatives. Generally though, the user setting shouldn't be
touched, it's not really proper feedback for the driver or KWin having
problems.
Some modes can have the exact frame timings but different flags.
Currently, the mode comparison function doesn't take that into account
which can result in the drm backend setting the current mode flag
incorrectly.
If the blob is fetched while there is no kernel-visible reference to it,
the driver may re-use the blob ID. When DrmProperty is created or updated,
KWin holds a reference on the blob via drmModeObjectProperties, so this
should prevent any possible issues.
CCBUG: 449285
Using the global coordinate system when specifying output layer damage
regions would be very confusing. In order to make the coordinate system
comprehensible, use the layer-local coordinate system.
The infinite region is used to tell the Compositor when it needs to
repaint the entire layer.
When modesets are necessary, they are attempted when an output on the given
GPU gets presented. With multi-gpu setups however, the situation can arise
where there is only one disabled output on a GPU; in that case KWin eternally
waits and never properly turns off the display.
In order to work around this, explicitly call DrmGpu::maybeModeset when
an output gets disabled.
BUG: 449878
FIXED-IN: 5.24.4
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
Virtual machines aren't properly supporting atomic mode setting yet, which
causes the cursor to be offset, and will cause more issues with overlay
planes. In order to prevent that from impacting users, fall back to legacy,
unless KWIN_DRM_NO_AMS is set.
BUG: 427060
FIXED-IN: 5.24.4
Hard to avoid as long as we don't have CI coverage yet, but that will take
a bit more time, we need KWin (and all its dependencies) to fully build
first.
The raspberry pi exposes opaque formats for the cursor plane, and interprets
them as being opaque as well... Considering that we effectively don't support
anything else with the QPainter anyways, just hardcode ARGB8888 until we paint
the cursor with OpenGl.
fbdev has been deprecated and unmaintained for a while. With Linux 5.14
including SimpleDRM driver, we can drop it. (at the time of writing this
commit message, the latest Linux version is 5.16).
[1/6] Make autotests create fake input devices
The goal of this patch set is simulating user input in unit tests via
InputDevices and no longer use the Platform to fake input. This matches
more closely with how input is processed when running a full plasma
wayland session, i.e. with the DRM and libinput backends.
Otherwise when we render it, we do so upside down and screen sharing
looks broken.
This only happens when the shadow buffer is in use, so it's not all that
common.
Instead of having the render backends manage layers, have DrmGpu and DrmPipeline
do it. This makes it possible to unify code paths for leased and normal
outputs, remove some redirection and have more freedom with assigning layers
to screens.
We already try to ensure that the surface damage is within render target
bounds. Avoid clipping surface damage in render backend, which is a bit
excessive task and perhaps it should be done an abstraction level above.
When casting from integer to pointer, promoting the integer to (u)intptr_t
will ensure that the resulting type can be converted to a pointer without
problems. These two casts changed in this commit trigger a warning when
building for CHERI-enabled architectures such as Arm Morello. This is not
just limited to CHERI, the cast from xcb_pixmap_t (uint32_t) to void*
should also be flagged by -Wint-to-void-pointer-cast when using Clang,
however, it appears that warning only handles C-style casts, and not
reinterpret_cast (https://github.com/llvm/llvm-project/issues/53964).
At this point, it's safe to assume that only X11 has weird rendering
model, which stands in the way of making rendering abstractions nice and
intuitive, so let's check operation mode. If OperationModeX11 is
dropped, this will also simplify finding X11-specific code in kwin.
The responsibilities of the Scene must be reduced to painting only so we
can move forward with the layer-based compositing.
This change moves direct scanout logic from the opengl scene to the base
scene class and the compositor. It makes the opengl scene less
overloaded and allows to share direct scanout logic.
Having a render loop in the Platform has always been awkward. Another
way to interpret the platform not supporting per screen rendering would
be that all outputs share the same render loop.
On X11, Scene::painted_screen is going to correspond to the primary
screen, we should not rely on this assumption though!
This allows us to make the GLRenderTarget a bit nicer when using it to
wrap the default fbo as we don't know what the color attachment texture
is besides its size.
This means that the responsibility of ensuring that the color attachment
outlives the fbo is now up to the caller. However, most of kwin code
has been written that way, so it's not an issue.
Because the GLRenderTarget and the GLVertexBuffer use the global
coordinate system, they are not ergonomic in render layers.
Assigning the device pixel ratio to GLRenderTarget and GLVertexBuffer is
an interesting api design choice too. Scaling is a window system
abstraction, which is absent in OpenGL or Vulkan. For example, it's not
possible to create an OpenGL texture with a scale factor of 2. It only
works with device pixels.
This change makes the GLRenderTarget and the GLVertexBuffer more
ergonomic for usages other than rendering the workspace by removing all
the global coordinate system and scaling stuff. That's the
responsibility of the users of those two classes.
In order to support layered rendering and tiled outputs KWin needs to be
able to split rendering of outputs into multiple surfaces. This commit
prepares the drm backend for that, by moving most of the code in EglGbmBackend
out to a EglGbmSurface class, which will later be used for overlay surfaces
and rendering to multiple connectors side by side.
In doing that, this commit also cleans up the code a bit, removes a lot of
now unnecessary multi-gpu stuff and potentially makes modesets a little
bit more efficient by re-using resources more often.
Currently, the Cursors::currentCursorChanged signal is wired to the
updateCursor() function which calls xcb_xfixes_hide_cursor() or
xcb_xfixes_show_cursor() depending if the cursor is hidden. However, the
currentCursorChanged signal can be emitted if the cursor changed, e.g. a
new pixmap attached, or its visibility status changes.
The zoom effect hides the pointer, but when user hovers ui elements, it
will most likely change and result in more than one xcb_xfixes_hide_cursor()
calls.
It appears like xcb_xfixes_hide_cursor() is implemented as a reference
counter, i.e. if xcb_xfixes_hide_cursor() is called two times, then you
must call xcb_xfixes_show_cursor() two times as well.
This change adds a dedicated signal to indicate whether the cursor is
hidden to avoid calling xcb_xfixes_hide_cursor() multiple times while
the screen is scaled.
BUG: 448537
They're error prone and don't really work for changing modes. Having
a current mode in DrmConnector also doesn't work well together with
the transactional style of how DrmPipeline operates
The implicit cast effectively rounds the value down, which make the
refresh rate be different from what KScreen actually wrote.
A better fix would be to use integers instead of floating point numbers
but that needs to happen in KScreen.
BUG: 448778
While in principle Mesa should already check if the buffer can be scanned
out, this may not always work. If we can't create a framebuffer object for
the buffer, fall back to compositing.
CCBUG: 448818
Encoders are not really relevant for the test result, except that one of
the encoders for the connector must be compatible with the crtc.
The kernel usually exposes only a single encoder per connector for this
reason, but if a driver exposes multiple then that means KWin will do a
lot more tests than is necessary.
In order to prevent that from happening, do fewer syscalls and simplify
code, only check supported encoders once per connector.
19c471405e7eb4b6026db24d776d205125dbc013 introduced a regression if
there are two gbm backend and the backend fail to choose drm format.
This fix does two things:
1. Current buffer format should not be reset after create new buffer,
otherwise current.format may just be empty after resetOutput.
2. force xrgb 8888 need to be set on the primary backend.
BUG: 448790
