yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/abstract_backend.h

82 lines
2.2 KiB
C
Raw Normal View History

Introduce AbstractBackend as base class for Wayland and X11Windowed backend The AbstractBackend registers itself in the WaylandServer allowing external users to easily get to the backend and not needing to test manually which backend is used.
2015-03-20 13:41:03 +00:00
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2015 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#ifndef KWIN_ABSTRACT_BACKEND_H
#define KWIN_ABSTRACT_BACKEND_H
[wayland] Backends are no longer singletons They are installed in the WaylandServer, thus we don't need an explicit singleton accessor. If we need to differentiate we can cast.
2015-03-23 13:29:07 +00:00
#include <kwin_export.h>
[wayland] Add support for a "software" cursor At least the framebuffer backend does not have support for an overlay cursor. Thus the cursor needs to be rendered by the scene. This change allows a backend to set that it needs a software cursor which triggers tracking in the AbstractBackend. A repaint for the old cursor region is triggered whenever the cursor pos changes. So far only the QPainter/framebuffer scene is adjusted to render the software cursor. This is done after rendering a frame with the up to date cursor position. There is one problem, though: the KWin internal cursors don't work as we need to get it from the theme. Using wayland-cursor doesn't help as it gives us a (client) wl_buffer* and we cannot read the memory back.
2015-04-01 13:36:40 +00:00
#include <QImage>
Introduce AbstractBackend as base class for Wayland and X11Windowed backend The AbstractBackend registers itself in the WaylandServer allowing external users to easily get to the backend and not needing to test manually which backend is used.
2015-03-20 13:41:03 +00:00
#include <QObject>
namespace KWin
{
[wayland] Create OpenGLBackend through the AbstractBackend Replaces casting logic in the SceneOpenGL. Now the create is delegated to the backend allowing also to move the ifdef logic to where it belongs.
2015-03-27 07:51:56 +00:00
class OpenGLBackend;
[wayland] Create QPainterBackend through the AbstractBackend SceneQPainter delegates creation to the AbstractBackend removing the casting logic.
2015-03-27 08:05:03 +00:00
class QPainterBackend;
[wayland] Create Screens through the AbstractBackend The AbstractBackend provides a virtual method to create the Screens. A concrete backend can implement this method to create the backend specific Screens instance. This removes the casting logic from Screens::create.
2015-03-27 06:52:59 +00:00
class Screens;
[wayland] Set internal cursor through WaylandCursorTheme in AbstractBackend Getting the cursor image from the cursor theme is unfortunately not straight forward. We have three different libraries and all have drawbacks: * XCursor - we just kicked it out * xcb-util/cursor - only provides xcb_cursor_t, so a dependency on X * wayland-cursor - only a client side API The picked solution is using wayland-cursor. It provides the cursor in a wl_buffer. Unfortunately the client side API does not easily allow to a) read it back b) init without a wl_shm_pool Thus we need to work this around: * create an internal connection * get a ShmPool on it * init WaylandCursorTheme with this ShmPool * get the cursor wl_buffer from the theme * trigger a roundtrip * get the corresponding BufferInterface for the buffer * set the content as the software cursor
2015-04-02 12:37:23 +00:00
namespace Wayland
{
class WaylandCursorTheme;
}
[wayland] Backends are no longer singletons They are installed in the WaylandServer, thus we don't need an explicit singleton accessor. If we need to differentiate we can cast.
2015-03-23 13:29:07 +00:00
class KWIN_EXPORT AbstractBackend : public QObject
Introduce AbstractBackend as base class for Wayland and X11Windowed backend The AbstractBackend registers itself in the WaylandServer allowing external users to easily get to the backend and not needing to test manually which backend is used.
2015-03-20 13:41:03 +00:00
{
Q_OBJECT
public:
virtual ~AbstractBackend();
virtual void installCursorFromServer();
virtual void installCursorImage(Qt::CursorShape shape);
[wayland] Create Screens through the AbstractBackend The AbstractBackend provides a virtual method to create the Screens. A concrete backend can implement this method to create the backend specific Screens instance. This removes the casting logic from Screens::create.
2015-03-27 06:52:59 +00:00
virtual Screens *createScreens(QObject *parent = nullptr);
[wayland] Create OpenGLBackend through the AbstractBackend Replaces casting logic in the SceneOpenGL. Now the create is delegated to the backend allowing also to move the ifdef logic to where it belongs.
2015-03-27 07:51:56 +00:00
virtual OpenGLBackend *createOpenGLBackend();
[wayland] Create QPainterBackend through the AbstractBackend SceneQPainter delegates creation to the AbstractBackend removing the casting logic.
2015-03-27 08:05:03 +00:00
virtual QPainterBackend *createQPainterBackend();
Introduce AbstractBackend as base class for Wayland and X11Windowed backend The AbstractBackend registers itself in the WaylandServer allowing external users to easily get to the backend and not needing to test manually which backend is used.
2015-03-20 13:41:03 +00:00
[wayland] Add support for a "software" cursor At least the framebuffer backend does not have support for an overlay cursor. Thus the cursor needs to be rendered by the scene. This change allows a backend to set that it needs a software cursor which triggers tracking in the AbstractBackend. A repaint for the old cursor region is triggered whenever the cursor pos changes. So far only the QPainter/framebuffer scene is adjusted to render the software cursor. This is done after rendering a frame with the up to date cursor position. There is one problem, though: the KWin internal cursors don't work as we need to get it from the theme. Using wayland-cursor doesn't help as it gives us a (client) wl_buffer* and we cannot read the memory back.
2015-04-01 13:36:40 +00:00
bool usesSoftwareCursor() const {
return m_softWareCursor;
}
QImage softwareCursor() const {
return m_cursor.image;
}
QPoint softwareCursorHotspot() const {
return m_cursor.hotspot;
}
void markCursorAsRendered();
Introduce AbstractBackend as base class for Wayland and X11Windowed backend The AbstractBackend registers itself in the WaylandServer allowing external users to easily get to the backend and not needing to test manually which backend is used.
2015-03-20 13:41:03 +00:00
protected:
explicit AbstractBackend(QObject *parent = nullptr);
[wayland] Add support for a "software" cursor At least the framebuffer backend does not have support for an overlay cursor. Thus the cursor needs to be rendered by the scene. This change allows a backend to set that it needs a software cursor which triggers tracking in the AbstractBackend. A repaint for the old cursor region is triggered whenever the cursor pos changes. So far only the QPainter/framebuffer scene is adjusted to render the software cursor. This is done after rendering a frame with the up to date cursor position. There is one problem, though: the KWin internal cursors don't work as we need to get it from the theme. Using wayland-cursor doesn't help as it gives us a (client) wl_buffer* and we cannot read the memory back.
2015-04-01 13:36:40 +00:00
void setSoftWareCursor(bool set);
[wayland] Set internal cursor through WaylandCursorTheme in AbstractBackend Getting the cursor image from the cursor theme is unfortunately not straight forward. We have three different libraries and all have drawbacks: * XCursor - we just kicked it out * xcb-util/cursor - only provides xcb_cursor_t, so a dependency on X * wayland-cursor - only a client side API The picked solution is using wayland-cursor. It provides the cursor in a wl_buffer. Unfortunately the client side API does not easily allow to a) read it back b) init without a wl_shm_pool Thus we need to work this around: * create an internal connection * get a ShmPool on it * init WaylandCursorTheme with this ShmPool * get the cursor wl_buffer from the theme * trigger a roundtrip * get the corresponding BufferInterface for the buffer * set the content as the software cursor
2015-04-02 12:37:23 +00:00
private Q_SLOTS:
void installThemeCursor(quint32 id, const QPoint &hotspot);
[wayland] Add support for a "software" cursor At least the framebuffer backend does not have support for an overlay cursor. Thus the cursor needs to be rendered by the scene. This change allows a backend to set that it needs a software cursor which triggers tracking in the AbstractBackend. A repaint for the old cursor region is triggered whenever the cursor pos changes. So far only the QPainter/framebuffer scene is adjusted to render the software cursor. This is done after rendering a frame with the up to date cursor position. There is one problem, though: the KWin internal cursors don't work as we need to get it from the theme. Using wayland-cursor doesn't help as it gives us a (client) wl_buffer* and we cannot read the memory back.
2015-04-01 13:36:40 +00:00
private:
void triggerCursorRepaint();
bool m_softWareCursor = false;
struct {
QPoint hotspot;
QImage image;
QPoint lastRenderedPosition;
} m_cursor;
[wayland] Set internal cursor through WaylandCursorTheme in AbstractBackend Getting the cursor image from the cursor theme is unfortunately not straight forward. We have three different libraries and all have drawbacks: * XCursor - we just kicked it out * xcb-util/cursor - only provides xcb_cursor_t, so a dependency on X * wayland-cursor - only a client side API The picked solution is using wayland-cursor. It provides the cursor in a wl_buffer. Unfortunately the client side API does not easily allow to a) read it back b) init without a wl_shm_pool Thus we need to work this around: * create an internal connection * get a ShmPool on it * init WaylandCursorTheme with this ShmPool * get the cursor wl_buffer from the theme * trigger a roundtrip * get the corresponding BufferInterface for the buffer * set the content as the software cursor
2015-04-02 12:37:23 +00:00
Wayland::WaylandCursorTheme *m_cursorTheme = nullptr;
Introduce AbstractBackend as base class for Wayland and X11Windowed backend The AbstractBackend registers itself in the WaylandServer allowing external users to easily get to the backend and not needing to test manually which backend is used.
2015-03-20 13:41:03 +00:00
};
}
#endif
Reference in a new issue Copy permalink