2016-08-31 12:00:31 +00:00
|
|
|
/********************************************************************
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
|
|
|
|
|
|
|
Copyright (C) 2016 Roman Gilg <subdiff@gmail.com>
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; either version 2 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*********************************************************************/
|
|
|
|
#ifndef KWIN_DRM_OBJECT_CRTC_H
|
|
|
|
#define KWIN_DRM_OBJECT_CRTC_H
|
|
|
|
|
|
|
|
#include "drm_object.h"
|
|
|
|
|
|
|
|
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;
|
2016-08-31 12:00:31 +00:00
|
|
|
class DrmBuffer;
|
2017-05-09 19:00:33 +00:00
|
|
|
class DrmDumbBuffer;
|
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
|
|
|
class GammaRamp;
|
2016-08-31 12:00:31 +00:00
|
|
|
|
|
|
|
class DrmCrtc : public DrmObject
|
|
|
|
{
|
|
|
|
public:
|
2017-05-09 19:29:10 +00:00
|
|
|
DrmCrtc(uint32_t crtc_id, DrmBackend *backend, int resIndex);
|
2016-08-31 12:00:31 +00:00
|
|
|
|
Run clang-tidy with modernize-use-override check
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
|
|
|
~DrmCrtc() override;
|
2016-08-31 12:00:31 +00:00
|
|
|
|
Run clang-tidy with modernize-use-override check
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
|
|
|
bool atomicInit() override;
|
2016-08-31 12:00:31 +00:00
|
|
|
|
|
|
|
enum class PropertyIndex {
|
|
|
|
ModeId = 0,
|
|
|
|
Active,
|
|
|
|
Count
|
|
|
|
};
|
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
|
|
|
|
Run clang-tidy with modernize-use-override check
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
|
|
|
bool initProps() 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
|
|
|
|
|
|
|
int resIndex() const {
|
|
|
|
return m_resIndex;
|
|
|
|
}
|
|
|
|
|
|
|
|
DrmBuffer *current() {
|
|
|
|
return m_currentBuffer;
|
|
|
|
}
|
|
|
|
DrmBuffer *next() {
|
|
|
|
return m_nextBuffer;
|
|
|
|
}
|
|
|
|
void setNext(DrmBuffer *buffer) {
|
|
|
|
m_nextBuffer = buffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
void flipBuffer();
|
|
|
|
bool blank();
|
|
|
|
|
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 {
|
[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
|
|
|
return m_gammaRampSize;
|
|
|
|
}
|
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
|
|
|
bool setGammaRamp(const GammaRamp &gamma);
|
[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
|
|
|
|
[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:
|
|
|
|
int m_resIndex;
|
[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
|
|
|
uint32_t m_gammaRampSize = 0;
|
[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
|
|
|
|
|
|
|
DrmBuffer *m_currentBuffer = nullptr;
|
|
|
|
DrmBuffer *m_nextBuffer = nullptr;
|
2017-05-09 19:00:33 +00:00
|
|
|
DrmDumbBuffer *m_blackBuffer = nullptr;
|
2017-11-12 20:00:02 +00:00
|
|
|
DrmBackend *m_backend;
|
2016-08-31 12:00:31 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|