2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2015-03-31 09:00:46 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2015 Martin Gräßlin <mgraesslin@kde.org>
|
|
|
|
SPDX-FileCopyrightText: 2019 Roman Gilg <subdiff@gmail.com>
|
2015-03-31 09:00:46 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2015-03-31 09:00:46 +00:00
|
|
|
#ifndef KWIN_FB_BACKEND_H
|
|
|
|
#define KWIN_FB_BACKEND_H
|
2019-06-13 09:36:07 +00:00
|
|
|
#include "abstract_wayland_output.h"
|
2016-04-07 07:24:17 +00:00
|
|
|
#include "platform.h"
|
2015-03-31 09:00:46 +00:00
|
|
|
|
|
|
|
#include <QImage>
|
|
|
|
#include <QSize>
|
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
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 FramebufferBackend;
|
|
|
|
class VsyncMonitor;
|
|
|
|
|
2019-06-13 09:36:07 +00:00
|
|
|
class FramebufferOutput : public AbstractWaylandOutput
|
2019-02-22 12:17:46 +00:00
|
|
|
{
|
|
|
|
Q_OBJECT
|
|
|
|
|
|
|
|
public:
|
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
|
|
|
explicit FramebufferOutput(FramebufferBackend *backend, QObject *parent = nullptr);
|
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
|
|
|
~FramebufferOutput() override = default;
|
2019-02-22 12:17:46 +00:00
|
|
|
|
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;
|
|
|
|
VsyncMonitor *vsyncMonitor() const;
|
|
|
|
|
2019-08-27 14:52:39 +00:00
|
|
|
void init(const QSize &pixelSize, const QSize &physicalSize);
|
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
|
|
|
|
|
|
|
private:
|
|
|
|
void vblank(std::chrono::nanoseconds timestamp);
|
|
|
|
|
|
|
|
RenderLoop *m_renderLoop = nullptr;
|
|
|
|
VsyncMonitor *m_vsyncMonitor = nullptr;
|
2019-02-22 12:17:46 +00:00
|
|
|
};
|
|
|
|
|
2016-04-07 07:18:10 +00:00
|
|
|
class KWIN_EXPORT FramebufferBackend : public Platform
|
2015-03-31 09:00:46 +00:00
|
|
|
{
|
|
|
|
Q_OBJECT
|
2016-04-07 07:18:10 +00:00
|
|
|
Q_INTERFACES(KWin::Platform)
|
|
|
|
Q_PLUGIN_METADATA(IID "org.kde.kwin.Platform" FILE "fbdev.json")
|
2015-03-31 09:00:46 +00:00
|
|
|
public:
|
|
|
|
explicit FramebufferBackend(QObject *parent = nullptr);
|
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
|
|
|
~FramebufferBackend() override;
|
2015-03-31 09:00:46 +00:00
|
|
|
|
|
|
|
QPainterBackend *createQPainterBackend() override;
|
|
|
|
|
2019-02-22 12:17:46 +00:00
|
|
|
QSize screenSize() const override;
|
2015-11-17 09:46:32 +00:00
|
|
|
|
2015-05-06 06:32:39 +00:00
|
|
|
void init() override;
|
2015-03-31 09:00:46 +00:00
|
|
|
|
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
|
|
|
int fileDescriptor() const;
|
2015-03-31 09:00:46 +00:00
|
|
|
bool isValid() const {
|
|
|
|
return m_fd >= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void map();
|
|
|
|
void unmap();
|
|
|
|
void *mappedMemory() const {
|
|
|
|
return m_memory;
|
|
|
|
}
|
|
|
|
int bytesPerLine() const {
|
|
|
|
return m_bytesPerLine;
|
|
|
|
}
|
|
|
|
int bufferSize() const {
|
|
|
|
return m_bufferLength;
|
|
|
|
}
|
|
|
|
quint32 bitsPerPixel() const {
|
|
|
|
return m_bitsPerPixel;
|
|
|
|
}
|
|
|
|
QImage::Format imageFormat() const;
|
2016-07-11 08:53:04 +00:00
|
|
|
/**
|
|
|
|
* @returns whether the imageFormat is BGR instead of RGB.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2016-07-11 08:53:04 +00:00
|
|
|
bool isBGR() const {
|
|
|
|
return m_bgr;
|
|
|
|
}
|
2015-03-31 09:00:46 +00:00
|
|
|
|
2019-02-22 12:17:46 +00:00
|
|
|
Outputs outputs() const override;
|
|
|
|
Outputs enabledOutputs() const override;
|
|
|
|
|
2017-10-15 20:24:49 +00:00
|
|
|
QVector<CompositingType> supportedCompositors() const override {
|
|
|
|
return QVector<CompositingType>{QPainterCompositing};
|
|
|
|
}
|
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
private:
|
|
|
|
void openFrameBuffer();
|
[platforms/fbdev] Attempt to set the framebuffer color layout on the framebuffer device
Summary:
Weston does something similar
https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-fbdev.c#n315
...and it seems that the non-primary framebuffer devices start completely off. (the screen is off on my Displayport device, and the window for the second vga card in qemu is much smaller than the primary one, and all black for my qemu vm) .
In my testing, sending the ioctl FBIOPUT_VSCREENINFO with a *changed* &varinfo allows it to wake up, and turns on the screen.
doing FBIOGET_VSCREENINFO and then FBIOPUT_VSCREENINFO in my testing does not work.
I think really the values that end up getting changed are varinfo.transp.offset and varinfo.transp.length. at least on the qemu system, but in this patch I am aligning all of them for completeness, because the drivers might do it differently for qemu
Test Plan: This causes the window for /dev/fb1 (remote-viewer, and a qemu vm with two "VGA" (bochsdrm) cards) to resize from the smaller size when specifying it as the --fb-device on seat0, and kwin draws on the device.
Reviewers: #kwin, davidedmundson, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, davidedmundson, rkflx, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9572
2018-08-13 14:17:59 +00:00
|
|
|
bool handleScreenInfo();
|
2016-07-11 08:53:04 +00:00
|
|
|
void initImageFormat();
|
2019-02-22 12:17:46 +00:00
|
|
|
|
|
|
|
QVector<FramebufferOutput*> m_outputs;
|
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
QByteArray m_id;
|
|
|
|
struct Color {
|
|
|
|
quint32 offset;
|
|
|
|
quint32 length;
|
|
|
|
};
|
|
|
|
Color m_red;
|
|
|
|
Color m_green;
|
|
|
|
Color m_blue;
|
|
|
|
Color m_alpha;
|
|
|
|
quint32 m_bitsPerPixel = 0;
|
|
|
|
int m_fd = -1;
|
|
|
|
quint32 m_bufferLength = 0;
|
|
|
|
int m_bytesPerLine = 0;
|
|
|
|
void *m_memory = nullptr;
|
2016-07-11 08:53:04 +00:00
|
|
|
QImage::Format m_imageFormat = QImage::Format_Invalid;
|
|
|
|
bool m_bgr = false;
|
2015-03-31 09:00:46 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|