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: 2019 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
|
|
|
|
*/
|
2019-06-13 09:36:07 +00:00
|
|
|
#ifndef KWIN_ABSTRACT_OUTPUT_H
|
|
|
|
#define KWIN_ABSTRACT_OUTPUT_H
|
2018-03-28 23:27:21 +00:00
|
|
|
|
|
|
|
#include <kwin_export.h>
|
|
|
|
|
2021-02-23 10:45:04 +00:00
|
|
|
#include <QDebug>
|
2018-03-28 23:27:21 +00:00
|
|
|
#include <QObject>
|
|
|
|
#include <QRect>
|
|
|
|
#include <QSize>
|
2021-04-06 20:08:02 +00:00
|
|
|
#include <QUuid>
|
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
|
|
|
#include <QVector>
|
2018-03-28 23:27:21 +00:00
|
|
|
|
2020-04-29 15:18:41 +00:00
|
|
|
namespace KWaylandServer
|
2019-08-28 18:54:37 +00:00
|
|
|
{
|
2021-07-21 10:11:21 +00:00
|
|
|
class OutputChangeSetV2;
|
2019-08-28 18:54:37 +00:00
|
|
|
}
|
|
|
|
|
2018-03-28 23:27:21 +00:00
|
|
|
namespace KWin
|
|
|
|
{
|
2021-10-01 07:23:30 +00:00
|
|
|
class EffectScreenImpl;
|
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
|
|
|
class RenderLoop;
|
|
|
|
|
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 KWIN_EXPORT GammaRamp
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
GammaRamp(uint32_t size);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the size of the gamma ramp.
|
2019-07-29 18:58:33 +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 size() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns pointer to the first red component in the gamma ramp.
|
|
|
|
*
|
|
|
|
* The returned pointer can be used for altering the red component
|
|
|
|
* in the gamma ramp.
|
2019-07-29 18:58:33 +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
|
|
|
uint16_t *red();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns pointer to the first red component in the gamma ramp.
|
2019-07-29 18:58:33 +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
|
|
|
const uint16_t *red() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns pointer to the first green component in the gamma ramp.
|
|
|
|
*
|
|
|
|
* The returned pointer can be used for altering the green component
|
|
|
|
* in the gamma ramp.
|
2019-07-29 18:58:33 +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
|
|
|
uint16_t *green();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns pointer to the first green component in the gamma ramp.
|
2019-07-29 18:58:33 +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
|
|
|
const uint16_t *green() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns pointer to the first blue component in the gamma ramp.
|
|
|
|
*
|
|
|
|
* The returned pointer can be used for altering the blue component
|
|
|
|
* in the gamma ramp.
|
2019-07-29 18:58:33 +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
|
|
|
uint16_t *blue();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns pointer to the first blue component in the gamma ramp.
|
2019-07-29 18:58:33 +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
|
|
|
const uint16_t *blue() const;
|
|
|
|
|
|
|
|
private:
|
|
|
|
QVector<uint16_t> m_table;
|
|
|
|
uint32_t m_size;
|
|
|
|
};
|
2018-03-30 13:03:37 +00:00
|
|
|
|
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
|
|
|
* Generic output representation.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2018-03-28 23:27:21 +00:00
|
|
|
class KWIN_EXPORT AbstractOutput : public QObject
|
|
|
|
{
|
|
|
|
Q_OBJECT
|
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
|
|
|
|
2018-03-28 23:27:21 +00:00
|
|
|
public:
|
|
|
|
explicit AbstractOutput(QObject *parent = nullptr);
|
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
|
|
|
~AbstractOutput() override;
|
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
|
|
|
/**
|
2020-04-08 09:38:41 +00:00
|
|
|
* Returns a short identifiable name of this output.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-06-13 09:36:07 +00:00
|
|
|
virtual QString name() const = 0;
|
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
|
|
|
|
2019-08-28 18:54:37 +00:00
|
|
|
/**
|
|
|
|
* Returns the identifying uuid of this output.
|
|
|
|
*
|
|
|
|
* Default implementation returns an empty byte array.
|
|
|
|
*/
|
2021-04-06 20:08:02 +00:00
|
|
|
virtual QUuid uuid() const;
|
2019-08-28 18:54:37 +00:00
|
|
|
|
2021-01-22 08:22:24 +00:00
|
|
|
/**
|
|
|
|
* Returns @c true if the output is enabled; otherwise returns @c false.
|
|
|
|
*/
|
|
|
|
virtual bool isEnabled() const;
|
|
|
|
|
2019-08-28 18:54:37 +00:00
|
|
|
/**
|
|
|
|
* Enable or disable the output.
|
|
|
|
*
|
|
|
|
* Default implementation does nothing
|
|
|
|
*/
|
|
|
|
virtual void setEnabled(bool 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
|
|
|
/**
|
|
|
|
* Returns geometry of this output in device independent pixels.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-06-13 09:36:07 +00:00
|
|
|
virtual QRect geometry() const = 0;
|
2018-03-28 23:27:21 +00:00
|
|
|
|
2019-02-02 18:17:44 +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
|
|
|
* Returns the approximate vertical refresh rate of this output, in mHz.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-06-13 09:36:07 +00:00
|
|
|
virtual int refreshRate() const = 0;
|
2018-11-09 22:17:27 +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
|
|
|
/**
|
|
|
|
* Returns whether this output is connected through an internal connector,
|
|
|
|
* e.g. LVDS, or eDP.
|
|
|
|
*
|
|
|
|
* Default implementation returns @c false.
|
2019-07-29 18:58:33 +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
|
|
|
virtual bool isInternal() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the ratio between physical pixels and logical pixels.
|
|
|
|
*
|
|
|
|
* Default implementation returns 1.
|
2019-07-29 18:58:33 +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
|
|
|
virtual qreal scale() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the physical size of this output, in millimeters.
|
|
|
|
*
|
|
|
|
* Default implementation returns an invalid QSize.
|
2019-07-29 18:58:33 +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
|
|
|
virtual QSize physicalSize() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the size of the gamma lookup table.
|
|
|
|
*
|
|
|
|
* Default implementation returns 0.
|
2019-07-29 18:58:33 +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
|
|
|
virtual int gammaRampSize() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Sets the gamma ramp of this output.
|
|
|
|
*
|
|
|
|
* Returns @c true if the gamma ramp was successfully set.
|
2019-07-29 18:58:33 +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
|
|
|
virtual bool setGammaRamp(const GammaRamp &gamma);
|
|
|
|
|
2020-07-22 17:22:36 +00:00
|
|
|
/** Returns the resolution of the output. */
|
|
|
|
virtual QSize pixelSize() const = 0;
|
|
|
|
|
2020-11-24 17:31:06 +00:00
|
|
|
/**
|
|
|
|
* Returns the manufacturer of the screen.
|
|
|
|
*/
|
|
|
|
virtual QString manufacturer() const;
|
|
|
|
/**
|
|
|
|
* Returns the model of the screen.
|
|
|
|
*/
|
|
|
|
virtual QString model() const;
|
|
|
|
/**
|
|
|
|
* Returns the serial number of the screen.
|
|
|
|
*/
|
|
|
|
virtual QString serialNumber() const;
|
|
|
|
|
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
|
|
|
/**
|
2022-02-05 13:20:17 +00:00
|
|
|
* Returns the RenderLoop for this output. If the platform does not support per screen
|
|
|
|
* rendering, all outputs will share the same render loop.
|
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
|
|
|
*/
|
2022-02-05 13:20:17 +00:00
|
|
|
virtual RenderLoop *renderLoop() const = 0;
|
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
|
|
|
|
2021-02-02 13:26:43 +00:00
|
|
|
void inhibitDirectScanout();
|
|
|
|
void uninhibitDirectScanout();
|
|
|
|
|
|
|
|
bool directScanoutInhibited() const;
|
|
|
|
|
2021-07-09 00:28:53 +00:00
|
|
|
/**
|
|
|
|
* @returns the configured time for an output to dim
|
|
|
|
*
|
|
|
|
* This allows the backends to coordinate with the front-end the time they
|
|
|
|
* allow to decorate the dimming until the display is turned off
|
|
|
|
*
|
|
|
|
* @see aboutToTurnOff
|
|
|
|
*/
|
|
|
|
static std::chrono::milliseconds dimAnimationTime();
|
|
|
|
|
2021-07-29 02:07:13 +00:00
|
|
|
enum class Transform {
|
|
|
|
Normal,
|
|
|
|
Rotated90,
|
|
|
|
Rotated180,
|
|
|
|
Rotated270,
|
|
|
|
Flipped,
|
|
|
|
Flipped90,
|
|
|
|
Flipped180,
|
|
|
|
Flipped270
|
|
|
|
};
|
|
|
|
Q_ENUM(Transform)
|
|
|
|
virtual Transform transform() const { return Transform::Normal; }
|
|
|
|
|
2021-12-25 17:12:12 +00:00
|
|
|
virtual bool usesSoftwareCursor() const;
|
|
|
|
|
2020-08-18 18:38:12 +00:00
|
|
|
Q_SIGNALS:
|
|
|
|
/**
|
|
|
|
* This signal is emitted when the geometry of this output has changed.
|
|
|
|
*/
|
|
|
|
void geometryChanged();
|
2021-01-22 08:22:24 +00:00
|
|
|
/**
|
|
|
|
* This signal is emitted when the output has been enabled or disabled.
|
|
|
|
*/
|
|
|
|
void enabledChanged();
|
2021-07-23 07:37:18 +00:00
|
|
|
/**
|
|
|
|
* This signal is emitted when the device pixel ratio of the output has changed.
|
|
|
|
*/
|
|
|
|
void scaleChanged();
|
2020-08-18 18:38:12 +00:00
|
|
|
|
2021-07-09 00:28:53 +00:00
|
|
|
/**
|
|
|
|
* Notifies that the display will be dimmed in @p time ms. This allows
|
|
|
|
* effects to plan for it and hopefully animate it
|
|
|
|
*/
|
|
|
|
void aboutToTurnOff(std::chrono::milliseconds time);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Notifies that the output has been turned on and the wake can be decorated.
|
|
|
|
*/
|
|
|
|
void wakeUp();
|
|
|
|
|
2021-07-27 17:42:21 +00:00
|
|
|
/**
|
|
|
|
* Notifies that the output is about to change configuration based on a
|
|
|
|
* user interaction.
|
|
|
|
*
|
|
|
|
* Be it because it gets a transformation or moved around.
|
|
|
|
*
|
|
|
|
* Only to be used for effects
|
|
|
|
*/
|
|
|
|
void aboutToChange();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Notifies that the output changed based on a user interaction.
|
|
|
|
*
|
|
|
|
* Be it because it gets a transformation or moved around.
|
|
|
|
*
|
|
|
|
* Only to be used for effects
|
|
|
|
*/
|
|
|
|
void changed();
|
|
|
|
|
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
|
|
|
private:
|
|
|
|
Q_DISABLE_COPY(AbstractOutput)
|
2021-10-01 07:23:30 +00:00
|
|
|
EffectScreenImpl *m_effectScreen = nullptr;
|
2021-02-02 13:26:43 +00:00
|
|
|
int m_directScanoutCount = 0;
|
2021-10-01 07:23:30 +00:00
|
|
|
friend class EffectScreenImpl; // to access m_effectScreen
|
2018-03-28 23:27:21 +00:00
|
|
|
};
|
|
|
|
|
2021-02-23 10:45:04 +00:00
|
|
|
KWIN_EXPORT QDebug operator<<(QDebug debug, const AbstractOutput *output);
|
|
|
|
|
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
|
2018-03-28 23:27:21 +00:00
|
|
|
|
2019-06-13 09:36:07 +00:00
|
|
|
#endif
|