Open zccrs opened 3 years ago
You'll need to create a new wlr_backend
implementation which uses Qt.
You'll need to create a new
wlr_backend
implementation which uses Qt.
I don't want to use Qt as the backend of wlroots, but I want to use wlroots as the platform plugin of Qt .
Ah. Can you explain your use-case in detail? I'm not sure I fully understand it.
Is it this way: you have a wlr_backend
, and you want to use Qt to draw buffers for it?
The content rendered to QWindow will be saved in wlr_buffer, and I then the wlr_buffer will be composition into wlr_output, so that QWindow does not depend on the native window (eg: xwindow or wayland surface)
Like this: https://github.com/KDE/kwin/blob/master/src/plugins/qpa/window.cpp kwin use the egl pbuffer for the QWindow, I want to use the wlr_buffer replace this pbuffer.
QWindow is a drawable surface, and its backend may be an EGLSurface or GLXDrawable (depending on the implementation of the underlying plug-in), we can use opengl/gles to draw anything in QWindow, such as wlr_surface's wlr_texture using opengl to draw To QWindow, if the backend of QWindow is an X11 window, this will cause wlr_surface to be synthesized into an X11 window, just like the x11 backend of wlroots. In my compositor, I use wlr_output as the backend of QWindow, Use the Qt interface to draw the wlr_texture of wlr_surface into this QWindow, so that the windows created by wayland clients can be synthesized to the screen, and my compositor itself needs to use QWindow (these QWindow are ordinary windows, and wlr_output cannot be used. For example, create a dialog box in the synthesizer program to display some information), but the wayland client interface can no longer be used to create the wayland window in the synthesizer process. If the backend of these QWindow can use wlr_buffer, then I can use these wlr_buffer Synthesize with wlr_suface to wlr_output.
Can't you use QOpenGLFramebufferObject
here?
Can't you use
QOpenGLFramebufferObject
here?
Yes. But I think to unify the implement, must can completely use wlroots to build a completed Qt platform plugin, so that when wlroots supports vulkan, I won't add much work to enjoy this result.
Plase look the follow:
Plase look the follow
Ah, so you want to get wlr_buffer
s from wlroots, then wrap them into a QQuickItem
and use Qt APIs to draw them, then display the result using a wlr_output
?
But I think to unify the implement, must can completely use wlroots to build a completed Qt platform plugin, so that when wlroots supports vulkan, I won't add much work to enjoy this result.
Hm, how would this work? When wlroots will gain a Vulkan renderer, Qt would still be in charge of performing the drawing, right? So I'm not sure I see a scenario in which the wlroots renderers are useful for your use-case.
This discussion in the KWinFT bug tracker may be interesting to you: https://gitlab.com/kwinft/kwinft/-/issues/137
It's not strictly about Qt, but it's about integrating wlroots into an existing rendering pipeline.
I'm trying to make a Wayland compositor useing Qt and wlroots. The QWindow/QSurface must need a native surface, I want use a wl_buffer with QPlatformWindow, and wl_buffer be qualified for this work. But I can only use wlr_gbm_allocator to create wl_buffer through backend/drm/renderer.h, or use wlr_wl_backend in the wayland backend, I think this is not a good idea.
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2750