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>
|
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
|
|
|
#include "fb_backend.h"
|
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
|
|
|
#include "fbvsyncmonitor.h"
|
2019-02-22 12:17:46 +00:00
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
#include "composite.h"
|
2015-05-05 15:27:03 +00:00
|
|
|
#include "logging.h"
|
2015-03-31 09:00:46 +00:00
|
|
|
#include "logind.h"
|
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
|
|
|
#include "renderloop_p.h"
|
2015-05-05 13:04:15 +00:00
|
|
|
#include "scene_qpainter_fb_backend.h"
|
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
|
|
|
#include "softwarevsyncmonitor.h"
|
2015-03-31 09:00:46 +00:00
|
|
|
#include "virtual_terminal.h"
|
2018-04-22 15:51:09 +00:00
|
|
|
#include "udev.h"
|
2015-03-31 09:00:46 +00:00
|
|
|
// system
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <sys/ioctl.h>
|
|
|
|
#include <sys/mman.h>
|
|
|
|
// Linux
|
|
|
|
#include <linux/fb.h>
|
|
|
|
|
|
|
|
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
|
|
|
FramebufferOutput::FramebufferOutput(FramebufferBackend *backend, QObject *parent)
|
|
|
|
: AbstractWaylandOutput(parent)
|
|
|
|
, m_renderLoop(new RenderLoop(this))
|
2020-04-08 09:38:41 +00:00
|
|
|
{
|
|
|
|
setName("FB-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
|
|
|
|
|
|
|
if (!qEnvironmentVariableIsSet("KWIN_FB_NO_HW_VSYNC")) {
|
|
|
|
m_vsyncMonitor = FramebufferVsyncMonitor::create(backend->fileDescriptor(), this);
|
|
|
|
}
|
|
|
|
if (!m_vsyncMonitor) {
|
|
|
|
SoftwareVsyncMonitor *monitor = SoftwareVsyncMonitor::create(this);
|
|
|
|
monitor->setRefreshRate(m_renderLoop->refreshRate());
|
|
|
|
connect(m_renderLoop, &RenderLoop::refreshRateChanged, this, [this, monitor]() {
|
|
|
|
monitor->setRefreshRate(m_renderLoop->refreshRate());
|
|
|
|
});
|
|
|
|
m_vsyncMonitor = monitor;
|
|
|
|
}
|
|
|
|
|
|
|
|
connect(m_vsyncMonitor, &VsyncMonitor::vblankOccurred, this, &FramebufferOutput::vblank);
|
|
|
|
}
|
|
|
|
|
|
|
|
RenderLoop *FramebufferOutput::renderLoop() const
|
|
|
|
{
|
|
|
|
return m_renderLoop;
|
|
|
|
}
|
|
|
|
|
|
|
|
VsyncMonitor *FramebufferOutput::vsyncMonitor() const
|
|
|
|
{
|
|
|
|
return m_vsyncMonitor;
|
2020-04-08 09:38:41 +00:00
|
|
|
}
|
|
|
|
|
2019-08-27 14:52:39 +00:00
|
|
|
void FramebufferOutput::init(const QSize &pixelSize, const QSize &physicalSize)
|
2019-08-27 10:28:19 +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
|
|
|
const int refreshRate = 60000; // TODO: get actual refresh rate of fb device?
|
|
|
|
m_renderLoop->setRefreshRate(refreshRate);
|
|
|
|
|
2020-04-29 15:18:41 +00:00
|
|
|
KWaylandServer::OutputDeviceInterface::Mode mode;
|
2019-08-27 10:28:19 +00:00
|
|
|
mode.id = 0;
|
2019-08-27 14:52:39 +00:00
|
|
|
mode.size = pixelSize;
|
2020-04-29 15:18:41 +00:00
|
|
|
mode.flags = KWaylandServer::OutputDeviceInterface::ModeFlag::Current;
|
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
|
|
|
mode.refreshRate = refreshRate;
|
2020-10-26 17:29:33 +00:00
|
|
|
initInterfaces("model_TODO", "manufacturer_TODO", "UUID_TODO", physicalSize, { mode }, {});
|
2019-08-27 10:28:19 +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
|
|
|
void FramebufferOutput::vblank(std::chrono::nanoseconds timestamp)
|
|
|
|
{
|
|
|
|
RenderLoopPrivate *renderLoopPrivate = RenderLoopPrivate::get(m_renderLoop);
|
|
|
|
renderLoopPrivate->notifyFrameCompleted(timestamp);
|
|
|
|
}
|
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
FramebufferBackend::FramebufferBackend(QObject *parent)
|
2016-04-07 07:18:10 +00:00
|
|
|
: Platform(parent)
|
2015-03-31 09:00:46 +00:00
|
|
|
{
|
2020-11-09 12:19:15 +00:00
|
|
|
setPerScreenRenderingEnabled(true);
|
2015-03-31 09:00:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
FramebufferBackend::~FramebufferBackend()
|
|
|
|
{
|
|
|
|
unmap();
|
|
|
|
if (m_fd >= 0) {
|
|
|
|
close(m_fd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
QPainterBackend *FramebufferBackend::createQPainterBackend()
|
|
|
|
{
|
|
|
|
return new FramebufferQPainterBackend(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
void FramebufferBackend::init()
|
|
|
|
{
|
2020-10-28 07:03:09 +00:00
|
|
|
setSoftwareCursorForced(true);
|
2015-03-31 09:00:46 +00:00
|
|
|
LogindIntegration *logind = LogindIntegration::self();
|
|
|
|
auto takeControl = [logind, this]() {
|
|
|
|
if (logind->hasSessionControl()) {
|
|
|
|
openFrameBuffer();
|
|
|
|
} else {
|
|
|
|
logind->takeControl();
|
|
|
|
connect(logind, &LogindIntegration::hasSessionControlChanged, this, &FramebufferBackend::openFrameBuffer);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
if (logind->isConnected()) {
|
|
|
|
takeControl();
|
|
|
|
} else {
|
|
|
|
connect(logind, &LogindIntegration::connectedChanged, this, takeControl);
|
|
|
|
}
|
2015-04-08 13:12:06 +00:00
|
|
|
VirtualTerminal::create(this);
|
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 FramebufferBackend::fileDescriptor() const
|
|
|
|
{
|
|
|
|
return m_fd;
|
|
|
|
}
|
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
void FramebufferBackend::openFrameBuffer()
|
|
|
|
{
|
2015-04-08 13:12:06 +00:00
|
|
|
VirtualTerminal::self()->init();
|
2018-04-22 15:51:09 +00:00
|
|
|
QString framebufferDevice = deviceIdentifier().constData();
|
|
|
|
if (framebufferDevice.isEmpty()) {
|
2020-10-05 21:05:55 +00:00
|
|
|
framebufferDevice = QString(Udev().listFramebuffers().at(0)->devNode());
|
2018-04-22 15:51:09 +00:00
|
|
|
}
|
|
|
|
int fd = LogindIntegration::self()->takeDevice(framebufferDevice.toUtf8().constData());
|
|
|
|
qCDebug(KWIN_FB) << "Using frame buffer device:" << framebufferDevice;
|
2015-03-31 09:00:46 +00:00
|
|
|
if (fd < 0) {
|
2018-04-22 15:51:09 +00:00
|
|
|
qCWarning(KWIN_FB) << "Failed to open frame buffer device:" << framebufferDevice << "through logind, trying without";
|
2015-03-31 09:00:46 +00:00
|
|
|
}
|
2018-04-22 15:51:09 +00:00
|
|
|
fd = open(framebufferDevice.toUtf8().constData(), O_RDWR | O_CLOEXEC);
|
2015-03-31 09:00:46 +00:00
|
|
|
if (fd < 0) {
|
2018-04-22 15:51:09 +00:00
|
|
|
qCWarning(KWIN_FB) << "failed to open frame buffer device:" << framebufferDevice;
|
2016-07-13 08:08:25 +00:00
|
|
|
emit initFailed();
|
2015-03-31 09:00:46 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
m_fd = fd;
|
[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
|
|
|
if (!handleScreenInfo()) {
|
|
|
|
qCWarning(KWIN_FB) << "failed to handle framebuffer information";
|
2016-07-13 08:08:25 +00:00
|
|
|
emit initFailed();
|
|
|
|
return;
|
|
|
|
}
|
2016-07-11 08:53:04 +00:00
|
|
|
initImageFormat();
|
2016-07-13 08:08:25 +00:00
|
|
|
if (m_imageFormat == QImage::Format_Invalid) {
|
|
|
|
emit initFailed();
|
|
|
|
return;
|
|
|
|
}
|
2015-05-05 17:02:52 +00:00
|
|
|
setReady(true);
|
2015-03-31 09:00:46 +00:00
|
|
|
emit screensQueried();
|
|
|
|
}
|
|
|
|
|
[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 FramebufferBackend::handleScreenInfo()
|
2015-03-31 09:00:46 +00:00
|
|
|
{
|
|
|
|
if (m_fd < 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
fb_var_screeninfo varinfo;
|
|
|
|
fb_fix_screeninfo fixinfo;
|
|
|
|
|
|
|
|
// Probe the device for screen information.
|
|
|
|
if (ioctl(m_fd, FBIOGET_FSCREENINFO, &fixinfo) < 0 || ioctl(m_fd, FBIOGET_VSCREENINFO, &varinfo) < 0) {
|
|
|
|
return false;
|
|
|
|
}
|
[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
|
|
|
|
2019-03-13 08:49:04 +00:00
|
|
|
// Activate the framebuffer device, assuming this is a non-primary framebuffer device
|
|
|
|
varinfo.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
|
[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
|
|
|
ioctl(m_fd, FBIOPUT_VSCREENINFO, &varinfo);
|
|
|
|
|
|
|
|
// Probe the device for new screen information.
|
|
|
|
if (ioctl(m_fd, FBIOGET_VSCREENINFO, &varinfo) < 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-02-22 12:17:46 +00:00
|
|
|
auto *output = new FramebufferOutput(this);
|
2019-08-27 14:52:39 +00:00
|
|
|
output->init(QSize(varinfo.xres, varinfo.yres), QSize(varinfo.width, varinfo.height));
|
2019-02-22 12:17:46 +00:00
|
|
|
m_outputs << output;
|
2020-12-02 18:17:52 +00:00
|
|
|
emit outputAdded(output);
|
2020-12-09 14:01:29 +00:00
|
|
|
emit outputEnabled(output);
|
2019-02-22 12:17:46 +00:00
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
m_id = QByteArray(fixinfo.id);
|
|
|
|
m_red = {varinfo.red.offset, varinfo.red.length};
|
|
|
|
m_green = {varinfo.green.offset, varinfo.green.length};
|
|
|
|
m_blue = {varinfo.blue.offset, varinfo.blue.length};
|
|
|
|
m_alpha = {varinfo.transp.offset, varinfo.transp.length};
|
|
|
|
m_bitsPerPixel = varinfo.bits_per_pixel;
|
|
|
|
m_bufferLength = fixinfo.smem_len;
|
|
|
|
m_bytesPerLine = fixinfo.line_length;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void FramebufferBackend::map()
|
|
|
|
{
|
|
|
|
if (m_memory) {
|
|
|
|
// already mapped;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (m_fd < 0) {
|
|
|
|
// not valid
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
void *mem = mmap(nullptr, m_bufferLength, PROT_WRITE, MAP_SHARED, m_fd, 0);
|
|
|
|
if (mem == MAP_FAILED) {
|
2015-05-05 15:27:03 +00:00
|
|
|
qCWarning(KWIN_FB) << "Failed to mmap frame buffer";
|
2015-03-31 09:00:46 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
m_memory = mem;
|
|
|
|
}
|
|
|
|
|
|
|
|
void FramebufferBackend::unmap()
|
|
|
|
{
|
|
|
|
if (!m_memory) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (munmap(m_memory, m_bufferLength) < 0) {
|
2015-05-05 15:27:03 +00:00
|
|
|
qCWarning(KWIN_FB) << "Failed to munmap frame buffer";
|
2015-03-31 09:00:46 +00:00
|
|
|
}
|
|
|
|
m_memory = nullptr;
|
|
|
|
}
|
|
|
|
|
2019-02-22 12:17:46 +00:00
|
|
|
QSize FramebufferBackend::screenSize() const
|
|
|
|
{
|
|
|
|
if (m_outputs.isEmpty()) {
|
|
|
|
return QSize();
|
|
|
|
}
|
|
|
|
return m_outputs[0]->pixelSize();
|
|
|
|
}
|
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
QImage::Format FramebufferBackend::imageFormat() const
|
2016-07-11 08:53:04 +00:00
|
|
|
{
|
|
|
|
return m_imageFormat;
|
|
|
|
}
|
|
|
|
|
|
|
|
void FramebufferBackend::initImageFormat()
|
2015-03-31 09:00:46 +00:00
|
|
|
{
|
|
|
|
if (m_fd < 0) {
|
2016-07-11 08:53:04 +00:00
|
|
|
return;
|
2015-03-31 09:00:46 +00:00
|
|
|
}
|
2015-12-15 12:04:23 +00:00
|
|
|
|
|
|
|
qCDebug(KWIN_FB) << "Bits Per Pixel: " << m_bitsPerPixel;
|
|
|
|
qCDebug(KWIN_FB) << "Buffer Length: " << m_bufferLength;
|
|
|
|
qCDebug(KWIN_FB) << "Bytes Per Line: " << m_bytesPerLine;
|
|
|
|
qCDebug(KWIN_FB) << "Alpha Length: " << m_alpha.length;
|
|
|
|
qCDebug(KWIN_FB) << "Red Length: " << m_red.length;
|
|
|
|
qCDebug(KWIN_FB) << "Green Length: " << m_green.length;
|
|
|
|
qCDebug(KWIN_FB) << "Blue Length: " << m_blue.length;
|
|
|
|
qCDebug(KWIN_FB) << "Blue Offset: " << m_blue.offset;
|
|
|
|
qCDebug(KWIN_FB) << "Green Offset: " << m_green.offset;
|
|
|
|
qCDebug(KWIN_FB) << "Red Offset: " << m_red.offset;
|
|
|
|
qCDebug(KWIN_FB) << "Alpha Offset: " << m_alpha.offset;
|
|
|
|
|
|
|
|
if (m_bitsPerPixel == 32 &&
|
2015-03-31 09:00:46 +00:00
|
|
|
m_red.length == 8 &&
|
|
|
|
m_green.length == 8 &&
|
|
|
|
m_blue.length == 8 &&
|
|
|
|
m_blue.offset == 0 &&
|
|
|
|
m_green.offset == 8 &&
|
|
|
|
m_red.offset == 16) {
|
2015-12-15 12:04:23 +00:00
|
|
|
qCDebug(KWIN_FB) << "Framebuffer format is RGB32";
|
2016-07-11 08:53:04 +00:00
|
|
|
m_imageFormat = QImage::Format_RGB32;
|
2017-10-23 08:14:16 +00:00
|
|
|
} else if (m_bitsPerPixel == 32 &&
|
|
|
|
m_red.length == 8 &&
|
|
|
|
m_green.length == 8 &&
|
|
|
|
m_blue.length == 8 &&
|
|
|
|
m_alpha.length == 8 &&
|
|
|
|
m_red.offset == 0 &&
|
|
|
|
m_green.offset == 8 &&
|
|
|
|
m_blue.offset == 16 &&
|
|
|
|
m_alpha.offset == 24) {
|
|
|
|
qCDebug(KWIN_FB) << "Framebuffer format is RGBA8888";
|
|
|
|
m_imageFormat = QImage::Format_RGBA8888;
|
2015-12-15 12:04:23 +00:00
|
|
|
} else if (m_bitsPerPixel == 24 &&
|
|
|
|
m_red.length == 8 &&
|
|
|
|
m_green.length == 8 &&
|
|
|
|
m_blue.length == 8 &&
|
|
|
|
m_blue.offset == 0 &&
|
|
|
|
m_green.offset == 8 &&
|
|
|
|
m_red.offset == 16) {
|
|
|
|
qCDebug(KWIN_FB) << "Framebuffer Format is RGB888";
|
2016-07-11 08:53:04 +00:00
|
|
|
m_bgr = true;
|
|
|
|
m_imageFormat = QImage::Format_RGB888;
|
2015-12-15 12:04:23 +00:00
|
|
|
} else if (m_bitsPerPixel == 16 &&
|
|
|
|
m_red.length == 5 &&
|
|
|
|
m_green.length == 6 &&
|
|
|
|
m_blue.length == 5 &&
|
|
|
|
m_blue.offset == 0 &&
|
|
|
|
m_green.offset == 5 &&
|
|
|
|
m_red.offset == 11) {
|
|
|
|
qCDebug(KWIN_FB) << "Framebuffer Format is RGB16";
|
2016-07-11 08:53:04 +00:00
|
|
|
m_imageFormat = QImage::Format_RGB16;
|
2018-04-22 15:48:44 +00:00
|
|
|
} else {
|
|
|
|
qCWarning(KWIN_FB) << "Framebuffer format is unknown";
|
2015-03-31 09:00:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-22 12:17:46 +00:00
|
|
|
Outputs FramebufferBackend::outputs() const
|
|
|
|
{
|
|
|
|
return m_outputs;
|
|
|
|
}
|
|
|
|
|
|
|
|
Outputs FramebufferBackend::enabledOutputs() const
|
|
|
|
{
|
|
|
|
return m_outputs;
|
|
|
|
}
|
|
|
|
|
2015-03-31 09:00:46 +00:00
|
|
|
}
|