2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2019-06-13 09:27:01 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2019 Roman Gilg <subdiff@gmail.com>
|
2019-06-13 09:27:01 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2019-06-13 09:27:01 +00:00
|
|
|
#include "x11windowed_output.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"
|
|
|
|
#include "softwarevsyncmonitor.h"
|
2019-06-13 09:27:01 +00:00
|
|
|
#include "x11windowed_backend.h"
|
|
|
|
|
|
|
|
#include <NETWM>
|
|
|
|
|
|
|
|
#if HAVE_X11_XINPUT
|
|
|
|
#include <X11/extensions/XInput2.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <QIcon>
|
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
|
|
|
X11WindowedOutput::X11WindowedOutput(X11WindowedBackend *backend)
|
2019-06-13 09:36:07 +00:00
|
|
|
: AbstractWaylandOutput(backend)
|
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
|
|
|
, m_renderLoop(new RenderLoop(this))
|
|
|
|
, m_vsyncMonitor(SoftwareVsyncMonitor::create(this))
|
2019-06-13 09:27:01 +00:00
|
|
|
, m_backend(backend)
|
|
|
|
{
|
|
|
|
m_window = xcb_generate_id(m_backend->connection());
|
2020-04-08 09:38:41 +00:00
|
|
|
|
|
|
|
static int identifier = -1;
|
|
|
|
identifier++;
|
|
|
|
setName("X11-" + QString::number(identifier));
|
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
|
|
|
|
|
|
|
connect(m_vsyncMonitor, &VsyncMonitor::vblankOccurred, this, &X11WindowedOutput::vblank);
|
2019-06-13 09:27:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
X11WindowedOutput::~X11WindowedOutput()
|
|
|
|
{
|
|
|
|
xcb_unmap_window(m_backend->connection(), m_window);
|
|
|
|
xcb_destroy_window(m_backend->connection(), m_window);
|
|
|
|
delete m_winInfo;
|
|
|
|
xcb_flush(m_backend->connection());
|
|
|
|
}
|
|
|
|
|
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 *X11WindowedOutput::renderLoop() const
|
|
|
|
{
|
|
|
|
return m_renderLoop;
|
|
|
|
}
|
|
|
|
|
|
|
|
SoftwareVsyncMonitor *X11WindowedOutput::vsyncMonitor() const
|
|
|
|
{
|
|
|
|
return m_vsyncMonitor;
|
|
|
|
}
|
|
|
|
|
2019-08-27 10:31:42 +00:00
|
|
|
void X11WindowedOutput::init(const QPoint &logicalPosition, const QSize &pixelSize)
|
2019-06-13 09:27:01 +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 refresh rate via randr
|
|
|
|
m_renderLoop->setRefreshRate(refreshRate);
|
|
|
|
m_vsyncMonitor->setRefreshRate(refreshRate);
|
|
|
|
|
2020-04-29 15:18:41 +00:00
|
|
|
KWaylandServer::OutputDeviceInterface::Mode mode;
|
2019-08-27 10:31:42 +00:00
|
|
|
mode.id = 0;
|
|
|
|
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;
|
2019-08-27 14:52:39 +00:00
|
|
|
|
|
|
|
// Physicial size must be adjusted, such that QPA calculates correct sizes of
|
|
|
|
// internal elements.
|
2019-08-28 20:27:22 +00:00
|
|
|
const QSize physicalSize = pixelSize / 96.0 * 25.4 / m_backend->initialOutputScale();
|
2020-10-26 17:29:33 +00:00
|
|
|
initInterfaces("model_TODO", "manufacturer_TODO", "UUID_TODO", physicalSize, { mode }, {});
|
2019-08-27 10:31:42 +00:00
|
|
|
setGeometry(logicalPosition, pixelSize);
|
|
|
|
setScale(m_backend->initialOutputScale());
|
|
|
|
|
2019-06-13 09:27:01 +00:00
|
|
|
uint32_t mask = XCB_CW_BACK_PIXEL | XCB_CW_EVENT_MASK;
|
|
|
|
const uint32_t values[] = {
|
|
|
|
m_backend->screen()->black_pixel,
|
|
|
|
XCB_EVENT_MASK_KEY_PRESS |
|
|
|
|
XCB_EVENT_MASK_KEY_RELEASE |
|
|
|
|
XCB_EVENT_MASK_BUTTON_PRESS |
|
|
|
|
XCB_EVENT_MASK_BUTTON_RELEASE |
|
|
|
|
XCB_EVENT_MASK_POINTER_MOTION |
|
|
|
|
XCB_EVENT_MASK_ENTER_WINDOW |
|
|
|
|
XCB_EVENT_MASK_LEAVE_WINDOW |
|
|
|
|
XCB_EVENT_MASK_STRUCTURE_NOTIFY |
|
|
|
|
XCB_EVENT_MASK_EXPOSURE
|
|
|
|
};
|
|
|
|
xcb_create_window(m_backend->connection(),
|
|
|
|
XCB_COPY_FROM_PARENT,
|
|
|
|
m_window,
|
|
|
|
m_backend->screen()->root,
|
|
|
|
0, 0,
|
2019-08-27 10:31:42 +00:00
|
|
|
pixelSize.width(), pixelSize.height(),
|
2019-06-13 09:27:01 +00:00
|
|
|
0, XCB_WINDOW_CLASS_INPUT_OUTPUT, XCB_COPY_FROM_PARENT,
|
|
|
|
mask, values);
|
|
|
|
|
|
|
|
// select xinput 2 events
|
|
|
|
initXInputForWindow();
|
|
|
|
|
|
|
|
m_winInfo = new NETWinInfo(m_backend->connection(),
|
|
|
|
m_window,
|
|
|
|
m_backend->screen()->root,
|
|
|
|
NET::WMWindowType, NET::Properties2());
|
|
|
|
|
|
|
|
m_winInfo->setWindowType(NET::Normal);
|
|
|
|
m_winInfo->setPid(QCoreApplication::applicationPid());
|
|
|
|
QIcon windowIcon = QIcon::fromTheme(QStringLiteral("kwin"));
|
|
|
|
auto addIcon = [&windowIcon, this] (const QSize &size) {
|
|
|
|
if (windowIcon.actualSize(size) != size) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
NETIcon icon;
|
2020-05-01 15:13:40 +00:00
|
|
|
QImage windowImage = windowIcon.pixmap(size).toImage();
|
|
|
|
icon.data = windowImage.bits();
|
2019-06-13 09:27:01 +00:00
|
|
|
icon.size.width = size.width();
|
|
|
|
icon.size.height = size.height();
|
|
|
|
m_winInfo->setIcon(icon, false);
|
|
|
|
};
|
|
|
|
addIcon(QSize(16, 16));
|
|
|
|
addIcon(QSize(32, 32));
|
|
|
|
addIcon(QSize(48, 48));
|
|
|
|
|
|
|
|
xcb_map_window(m_backend->connection(), m_window);
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11WindowedOutput::initXInputForWindow()
|
|
|
|
{
|
|
|
|
if (!m_backend->hasXInput()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
#if HAVE_X11_XINPUT
|
|
|
|
XIEventMask evmasks[1];
|
|
|
|
unsigned char mask1[XIMaskLen(XI_LASTEVENT)];
|
|
|
|
|
|
|
|
memset(mask1, 0, sizeof(mask1));
|
|
|
|
XISetMask(mask1, XI_TouchBegin);
|
|
|
|
XISetMask(mask1, XI_TouchUpdate);
|
|
|
|
XISetMask(mask1, XI_TouchOwnership);
|
|
|
|
XISetMask(mask1, XI_TouchEnd);
|
|
|
|
evmasks[0].deviceid = XIAllMasterDevices;
|
|
|
|
evmasks[0].mask_len = sizeof(mask1);
|
|
|
|
evmasks[0].mask = mask1;
|
|
|
|
XISelectEvents(m_backend->display(), m_window, evmasks, 1);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11WindowedOutput::setGeometry(const QPoint &logicalPosition, const QSize &pixelSize)
|
|
|
|
{
|
2019-08-27 14:19:47 +00:00
|
|
|
// TODO: set mode to have updated pixelSize
|
2019-08-28 16:10:24 +00:00
|
|
|
Q_UNUSED(pixelSize);
|
2019-06-13 09:27:01 +00:00
|
|
|
setGlobalPos(logicalPosition);
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11WindowedOutput::setWindowTitle(const QString &title)
|
|
|
|
{
|
|
|
|
m_winInfo->setName(title.toUtf8().constData());
|
|
|
|
}
|
|
|
|
|
|
|
|
QPoint X11WindowedOutput::internalPosition() const
|
|
|
|
{
|
|
|
|
return geometry().topLeft();
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11WindowedOutput::setHostPosition(const QPoint &pos)
|
|
|
|
{
|
|
|
|
m_hostPosition = pos;
|
|
|
|
}
|
|
|
|
|
2019-09-14 18:19:20 +00:00
|
|
|
QPointF X11WindowedOutput::mapFromGlobal(const QPointF &pos) const
|
|
|
|
{
|
|
|
|
return (pos - hostPosition() + internalPosition()) / scale();
|
|
|
|
}
|
|
|
|
|
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 X11WindowedOutput::vblank(std::chrono::nanoseconds timestamp)
|
|
|
|
{
|
|
|
|
RenderLoopPrivate *renderLoopPrivate = RenderLoopPrivate::get(m_renderLoop);
|
|
|
|
renderLoopPrivate->notifyFrameCompleted(timestamp);
|
|
|
|
}
|
|
|
|
|
2019-06-13 09:27:01 +00:00
|
|
|
}
|