kwin/src/plugins/platforms/drm/drm_object_crtc.h

87 lines
1.7 KiB
C
Raw Normal View History

2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2016 Roman Gilg <subdiff@gmail.com>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#ifndef KWIN_DRM_OBJECT_CRTC_H
#define KWIN_DRM_OBJECT_CRTC_H
#include "drm_object.h"
2021-03-22 14:46:09 +00:00
#include <QSharedPointer>
namespace KWin
{
[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
class DrmBackend;
class DrmBuffer;
class DrmDumbBuffer;
class GammaRamp;
class DrmGpu;
class DrmCrtc : public DrmObject
{
public:
DrmCrtc(DrmGpu *gpu, uint32_t crtcId, int pipeIndex);
bool init() override;
2021-03-10 21:04:32 +00:00
enum class PropertyIndex : uint32_t {
ModeId = 0,
Active,
VrrEnabled,
Gamma_LUT,
Gamma_LUT_size,
Count
};
int pipeIndex() const {
return m_pipeIndex;
[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
}
QSharedPointer<DrmBuffer> current() const {
[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
return m_currentBuffer;
}
QSharedPointer<DrmBuffer> next() const {
[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
return m_nextBuffer;
}
void setCurrent(const QSharedPointer<DrmBuffer> &buffer) {
m_currentBuffer = buffer;
}
2021-03-22 14:46:09 +00:00
void setNext(const QSharedPointer<DrmBuffer> &buffer) {
[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
m_nextBuffer = buffer;
}
void flipBuffer();
int gammaRampSize() const {
if (auto prop = getProp(PropertyIndex::Gamma_LUT_size)) {
return prop->current();
}
2021-03-10 21:04:32 +00:00
return m_crtc->gamma_size;
[colorcorrection] Night Color - blue light filter at nighttime With Wayland KWin needs to provide certain services, which were provided before that by the Xserver. One of these is gamma correction, which includes the - by many people beloved - functionality to reduce the blue light at nighttime. This patch provides the KWin part of that. It is self contained, but in the end will work in tandem with a lib in Plasma Workspace and a KCM in Plasma Desktop, which can be used to configure Night Color. * Three modi: ** Automatic: The location and sun timings are determined automatically (location data updates will be provided by the workspace) ** Location: The sun timings are determined by fixed location data ** Timings: The sun timings are set manually by the user * Color temperature value changes are smoothly applied: ** Configuration changes, which lead to other current values are changed in a quick way over a few seconds ** Changes on sunrise and sunset are applied slowly over the course of few minutes till several hours depending on the configuration * The current color value is set immediately at startup or after suspend phases and VT switches. There is no flickering. * All configuration is done via a DBus interface, changed values are tested on correctness and applied atomically * Self contained mechanism, speaks directly to the hardware by setting the gamma ramps on the CRTC * Currently working on DRM backend, extensible to other platform backends in the future * The code is written in a way to make the classes later easily extendable to also provide normal color correction, as it's currently done by KGamma on X Test Plan: Manually with the workspace parts and added integration tests in KWin using the virtual backend. BUG:371494 Reviewers: #kwin, graesslin Subscribers: kwin, plasma-devel, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5928
2017-12-11 09:43:12 +00:00
}
bool setGammaRamp(const GammaRamp &gamma);
2020-11-27 19:57:24 +00:00
bool setVrr(bool enable);
bool isVrrEnabled() const;
drmModeModeInfo queryCurrentMode();
bool needsModeset() const override;
[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
private:
2021-03-10 21:04:32 +00:00
DrmScopedPointer<drmModeCrtc> m_crtc;
2021-03-22 14:46:09 +00:00
QSharedPointer<DrmBuffer> m_currentBuffer;
QSharedPointer<DrmBuffer> m_nextBuffer;
DrmDumbBuffer *m_blackBuffer = nullptr;
int m_pipeIndex;
};
}
#endif