kwin/src/core/renderbackend.cpp

/*
    SPDX-FileCopyrightText: 2021 Vlad Zahorodnii <vlad.zahorodnii@kde.org>

    SPDX-License-Identifier: GPL-2.0-or-later
*/

#include "renderbackend.h"

#include <drm_fourcc.h>

namespace KWin
{

RenderBackend::RenderBackend(QObject *parent)
    : QObject(parent)
{
}

OverlayWindow *RenderBackend::overlayWindow() const
{
    return nullptr;
}

bool RenderBackend::checkGraphicsReset()
{
    return false;
}

QHash<uint32_t, QVector<uint64_t>> RenderBackend::supportedFormats() const
{
    return QHash<uint32_t, QVector<uint64_t>>{{DRM_FORMAT_XRGB8888, QVector<uint64_t>{DRM_FORMAT_MOD_LINEAR}}};
}

} // namespace KWin
Introduce explicit base render backend type The main idea behind the render backend is to decouple low level bits from scenes. The end goal is to make the render backend provide render targets where the scene can render. Design-wise, such a split is more flexible than the current state, for example we could start experimenting with using qtquick (assuming that the legacy scene is properly encapsulated) or creating multiple scenes, for example for each output layer, etc. So far, the RenderBackend class only contains one getter, more stuff will be moved from the Scene as it makes sense. 2021-11-10 10:34:18 +00:00			`/*`
			`SPDX-FileCopyrightText: 2021 Vlad Zahorodnii <vlad.zahorodnii@kde.org>`

			`SPDX-License-Identifier: GPL-2.0-or-later`
			`*/`

			`#include "renderbackend.h"`

plugins/screencast: centralize format querying into the RenderBackend BUG: 460563 2022-10-20 12:20:48 +00:00			`#include <drm_fourcc.h>`

Introduce explicit base render backend type The main idea behind the render backend is to decouple low level bits from scenes. The end goal is to make the render backend provide render targets where the scene can render. Design-wise, such a split is more flexible than the current state, for example we could start experimenting with using qtquick (assuming that the legacy scene is properly encapsulated) or creating multiple scenes, for example for each output layer, etc. So far, the RenderBackend class only contains one getter, more stuff will be moved from the Scene as it makes sense. 2021-11-10 10:34:18 +00:00			`namespace KWin`
			`{`

			`RenderBackend::RenderBackend(QObject *parent)`
			`: QObject(parent)`
			`{`
			`}`

Move OverlayWindow getter to RenderBackend 2021-11-11 09:48:43 +00:00			`OverlayWindow *RenderBackend::overlayWindow() const`
			`{`
			`return nullptr;`
			`}`

Move graphics reset handling to RenderBackend This makes the Scene less overloaded and it's needed for things such as render layers. In hindsight, it would be great to merge checkGraphicsReset() and beginFrame(), e.g. make beginFrame() return the status like in QRhi or VkSwapchain. If it's OUT_OF_DATE or something, reinitialize the compositor. 2021-12-31 11:51:42 +00:00			`bool RenderBackend::checkGraphicsReset()`
			`{`
			`return false;`
			`}`

plugins/screencast: centralize format querying into the RenderBackend BUG: 460563 2022-10-20 12:20:48 +00:00			`QHash<uint32_t, QVector<uint64_t>> RenderBackend::supportedFormats() const`
			`{`
			`return QHash<uint32_t, QVector<uint64_t>>{{DRM_FORMAT_XRGB8888, QVector<uint64_t>{DRM_FORMAT_MOD_LINEAR}}};`
			`}`

Introduce explicit base render backend type The main idea behind the render backend is to decouple low level bits from scenes. The end goal is to make the render backend provide render targets where the scene can render. Design-wise, such a split is more flexible than the current state, for example we could start experimenting with using qtquick (assuming that the legacy scene is properly encapsulated) or creating multiple scenes, for example for each output layer, etc. So far, the RenderBackend class only contains one getter, more stuff will be moved from the Scene as it makes sense. 2021-11-10 10:34:18 +00:00			`} // namespace KWin`