2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2019 Roman Gilg <subdiff@gmail.com>
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
#include "wayland_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.h"
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
#include "wayland_backend.h"
|
|
|
|
#include "wayland_server.h"
|
|
|
|
|
|
|
|
#include <KWayland/Client/pointerconstraints.h>
|
|
|
|
#include <KWayland/Client/surface.h>
|
|
|
|
|
2020-04-29 15:18:41 +00:00
|
|
|
#include <KWaylandServer/display.h>
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
|
|
|
|
#include <KLocalizedString>
|
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
namespace Wayland
|
|
|
|
{
|
|
|
|
|
|
|
|
using namespace KWayland::Client;
|
|
|
|
|
2019-08-27 10:14:10 +00:00
|
|
|
WaylandOutput::WaylandOutput(Surface *surface, WaylandBackend *backend)
|
|
|
|
: 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))
|
2019-08-27 10:14:10 +00:00
|
|
|
, m_surface(surface)
|
|
|
|
, m_backend(backend)
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
{
|
2020-04-08 09:38:41 +00:00
|
|
|
static int identifier = -1;
|
|
|
|
identifier++;
|
|
|
|
setName("WL-" + QString::number(identifier));
|
|
|
|
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
connect(surface, &Surface::frameRendered, [this] {
|
|
|
|
m_rendered = true;
|
|
|
|
emit frameRendered();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
WaylandOutput::~WaylandOutput()
|
|
|
|
{
|
|
|
|
m_surface->destroy();
|
|
|
|
delete m_surface;
|
|
|
|
}
|
|
|
|
|
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 *WaylandOutput::renderLoop() const
|
|
|
|
{
|
|
|
|
return m_renderLoop;
|
|
|
|
}
|
|
|
|
|
2019-08-27 10:14:10 +00:00
|
|
|
void WaylandOutput::init(const QPoint &logicalPosition, const QSize &pixelSize)
|
|
|
|
{
|
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: can we get refresh rate data from Wayland host?
|
|
|
|
m_renderLoop->setRefreshRate(refreshRate);
|
|
|
|
|
2020-04-29 15:18:41 +00:00
|
|
|
KWaylandServer::OutputDeviceInterface::Mode mode;
|
2019-08-27 10:14:10 +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;
|
2020-10-26 17:29:33 +00:00
|
|
|
initInterfaces("model_TODO", "manufacturer_TODO", "UUID_TODO", pixelSize, { mode }, {});
|
2019-08-27 10:14:10 +00:00
|
|
|
setGeometry(logicalPosition, pixelSize);
|
|
|
|
setScale(backend()->initialOutputScale());
|
|
|
|
}
|
|
|
|
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
void WaylandOutput::setGeometry(const QPoint &logicalPosition, const QSize &pixelSize)
|
|
|
|
{
|
2019-08-27 14:19:47 +00:00
|
|
|
// TODO: set mode to have updated pixelSize
|
2019-08-27 14:52:39 +00:00
|
|
|
Q_UNUSED(pixelSize)
|
|
|
|
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
setGlobalPos(logicalPosition);
|
|
|
|
}
|
|
|
|
|
|
|
|
XdgShellOutput::XdgShellOutput(Surface *surface, XdgShell *xdgShell, WaylandBackend *backend, int number)
|
|
|
|
: WaylandOutput(surface, backend)
|
|
|
|
, m_number(number)
|
|
|
|
{
|
|
|
|
m_xdgShellSurface = xdgShell->createSurface(surface, this);
|
|
|
|
updateWindowTitle();
|
|
|
|
|
|
|
|
connect(m_xdgShellSurface, &XdgShellSurface::configureRequested, this, &XdgShellOutput::handleConfigure);
|
|
|
|
connect(m_xdgShellSurface, &XdgShellSurface::closeRequested, qApp, &QCoreApplication::quit);
|
|
|
|
|
|
|
|
connect(backend, &WaylandBackend::pointerLockSupportedChanged, this, &XdgShellOutput::updateWindowTitle);
|
|
|
|
connect(backend, &WaylandBackend::pointerLockChanged, this, [this](bool locked) {
|
|
|
|
if (locked) {
|
|
|
|
if (!m_hasPointerLock) {
|
|
|
|
// some other output has locked the pointer
|
|
|
|
// this surface can stop trying to lock the pointer
|
|
|
|
lockPointer(nullptr, false);
|
|
|
|
// set it true for the other surface
|
|
|
|
m_hasPointerLock = true;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// just try unlocking
|
|
|
|
lockPointer(nullptr, false);
|
|
|
|
}
|
|
|
|
updateWindowTitle();
|
|
|
|
});
|
2019-11-03 15:53:45 +00:00
|
|
|
|
|
|
|
surface->commit(Surface::CommitFlag::None);
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
XdgShellOutput::~XdgShellOutput()
|
|
|
|
{
|
|
|
|
m_xdgShellSurface->destroy();
|
|
|
|
delete m_xdgShellSurface;
|
|
|
|
}
|
|
|
|
|
|
|
|
void XdgShellOutput::handleConfigure(const QSize &size, XdgShellSurface::States states, quint32 serial)
|
|
|
|
{
|
|
|
|
Q_UNUSED(states);
|
2019-11-03 16:02:47 +00:00
|
|
|
if (size.width() > 0 && size.height() > 0) {
|
|
|
|
setGeometry(geometry().topLeft(), size);
|
|
|
|
emit sizeChanged(size);
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
}
|
|
|
|
m_xdgShellSurface->ackConfigure(serial);
|
|
|
|
}
|
|
|
|
|
|
|
|
void XdgShellOutput::updateWindowTitle()
|
|
|
|
{
|
|
|
|
QString grab;
|
|
|
|
if (m_hasPointerLock) {
|
|
|
|
grab = i18n("Press right control to ungrab pointer");
|
2019-08-27 10:14:10 +00:00
|
|
|
} else if (backend()->pointerConstraints()) {
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
grab = i18n("Press right control key to grab pointer");
|
|
|
|
}
|
|
|
|
const QString title = i18nc("Title of nested KWin Wayland with Wayland socket identifier as argument",
|
2020-11-17 13:26:01 +00:00
|
|
|
"KDE Wayland Compositor #%1 (%2)", m_number, waylandServer()->socketName());
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
|
|
|
|
if (grab.isEmpty()) {
|
|
|
|
m_xdgShellSurface->setTitle(title);
|
|
|
|
} else {
|
|
|
|
m_xdgShellSurface->setTitle(title + QStringLiteral(" — ") + grab);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void XdgShellOutput::lockPointer(Pointer *pointer, bool lock)
|
|
|
|
{
|
|
|
|
if (!lock) {
|
|
|
|
const bool surfaceWasLocked = m_pointerLock && m_hasPointerLock;
|
|
|
|
delete m_pointerLock;
|
|
|
|
m_pointerLock = nullptr;
|
|
|
|
m_hasPointerLock = false;
|
|
|
|
if (surfaceWasLocked) {
|
2019-08-27 10:14:10 +00:00
|
|
|
emit backend()->pointerLockChanged(false);
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Q_ASSERT(!m_pointerLock);
|
2019-08-27 10:14:10 +00:00
|
|
|
m_pointerLock = backend()->pointerConstraints()->lockPointer(surface(), pointer, nullptr,
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
PointerConstraints::LifeTime::OneShot,
|
|
|
|
this);
|
|
|
|
if (!m_pointerLock->isValid()) {
|
|
|
|
delete m_pointerLock;
|
|
|
|
m_pointerLock = nullptr;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
connect(m_pointerLock, &LockedPointer::locked, this,
|
|
|
|
[this] {
|
|
|
|
m_hasPointerLock = true;
|
2019-08-27 10:14:10 +00:00
|
|
|
emit backend()->pointerLockChanged(true);
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
}
|
|
|
|
);
|
|
|
|
connect(m_pointerLock, &LockedPointer::unlocked, this,
|
|
|
|
[this] {
|
|
|
|
delete m_pointerLock;
|
|
|
|
m_pointerLock = nullptr;
|
|
|
|
m_hasPointerLock = false;
|
2019-08-27 10:14:10 +00:00
|
|
|
emit backend()->pointerLockChanged(false);
|
[platforms/wayland] Multi output support
Summary:
This patch rewrites large parts of the Wayland platform plugin, in order to
facilitate the testing of multi output behavior in nested KWin sessions.
For that a new class WaylandOutput is introduced, which is based on
AbstractOutput and by that shares functionality with our virtual and DRM
platform plugins.
The EGL/GBM and QPainter backends have been remodelled after the DRM one,
sharing similiarities there as well now.
Pointer grabbing has been rewritten to support multiple outputs, now using
pointer locking instead of confining and drawing in this case onto a sub-
surface, which get dynamically recreated in between the different output
surfaces while the cursor is being moved.
Window resizing is possible if host supports xdg-shell, but currently the
mode size does not yet fill the new window size.
The number of outputs can be set by command line argument `--output-count`,
scaling is also supported by setting the argument `--scale`.
Further steps could be:
* Enabling automatic fill of resized windows via Wayland mode change
* Multiple diverging initial sizes and scale factors for mulitple outputs
**Watch it in action:** https://youtu.be/FYItn1jvkbI
Test Plan: Tested it in live session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18465
2019-02-22 09:57:07 +00:00
|
|
|
}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|