yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/plugins/platforms/virtual/CMakeLists.txt

23 lines
842 B
Text
Raw Normal View History

[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
set(VIRTUAL_SOURCES
[backends/virtual] Add a virtual rendering OpenGLBackend The backend is based on drm's gbm backend and also uses the GBM platform, but with the default display allowing the driver to pick a device. In addition it doesn't use a surface, but a surfaceless context with a framebuffer object to render to. Given that it diverged too much from drm's backend to allow more code sharing. If KWin is started from a tty it gets a proper driver, if KWin is started in a X11 session it only gets llvmpipe. Given that there is a chance that the autotests using the virtual backend will fail. In that case a follow up patch will enforce either O2 or Q.
2015-10-08 14:12:09 +00:00
egl_gbm_backend.cpp
[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
scene_qpainter_virtual_backend.cpp
Cleanup style in CMakeLists.txt files We have lots of inconsistency at the moment in CMakeLists.txt files. Most of it is due to kwin being a very old project. This change hopefully fixes all of it.
2019-09-17 09:15:35 +00:00
virtual_backend.cpp
virtual_output.cpp
[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
)
Move SceneOpenGL into a dedicated plugin Summary: Unfortunately a rather large change which required more refactoring than initially expected. The main problem was that some parts needed to go into platformsupport so that the platform plugins can link them. Due to the rather monolithic nature of scene_opengl.h a few changes were required: * SceneOpenGL::Texture -> SceneOpenGLTexture * SceneOpenGL::TexturePrivate -> SceneOpenGLTexturePrivate * texture based code into dedicated files * SwapProfiler code into dedicated files * SwapProfiler only used in x11 variants * Safety checks for OpenGL scene moved into the new plugin * signal declared in SceneOpenGL moved to Scene, so that we don't need to include SceneOpenGL in composite Test Plan: Nested OpenGL compositor works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7740
2017-09-08 20:30:18 +00:00
include_directories(${CMAKE_SOURCE_DIR}/platformsupport/scenes/opengl)
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
[platforms/virtual] Use rendernode or vgem device if available for egl Summary: The egl implementation for the virtual platform tries to use a render node if available. If there is no render node it looks for a virtual (kernel driver vgem) device, which unfortunately does not create a render node in mainline kernel (there are patches in ChromiumOS). For this the Udev wrapper is extended to search for renderNode devices and for virtual dri devices. If either render node or vgem dri device is found, it is tried to be opened (without logind escalation) and on success a gbm device is created on it. If any step of this fails the so far default behavior of default device is tried for creating the EGLDisplay. All of this is compile optional, so that the virtual platform does not hard depend on udev and/or gbm. Test Plan: Auto tests which need OpenGL executed and verified that they use the render node or vgem device. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2216
2016-07-19 08:51:09 +00:00
include(ECMQtDeclareLoggingCategory)
ecm_qt_declare_logging_category(VIRTUAL_SOURCES HEADER logging.h IDENTIFIER KWIN_VIRTUAL CATEGORY_NAME kwin_platform_virtual DEFAULT_SEVERITY Critical)
[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
add_library(KWinWaylandVirtualBackend MODULE ${VIRTUAL_SOURCES})
Build platform plugins in correct sub directory of build dir Summary: This brings KWin a step closer to be run from build dir without having to install at all. The integration tests are adjusted so that the virtual platform is still found which makes the code be closer to what is used in normal kwin_wayland. Test Plan: ctest passes, manually verified correct plugin is loaded Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17388
2018-12-06 17:38:36 +00:00
set_target_properties(KWinWaylandVirtualBackend PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin/org.kde.kwin.waylandbackends/")
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
target_link_libraries(KWinWaylandVirtualBackend kwin SceneQPainterBackend SceneOpenGLBackend VsyncSupport)
[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
install(
TARGETS
KWinWaylandVirtualBackend
DESTINATION
${PLUGIN_INSTALL_DIR}/org.kde.kwin.waylandbackends/
)
Reference in a new issue Copy permalink