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;
|
2021-05-25 22:05:17 +00:00
|
|
|
class DrmPipeline;
|
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;
|
|
|
|
|
2021-03-27 14:01:34 +00:00
|
|
|
bool showCursor();
|
|
|
|
bool hideCursor();
|
2021-04-20 10:53:02 +00:00
|
|
|
bool updateCursor();
|
2021-05-25 22:05:17 +00:00
|
|
|
bool moveCursor();
|
2021-05-25 17:55:15 +00:00
|
|
|
bool present(const QSharedPointer<DrmBuffer> &buffer, QRegion damagedRegion);
|
2021-04-20 10:53:02 +00:00
|
|
|
void pageFlipped();
|
2021-05-25 22:05:17 +00:00
|
|
|
bool isDpmsEnabled() const;
|
2016-03-21 14:11:17 +00:00
|
|
|
|
2021-05-25 22:05:17 +00:00
|
|
|
DrmPipeline *pipeline() const;
|
2021-05-25 17:55:15 +00:00
|
|
|
DrmBuffer *currentBuffer() const;
|
[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
|
|
|
|
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;
|
2021-05-25 22:05:17 +00:00
|
|
|
DrmOutput(DrmBackend *backend, DrmGpu* gpu, DrmPipeline *pipeline);
|
2021-04-20 10:53:02 +00:00
|
|
|
|
2021-05-25 21:08:31 +00:00
|
|
|
void initOutputDevice();
|
2021-04-20 10:53:02 +00:00
|
|
|
bool isCurrentMode(const drmModeModeInfo *mode) const;
|
|
|
|
|
2019-08-31 08:27:04 +00:00
|
|
|
void updateEnablement(bool enable) override;
|
2021-07-09 00:28:53 +00:00
|
|
|
void setDrmDpmsMode(DpmsMode mode);
|
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);
|
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
|
|
|
|
2016-03-21 14:11:17 +00:00
|
|
|
DrmBackend *m_backend;
|
2020-10-05 21:05:55 +00:00
|
|
|
DrmGpu *m_gpu;
|
2021-05-25 22:05:17 +00:00
|
|
|
DrmPipeline *m_pipeline;
|
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-05-25 22:05:17 +00:00
|
|
|
QSharedPointer<DrmDumbBuffer> m_cursor;
|
2017-05-09 19:29:10 +00:00
|
|
|
bool m_pageFlipPending = false;
|
2021-07-09 00:28:53 +00:00
|
|
|
QTimer m_turnOffTimer;
|
2016-08-31 12:00:31 +00:00
|
|
|
};
|
2016-03-21 14:11:17 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
Q_DECLARE_METATYPE(KWin::DrmOutput*)
|
|
|
|
|
|
|
|
#endif
|