Instead of hardcoding only NVidia, try to use CTM and GAMMA_LUT before falling
back to the shader path. This way it also works on other GPUs that lack
color management hardware, and only falls back to the color management path
on older NVidia drivers.
This commit also ensures that the color management hardware is set properly
after toggling color management on and off again, and simplifies ColorDevice
to only deal with rgb factors instead of always calculating luts. This should
improve performance of night color animations on hardware where CTMs are
supported
CCBUG: 453701
With kernel 6.6+, HOTSPOT_X and HOTSPOT_Y are exposed on the cursor plane
in virtual machines, so the fallback to the legacy API is no longer needed.
At some point in the future, the list of virtual machine drivers can be
dropped entirely.
They cause stutters and reduced frame rates on some Intel laptops because the
buffers don't become readable in time, so disable the checks until that's fixed
on the driver side. For debugging purposes, the environment variable
KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS can be used to override the default
behavior.
BUG: 476860
There is a chance that DrmGpu::pageFlipHandler gets executed on the main
thread while drmModeAtomicCommit hasn't returned yet on the commit thread.
When this situation happens, the destructor of DrmAtomicCommit doesn't set
the buffers to be current for the relevant drm planes, and once it gets
deleted, the framebuffers get destroyed and the output turns off.
To prevent that from happening, this commit moves the relevant code to a
method that gets explicitly called from the pageflip handler.
Pending buffers for drm planes and crtcs are no longer tracked in the planes
and crtcs themselves, but instead in a DrmCommit object that is used as
the user data for the pageflip handler. This way multiple commits can be
pending at the same time without causing conflicts, and the handling of
pending buffers is simplified as well.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
This change ports the drm backend to the GraphicsBuffer and
GraphicsBufferAllocator.
The main motivation is to unify graphics buffer abstractions across
various backends and to prepare it for output layers, which could be
nicer if we could have direct control over the buffers.
GEM handles are not reference counted and are unique per drm file
descriptor.
With the upcoming changes, dmabuf and dumb buffers will be abstraced
using DmaBufAttributes.
The issue with it is that we need GEM handles to get a drm framebuffer.
drmPrimeFDToHandle() can be used to get the GEM handle for a drm file
descriptor, but we would hit the reference counting issues then and
potentially double close GEM handles.
In order to resolve that, this change makes the drm backend reopen the
drm node to get a new GEM handle namespace for rendering.
We don't know what the current mode is, or if the display is even enabled
or whatever. Always do a modeset to be sure everything is correct
BUG: 469280
This makes it possible to ensure type safety for enums, as each drm property
object can have its own type now, and it reduces the amount of typing needed
to access properties
This feature is no longer needed, as the scene can efficiently do its own
transformations now. Support for using hardware rotation to make direct scanout
work specifically can be added again later
Instead of having every DrmProperty store pending values, store the data
for the next commit in a separate and temporary type. This simplifies the
code and makes it possible to do commits in a separate thread
QVector::count()'s return type is qsizetype. On a 64 bit platform, it's
equivalent to qint64, so "%d" does not suffice.
There are two ways to fix it: use PRIdQSIZETYPE or switch to the stream
operator. Since the warning format is not complex, this takes the latter
approach.
Currently, output backends track the cursor behind the scenes. This
results in some amount of code duplication, for example the handling of
hidden cursors, every backend handles in its own unique way, some don't
do it correctly. Another issue is that output backend interact with
other components behind the back. This can be a problem for tasks such
as backing the cursor with an output layer.
This change introduces explicit output cursor manipulation APIs in the
Output class. There's a good chance that it's going to be revised more
in the future as part of streamlining output layer manipulation apis.
With the proposed changes, the workspace would need to call
Output::setCursor() or Output::moveCursor() to set/unset or move the
cursor, respectively.
Due to being a compositor, kwin has to conform to some certain
interfaces. It means a lot of virtual functions and function tables to
integrate with C APIs. Naturally, we not always want to use every
argument in such functions.
Since we get -Wunused-parameter from -Wall, we have to plumb those
unused arguments in order to suppress compiler warnings at the moment.
However, I don't think that extra work is worth it. We cannot change or
alter prototypes in any way to fix the warning the desired way. Q_UNUSED
and similar macros are not good indicators of whether an argument is
used too, we tend to overlook putting or removing those macros. I've
also noticed that Q_UNUSED are not used to guide us with the removal no
longer needed parameters.
Therefore, I think it's worth adding -Wno-unused-parameter compiler
option to stop the compiler producing warnings about unused parameters.
It changes nothing except that we don't need to put Q_UNUSED anymore,
which can be really cumbersome sometimes. Note that it doesn't affect
unused variables, you'll still get a -Wunused-variable compiler warning
if a variable is unused.
The drm fd can get stuck in readable state, in which case the
QSocketNotifier will fire the activated signal as often as it can
leading to high cpu usage.
We need to read() the drm fd in order to make the socket notifier stop
firing QSocketNotifier::activated.
This change removes the m_platform->isActive() check to ensure that
drmHandleEvent() gets called, in general, it should be safe as we only
notify the outputs about completed pageflips.
BUG: 452726
Currently the Workspace processes output updates as they occur, e.g.
when the drm backend scans connectors, the Workspace will handle
hotplugged outputs one by one or if an output configuration changes the
mode of several outputs, the workspace will process output layout
updates one by one instead of handling it in one pass. The main reason
for the current behavior is simplicity.
However, that can create issues because it's possible that the output
layout will be temporarily in degenerate state and features such as
sticking windows to their outputs will be broken.
In order to fix that, this change makes the Workspace process batched
output updates. There are several challenges - disconnected outputs have
to be alive when the outputsQueried signal is emitted, the workspace
needs to determine what outputs have been added or removed on its own.
The proposed way to handle unplugged gpus allows us to ensure that
removed outputs' lifetime can be extended to the moment when the
Platform::outputsQueried signal is emitted.
Besides that, it's possible to extend this code a bit further to make
sure that output updates are batched when hotplugging multiple gpus,
e.g. after resuming, etc.
Currently, we effectively almost everywhere need DrmOutput outputs,
DrmVirtualOutput outputs are needed only in a couple of places. There's
not a lot that we gain from storing real and virtual outputs in one
list, it adds unnecessary casting, etc. Ideally, virtual outputs must
come from a different backend, the current approach is not scalable.
Placeholder outputs are not rendered so they don't need render data.
Also, this simplifies the control flow when the last real output is
removed. The Platform::screensQueried signal won't be emitted inside a
Platform::screensQueried slot.
Things such as Output, InputDevice and so on are made to be
multi-purpose. In order to make this separation more clear, this change
moves that code in the core directory. Some things still link to the
abstraction level above (kwin), they can be tackled in future refactors.
Ideally code in core/ should depend either on other code in core/ or
system libs.
If multiple properties that affect the geometry change, then the
Output::geometryChanged() signal will be emitted multiple times, which
in its turn may force the Workspace to re-arrange windows, etc.
With this, the geometryChanged signal will be emitted in more expected
fashion only once as long as relevant property changes are batched.
Backends aren't the right layer to take care of placeholder outputs, and
don't really have enough information to do it either. This also fixes a
crash, because the placeholder output currently gets created too late
Instead of checking for properties needing a modeset, do atomic tests
with ALLOW_MODESET where it makes sense, and do a second atomic test
afterwards without ALLOW_MODESET to check if the modeset can be skipped.
This should ensure that KWin always does a modeset when it needs to do one,
and not do a modeset when it's not necessary. Doing this also allows
reducing the complexity of the drm backend a bit.
The DrmOutput synchronizes the enabled state with the active state,
which makes sense on one hand, but on the other hand, that's not good.
The drm backend makes a decision that should be ideally made by either
kscreen (turn on outputs before applying an output config), user, or
kwin itself.
This would also allow kwin to control the allocation of crtcs for
non-desktop outputs, which is a minor thing, but it might be useful in
the future.
Xaver Hugl
Laurent Montel
Vlad Zahorodnii
Janet Blackquill