2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2018-03-28 23:27:21 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2018 Roman Gilg <subdiff@gmail.com>
|
2018-03-28 23:27:21 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
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
|
|
|
|
2018-03-28 23:27:21 +00:00
|
|
|
#include "abstract_output.h"
|
2021-07-09 00:28:53 +00:00
|
|
|
#include <KSharedConfig>
|
|
|
|
#include <KConfigGroup>
|
2018-03-28 23:27:21 +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
|
|
|
namespace KWin
|
|
|
|
{
|
2018-03-28 23:27:21 +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
|
|
|
GammaRamp::GammaRamp(uint32_t size)
|
|
|
|
: m_table(3 * size)
|
|
|
|
, m_size(size)
|
|
|
|
{
|
|
|
|
}
|
2018-03-28 23:27:21 +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
|
|
|
uint32_t GammaRamp::size() const
|
2018-03-28 23:27:21 +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
|
|
|
return m_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint16_t *GammaRamp::red()
|
|
|
|
{
|
|
|
|
return m_table.data();
|
|
|
|
}
|
|
|
|
|
|
|
|
const uint16_t *GammaRamp::red() const
|
|
|
|
{
|
|
|
|
return m_table.data();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint16_t *GammaRamp::green()
|
|
|
|
{
|
|
|
|
return m_table.data() + m_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
const uint16_t *GammaRamp::green() const
|
|
|
|
{
|
|
|
|
return m_table.data() + m_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint16_t *GammaRamp::blue()
|
|
|
|
{
|
|
|
|
return m_table.data() + 2 * m_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
const uint16_t *GammaRamp::blue() const
|
|
|
|
{
|
|
|
|
return m_table.data() + 2 * m_size;
|
|
|
|
}
|
2018-03-28 23:27:21 +00:00
|
|
|
|
2021-02-23 10:45:04 +00:00
|
|
|
QDebug operator<<(QDebug debug, const AbstractOutput *output)
|
|
|
|
{
|
|
|
|
QDebugStateSaver saver(debug);
|
|
|
|
debug.nospace();
|
|
|
|
if (output) {
|
|
|
|
debug << output->metaObject()->className() << '(' << static_cast<const void *>(output);
|
|
|
|
debug << ", name=" << output->name();
|
|
|
|
debug << ", geometry=" << output->geometry();
|
|
|
|
debug << ", scale=" << output->scale();
|
|
|
|
if (debug.verbosity() > 2) {
|
|
|
|
debug << ", manufacturer=" << output->manufacturer();
|
|
|
|
debug << ", model=" << output->model();
|
|
|
|
debug << ", serialNumber=" << output->serialNumber();
|
|
|
|
}
|
|
|
|
debug << ')';
|
|
|
|
} else {
|
|
|
|
debug << "AbstractOutput(0x0)";
|
|
|
|
}
|
|
|
|
return debug;
|
|
|
|
}
|
|
|
|
|
2018-03-28 23:27:21 +00:00
|
|
|
AbstractOutput::AbstractOutput(QObject *parent)
|
|
|
|
: QObject(parent)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
AbstractOutput::~AbstractOutput()
|
|
|
|
{
|
2018-11-09 22:53:02 +00:00
|
|
|
}
|
|
|
|
|
2021-04-06 20:08:02 +00:00
|
|
|
QUuid AbstractOutput::uuid() const
|
2019-08-28 18:54:37 +00:00
|
|
|
{
|
2021-04-06 20:08:02 +00:00
|
|
|
return QUuid();
|
2019-08-28 18:54:37 +00:00
|
|
|
}
|
|
|
|
|
2021-01-22 08:22:24 +00:00
|
|
|
bool AbstractOutput::isEnabled() const
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-08-28 18:54:37 +00:00
|
|
|
void AbstractOutput::setEnabled(bool enable)
|
|
|
|
{
|
|
|
|
Q_UNUSED(enable)
|
|
|
|
}
|
|
|
|
|
Overhaul AbstractOutput
Summary:
There are several issues with code of AbstractOutput class:
(a) Some methods are documented, and some are not. In general, we tend
to document all public methods in KWin core. It looks like a very
minor issue, but there are methods that have very ambiguous return
value. One such method is geometry(). It's not obvious whether the
returned geometry is in device independent pixels or not;
(b) There's a mix of methods defined in the cpp file and in the header.
This is not very good because reading such code becomes a bit harder
if you don't use any fancy IDE;
(c) Missing Q_DISABLE_COPY, etc.
This change addresses these issues, so the code is a bit more readable
and easier to work with.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: broulik, cfeck, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21874
2019-06-17 10:16:26 +00:00
|
|
|
bool AbstractOutput::isInternal() const
|
|
|
|
{
|
|
|
|
return false;
|
2018-03-28 23:27:21 +00:00
|
|
|
}
|
Overhaul AbstractOutput
Summary:
There are several issues with code of AbstractOutput class:
(a) Some methods are documented, and some are not. In general, we tend
to document all public methods in KWin core. It looks like a very
minor issue, but there are methods that have very ambiguous return
value. One such method is geometry(). It's not obvious whether the
returned geometry is in device independent pixels or not;
(b) There's a mix of methods defined in the cpp file and in the header.
This is not very good because reading such code becomes a bit harder
if you don't use any fancy IDE;
(c) Missing Q_DISABLE_COPY, etc.
This change addresses these issues, so the code is a bit more readable
and easier to work with.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: broulik, cfeck, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21874
2019-06-17 10:16:26 +00:00
|
|
|
|
|
|
|
qreal AbstractOutput::scale() const
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
QSize AbstractOutput::physicalSize() const
|
|
|
|
{
|
|
|
|
return QSize();
|
|
|
|
}
|
|
|
|
|
|
|
|
int AbstractOutput::gammaRampSize() const
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool AbstractOutput::setGammaRamp(const GammaRamp &gamma)
|
|
|
|
{
|
|
|
|
Q_UNUSED(gamma);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-11-24 17:31:06 +00:00
|
|
|
QString AbstractOutput::manufacturer() const
|
|
|
|
{
|
|
|
|
return QString();
|
|
|
|
}
|
|
|
|
|
|
|
|
QString AbstractOutput::model() const
|
|
|
|
{
|
|
|
|
return QString();
|
|
|
|
}
|
|
|
|
|
|
|
|
QString AbstractOutput::serialNumber() const
|
|
|
|
{
|
|
|
|
return QString();
|
|
|
|
}
|
|
|
|
|
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 *AbstractOutput::renderLoop() const
|
|
|
|
{
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2021-02-02 13:26:43 +00:00
|
|
|
void AbstractOutput::inhibitDirectScanout()
|
|
|
|
{
|
|
|
|
m_directScanoutCount++;
|
|
|
|
}
|
|
|
|
void AbstractOutput::uninhibitDirectScanout()
|
|
|
|
{
|
|
|
|
m_directScanoutCount--;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool AbstractOutput::directScanoutInhibited() const
|
|
|
|
{
|
|
|
|
return m_directScanoutCount;
|
|
|
|
}
|
|
|
|
|
2021-07-09 00:28:53 +00:00
|
|
|
std::chrono::milliseconds AbstractOutput::dimAnimationTime()
|
|
|
|
{
|
|
|
|
// See kscreen.kcfg
|
|
|
|
return std::chrono::milliseconds (KSharedConfig::openConfig()->group("Effect-Kscreen").readEntry("Duration", 250));
|
|
|
|
}
|
|
|
|
|
2021-12-25 17:12:12 +00:00
|
|
|
bool AbstractOutput::usesSoftwareCursor() const
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
Overhaul AbstractOutput
Summary:
There are several issues with code of AbstractOutput class:
(a) Some methods are documented, and some are not. In general, we tend
to document all public methods in KWin core. It looks like a very
minor issue, but there are methods that have very ambiguous return
value. One such method is geometry(). It's not obvious whether the
returned geometry is in device independent pixels or not;
(b) There's a mix of methods defined in the cpp file and in the header.
This is not very good because reading such code becomes a bit harder
if you don't use any fancy IDE;
(c) Missing Q_DISABLE_COPY, etc.
This change addresses these issues, so the code is a bit more readable
and easier to work with.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: broulik, cfeck, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21874
2019-06-17 10:16:26 +00:00
|
|
|
} // namespace KWin
|