[Interest] Fwd: QtCompositor API : is it bit-rotting ?

[Rutledge Shawn]

On 14 Feb 2014, at 11:12 AM, Jean-Michaël CELERIER wrote:

> I tried to compile it, however I get numerous errors related to Wayland and Wayland functions that seem to have changed.
> 
> For instance : wl_display_add_object which looks like it has disappeared some time ago : https://gitorious.org/weston/wayland/commit/3ac8757
> 
> This is quite sad, I would really have liked to toy my own compositor !

Quite recently I had it working temporarily with only minor changes, with KMS but not eglfs.  (Yes the minor changes need to be integrated soon.)  But my biggest problem right now is that the libEGL provided by the Arch mesa package tries to connect to the X server even if I'm trying to run completely without X.  So I'm a bit confused about how that really should work, and it seems the answer will be different depending on whether you want to run the stack with a Qt compositor on KMS or eglfs, and then Qt using the wayland plugin for applications, or whether you want to run wayland on top of X11, or run X11 on top of wayland.  Qt links with libEGL, so it seems to me you can end up needing one instance of Qt which links to the X11-capable libEGL and another which links to the libEGL which does not use X, if you want X11 to be involved at one layer but not the other.  Or maybe libEGL should link with libxcb but not necessarily open a connection, but that's not how the current packaged version is working.  So I tried building mesa from source without any X11 support, but libQt5Gui.so still links with libxcb anyway, because configure found it.  Next I think I will try Gentoo on a different machine, in the hope that it's possible to emerge all packages (mesa, Qt and other dependencies) with X11/xcb support turned off, so that libxcb won't even need to be installed.  (On Arch, that's impossible AFAICT, except if you build several packages from scratch.)  Then the standalone Qt compositor should be possible.  But maybe it's not really supposed to be that complicated.  What I want to achieve is that X11 should be an optional layer on top, not required for Qt applications but only for legacy X11 applications, and therefore not loaded into memory if you don't need it.  Did anyone find a simple way to get there yet?  

If it works, then the next question is, can we change Qt so that xcb is completely optional at runtime, even if it exists and configure has found it, if you are using the wayland plugin; while at the same time the same Qt library will happily use X11 if you use that plugin.  That way you could switch between wayland and X11 desktops (or stack them up) without needing two different Qt builds.  I don't know if that's possible, just seems that it should be.

I've heard that http://www.maui-project.org/ might end up being a pure Qt/wayland desktop with a Qt compositor and no need for weston, if we make sure it works.  (At the moment it depends on Weston because it's more complete.)

Next problem is that Qt works well with OpenGL ES 2, so you might as well build everything that way instead of with desktop OpenGL drivers.  But if your hardware can do more, that becomes an unfortunate limitation.  But maybe it's OK to use desktop drivers, while the Qt compositor uses only GLES API (because it's only doing compositing, not fancy rendering), and at the same time a Qt3D program (for example) would use the GL 4.x API to render frames.  The compositor and the application are separate processes, so maybe it should be OK in theory.  As long as people think that wayland is mainly for devices which can only run GLES anyway, there isn't much emphasis on doing this.  But I don't see why it doesn't make sense on a laptop as well, and then the hardware is capable of much more than GLES, so we should be able to use it.