2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2016-03-21 14:11:17 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2015 Martin Gräßlin <mgraesslin@kde.org>
|
2016-03-21 14:11:17 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2016-03-21 14:11:17 +00:00
|
|
|
#ifndef KWIN_DRM_OUTPUT_H
|
|
|
|
#define KWIN_DRM_OUTPUT_H
|
|
|
|
|
2019-06-13 09:36:07 +00:00
|
|
|
#include "abstract_wayland_output.h"
|
2016-03-21 14:11:17 +00:00
|
|
|
#include "drm_pointer.h"
|
2016-08-31 12:00:31 +00:00
|
|
|
#include "drm_object.h"
|
2017-11-01 18:21:08 +00:00
|
|
|
#include "drm_object_plane.h"
|
2016-03-21 14:11:17 +00:00
|
|
|
|
|
|
|
#include <QObject>
|
|
|
|
#include <QPoint>
|
|
|
|
#include <QSize>
|
2016-08-31 12:00:31 +00:00
|
|
|
#include <QVector>
|
2021-03-22 14:46:09 +00:00
|
|
|
#include <QSharedPointer>
|
2016-03-21 14:11:17 +00:00
|
|
|
#include <xf86drmMode.h>
|
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
|
|
|
class DrmBackend;
|
|
|
|
class DrmBuffer;
|
2017-05-09 19:00:33 +00:00
|
|
|
class DrmDumbBuffer;
|
2016-08-31 12:00:31 +00:00
|
|
|
class DrmPlane;
|
|
|
|
class DrmConnector;
|
|
|
|
class DrmCrtc;
|
2020-04-02 16:18:01 +00:00
|
|
|
class Cursor;
|
2020-10-05 21:05:55 +00:00
|
|
|
class DrmGpu;
|
2016-03-21 14:11:17 +00:00
|
|
|
|
2019-06-13 09:36:07 +00:00
|
|
|
class KWIN_EXPORT DrmOutput : public AbstractWaylandOutput
|
2016-03-21 14:11:17 +00:00
|
|
|
{
|
|
|
|
Q_OBJECT
|
|
|
|
public:
|
2018-07-18 14:13:38 +00:00
|
|
|
///deletes the output, calling this whilst a page flip is pending will result in an error
|
|
|
|
~DrmOutput() override;
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
|
|
|
|
RenderLoop *renderLoop() const override;
|
|
|
|
|
2018-07-18 14:13:38 +00:00
|
|
|
///queues deleting the output after a page flip has completed.
|
|
|
|
void teardown();
|
2021-05-02 20:38:36 +00:00
|
|
|
void releaseGbm();
|
2021-04-20 10:53:02 +00:00
|
|
|
bool showCursor(DrmDumbBuffer *buffer);
|
2021-03-27 14:01:34 +00:00
|
|
|
bool showCursor();
|
|
|
|
bool hideCursor();
|
2021-04-20 10:53:02 +00:00
|
|
|
bool updateCursor();
|
|
|
|
void moveCursor();
|
|
|
|
bool init(drmModeConnector *connector);
|
|
|
|
bool present(const QSharedPointer<DrmBuffer> &buffer);
|
|
|
|
void pageFlipped();
|
2016-03-21 14:11:17 +00:00
|
|
|
|
2021-03-27 14:01:34 +00:00
|
|
|
bool isDpmsEnabled() const {
|
2021-04-20 10:53:02 +00:00
|
|
|
// We care for current as well as pending mode in order to allow first present in AMS.
|
|
|
|
return m_dpmsModePending == DpmsMode::On;
|
|
|
|
}
|
|
|
|
|
|
|
|
DpmsMode dpmsModePending() const {
|
|
|
|
return m_dpmsModePending;
|
2020-04-08 14:07:36 +00:00
|
|
|
}
|
|
|
|
|
[platforms/drm] EGLStream DRM Backend Initial Implementation
Summary:
This is the initial implementation of a DRM backend based on the EGLDevice,
EGLOutput, and EGLStream extensions, supporting NVIDIA graphics hardware using
their proprietary driver. The new backend will be used if the environment
variable KWIN_DRM_USE_EGL_STREAMS is set. On initialization, it will attempt to
create an EGLDevice based on the DRM device currently in use and create
EGLOutputs and EGLStreams for any attached displays. These are used to control
presentation of the final composited frame. Additionally, it will register the
wl_eglstream_controller Wayland interface so that native EGL windows created by
clients can be attached to an EGLStream allowing buffer contents to be shared
with the compositor as a GL texture.
At this time there are two known bugs in the NVIDIA driver's EGL implementation
affecting desktop functionality. The first can result in tooltip windows drawn
by plasmashell to contain incorrect contents. The second prevents KWayland from
being able to query the format of EGLStream-backed buffers which interferes
with the blur effect. Fixes for both of these are currently in development and
should appear in an upcoming NVIDIA driver release.
Additionally, hardware cursors are currently not supported with this backend.
Enabling them causes the desktop to intermittently hang for several seconds.
This is also likely a bug in the NVIDIA DRM-KMS implementation but the root
cause is still under investigation.
Test Plan:
On a system with an NVIDIA graphics card running a recent release of their
proprietary driver
* Ensure the nvidia_drm kernel module is loaded with the option "modeset=1"
("# cat /sys/module/nvidia_drm/parameters/modeset" should print "Y")
* Ensure EGL external platform support is installed
https://github.com/NVIDIA/eglexternalplatform
* Ensure KWin was build with the CMake option
KWIN_BUILD_EGL_STREAM_BACKEND=ON (this is the default)
* Start a plasma wayland session with the environment variable
KWIN_DRM_USE_EGL_STREAMS set
* Ensure output from KWin OpenGL initialization indicates the NVIDIA EGL
driver is in use (as opposed to Mesa / llvmpipe).
* Desktop should be fully functional and perform smoothly.
Reviewers: #kwin, romangg, davidedmundson
Reviewed By: #kwin, romangg, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18570
2019-04-15 14:26:22 +00:00
|
|
|
const DrmCrtc *crtc() const {
|
|
|
|
return m_crtc;
|
|
|
|
}
|
2020-04-08 14:07:36 +00:00
|
|
|
const DrmConnector *connector() const {
|
|
|
|
return m_conn;
|
|
|
|
}
|
[platforms/drm] EGLStream DRM Backend Initial Implementation
Summary:
This is the initial implementation of a DRM backend based on the EGLDevice,
EGLOutput, and EGLStream extensions, supporting NVIDIA graphics hardware using
their proprietary driver. The new backend will be used if the environment
variable KWIN_DRM_USE_EGL_STREAMS is set. On initialization, it will attempt to
create an EGLDevice based on the DRM device currently in use and create
EGLOutputs and EGLStreams for any attached displays. These are used to control
presentation of the final composited frame. Additionally, it will register the
wl_eglstream_controller Wayland interface so that native EGL windows created by
clients can be attached to an EGLStream allowing buffer contents to be shared
with the compositor as a GL texture.
At this time there are two known bugs in the NVIDIA driver's EGL implementation
affecting desktop functionality. The first can result in tooltip windows drawn
by plasmashell to contain incorrect contents. The second prevents KWayland from
being able to query the format of EGLStream-backed buffers which interferes
with the blur effect. Fixes for both of these are currently in development and
should appear in an upcoming NVIDIA driver release.
Additionally, hardware cursors are currently not supported with this backend.
Enabling them causes the desktop to intermittently hang for several seconds.
This is also likely a bug in the NVIDIA DRM-KMS implementation but the root
cause is still under investigation.
Test Plan:
On a system with an NVIDIA graphics card running a recent release of their
proprietary driver
* Ensure the nvidia_drm kernel module is loaded with the option "modeset=1"
("# cat /sys/module/nvidia_drm/parameters/modeset" should print "Y")
* Ensure EGL external platform support is installed
https://github.com/NVIDIA/eglexternalplatform
* Ensure KWin was build with the CMake option
KWIN_BUILD_EGL_STREAM_BACKEND=ON (this is the default)
* Start a plasma wayland session with the environment variable
KWIN_DRM_USE_EGL_STREAMS set
* Ensure output from KWin OpenGL initialization indicates the NVIDIA EGL
driver is in use (as opposed to Mesa / llvmpipe).
* Desktop should be fully functional and perform smoothly.
Reviewers: #kwin, romangg, davidedmundson
Reviewed By: #kwin, romangg, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18570
2019-04-15 14:26:22 +00:00
|
|
|
const DrmPlane *primaryPlane() const {
|
|
|
|
return m_primaryPlane;
|
|
|
|
}
|
|
|
|
|
2017-11-05 10:59:24 +00:00
|
|
|
bool initCursor(const QSize &cursorSize);
|
|
|
|
|
2020-01-02 14:55:02 +00:00
|
|
|
/**
|
|
|
|
* Drm planes might be capable of realizing the current output transform without usage
|
|
|
|
* of compositing. This is a getter to query the current state of that
|
|
|
|
*
|
|
|
|
* @return true if the hardware realizes the transform without further assistance
|
|
|
|
*/
|
|
|
|
bool hardwareTransforms() const;
|
2020-11-27 19:57:24 +00:00
|
|
|
|
2020-10-05 21:05:55 +00:00
|
|
|
DrmGpu *gpu() {
|
|
|
|
return m_gpu;
|
|
|
|
}
|
2020-01-02 14:55:02 +00:00
|
|
|
|
2016-03-21 14:11:17 +00:00
|
|
|
private:
|
2020-10-05 21:05:55 +00:00
|
|
|
friend class DrmGpu;
|
2016-03-21 14:11:17 +00:00
|
|
|
friend class DrmBackend;
|
[DRM plugin] Remember static kernel objects, amplify use of DrmCrtc
To get an image from KWin to the screen in the DRM pipeline we combine a CRTC,
an encoder and a connector. These objects are static in the sense, that they
represent real hardware on the graphics card, which doesn't change in a
session. See here for more details:
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html
Until now we used DrmOutput as the main representation for such an active
rendering pipeline. I.e. it gets created and destroyed on hot plug events of
displays. On the other side we had no fixed representation of the static kernel
objects throughout the lifetime of KWin. This has several disadvantages:
* We always need to query all available static objects on an hot plug event.
* We can't manipulate the frame buffer of a CRTC after an output has been
disconnected
* Adding functionality for driving multiple displays on a single CRTC (i.e.
cloning) would be difficult
* We can't destroy the last frame buffer on display disconnect because the CRTC
still accesses it and have therefore a memory leak on every display disconnect
This patch solves these issues by storing representations of all available CRTC
and Connector objects in DrmBackend on init via DrmCrtc and DrmConnector
instances. On an hotplug event these vectors are looped for a fitting CRTC and
Connector combinations. Buffer handling is moved to the respective CRTC
instance. All changes in overview:
* Query all available CRTCs and Connectors and save for subsequent hotplug
events
* Fix logic errors in `queryResources()`
* Move framebuffers, buffer flip and blank logic in DrmCrtc
* Remove `restoreSaved()`. It isn't necessary and is dangerous if the old
framebuffer was deleted in the meantime. Also could reveal sensitive user
info from old session.
Test Plan:
Login, logout, VT switching, connect and disconnect external monitor, energy
saving mode.
Reviewers: #kwin
Subscribers: kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5118
2017-05-09 18:02:49 +00:00
|
|
|
friend class DrmCrtc; // TODO: For use of setModeLegacy. Remove later when we allow multiple connectors per crtc
|
|
|
|
// and save the connector ids in the DrmCrtc instance.
|
2020-10-05 21:05:55 +00:00
|
|
|
DrmOutput(DrmBackend *backend, DrmGpu* gpu);
|
2018-07-18 14:13:38 +00:00
|
|
|
|
2021-04-20 10:53:02 +00:00
|
|
|
bool presentAtomically(const QSharedPointer<DrmBuffer> &buffer);
|
|
|
|
|
|
|
|
enum class AtomicCommitMode {
|
|
|
|
Test,
|
|
|
|
Real
|
|
|
|
};
|
|
|
|
bool doAtomicCommit(AtomicCommitMode mode);
|
2017-05-09 19:29:10 +00:00
|
|
|
|
2021-04-20 10:53:02 +00:00
|
|
|
bool presentLegacy(const QSharedPointer<DrmBuffer> &buffer);
|
|
|
|
bool setModeLegacy(DrmBuffer *buffer);
|
|
|
|
void initOutputDevice(drmModeConnector *connector);
|
|
|
|
|
|
|
|
bool isCurrentMode(const drmModeModeInfo *mode) const;
|
|
|
|
|
|
|
|
void atomicEnable();
|
|
|
|
void atomicDisable();
|
2019-08-31 08:27:04 +00:00
|
|
|
void updateEnablement(bool enable) override;
|
2021-04-20 10:53:02 +00:00
|
|
|
|
|
|
|
bool dpmsAtomicOff();
|
|
|
|
bool dpmsLegacyApply();
|
|
|
|
|
|
|
|
void dpmsFinishOn();
|
|
|
|
void dpmsFinishOff();
|
|
|
|
|
2021-07-07 17:16:29 +00:00
|
|
|
void setModesetValues(bool enable);
|
2021-04-04 14:11:13 +00:00
|
|
|
void setDpmsMode(DpmsMode mode) override;
|
2018-11-09 18:36:02 +00:00
|
|
|
void updateMode(int modeIndex) override;
|
2020-12-15 20:20:10 +00:00
|
|
|
void updateMode(uint32_t width, uint32_t height, uint32_t refreshRate);
|
2021-04-20 10:53:02 +00:00
|
|
|
void setCurrentModeInternal();
|
|
|
|
|
2019-11-26 22:53:17 +00:00
|
|
|
void updateTransform(Transform transform) override;
|
2017-11-06 16:00:15 +00:00
|
|
|
|
Backport Night Color feature to X11
Summary:
The color correction manager doesn't make any specific assumptions about
underlying platform, e.g. whether it's x11, etc. The platform just
has to be capable of setting gamma ramps. Given that, there are no any
significant technical blockers for making this feature work on x.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, neobrain, GB_2, filipf, davidedmundson, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21345
2019-06-17 09:07:19 +00:00
|
|
|
int gammaRampSize() const override;
|
|
|
|
bool setGammaRamp(const GammaRamp &gamma) override;
|
2021-04-11 14:26:21 +00:00
|
|
|
void setOverscan(uint32_t overscan) override;
|
2018-03-30 13:03:37 +00:00
|
|
|
|
2021-02-20 15:04:18 +00:00
|
|
|
void setVrr(bool enable);
|
|
|
|
bool isCursorVisible();
|
|
|
|
|
2016-03-21 14:11:17 +00:00
|
|
|
DrmBackend *m_backend;
|
2020-10-05 21:05:55 +00:00
|
|
|
DrmGpu *m_gpu;
|
[DRM plugin] Remember static kernel objects, amplify use of DrmCrtc
To get an image from KWin to the screen in the DRM pipeline we combine a CRTC,
an encoder and a connector. These objects are static in the sense, that they
represent real hardware on the graphics card, which doesn't change in a
session. See here for more details:
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html
Until now we used DrmOutput as the main representation for such an active
rendering pipeline. I.e. it gets created and destroyed on hot plug events of
displays. On the other side we had no fixed representation of the static kernel
objects throughout the lifetime of KWin. This has several disadvantages:
* We always need to query all available static objects on an hot plug event.
* We can't manipulate the frame buffer of a CRTC after an output has been
disconnected
* Adding functionality for driving multiple displays on a single CRTC (i.e.
cloning) would be difficult
* We can't destroy the last frame buffer on display disconnect because the CRTC
still accesses it and have therefore a memory leak on every display disconnect
This patch solves these issues by storing representations of all available CRTC
and Connector objects in DrmBackend on init via DrmCrtc and DrmConnector
instances. On an hotplug event these vectors are looped for a fitting CRTC and
Connector combinations. Buffer handling is moved to the respective CRTC
instance. All changes in overview:
* Query all available CRTCs and Connectors and save for subsequent hotplug
events
* Fix logic errors in `queryResources()`
* Move framebuffers, buffer flip and blank logic in DrmCrtc
* Remove `restoreSaved()`. It isn't necessary and is dangerous if the old
framebuffer was deleted in the meantime. Also could reveal sensitive user
info from old session.
Test Plan:
Login, logout, VT switching, connect and disconnect external monitor, energy
saving mode.
Reviewers: #kwin
Subscribers: kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5118
2017-05-09 18:02:49 +00:00
|
|
|
DrmConnector *m_conn = nullptr;
|
|
|
|
DrmCrtc *m_crtc = nullptr;
|
2021-04-20 10:53:02 +00:00
|
|
|
bool m_lastGbm = false;
|
|
|
|
drmModeModeInfo m_mode;
|
|
|
|
DpmsMode m_dpmsModePending = DpmsMode::On;
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
RenderLoop *m_renderLoop;
|
2016-03-21 14:11:17 +00:00
|
|
|
|
2021-04-20 10:53:02 +00:00
|
|
|
uint32_t m_blobId = 0;
|
|
|
|
DrmPlane *m_primaryPlane = nullptr;
|
|
|
|
QVector<DrmPlane*> m_nextPlanesFlipList;
|
2021-02-20 15:04:18 +00:00
|
|
|
|
|
|
|
QPoint m_cursorPos;
|
2017-05-09 19:29:10 +00:00
|
|
|
bool m_pageFlipPending = false;
|
2021-04-20 10:53:02 +00:00
|
|
|
bool m_atomicOffPending = false;
|
|
|
|
bool m_modesetRequested = true;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
Transform transform;
|
|
|
|
drmModeModeInfo mode;
|
|
|
|
DrmPlane::Transformations planeTransformations;
|
|
|
|
QPoint globalPos;
|
|
|
|
bool valid = false;
|
|
|
|
} m_lastWorkingState;
|
|
|
|
QScopedPointer<DrmDumbBuffer> m_cursor[2];
|
|
|
|
int m_cursorIndex = 0;
|
|
|
|
bool m_hasNewCursor = false;
|
2018-07-18 14:13:38 +00:00
|
|
|
bool m_deleted = false;
|
2016-08-31 12:00:31 +00:00
|
|
|
};
|
2016-03-21 14:11:17 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
Q_DECLARE_METATYPE(KWin::DrmOutput*)
|
|
|
|
|
|
|
|
#endif
|