Wayland compatibility layer

Lyude Paul lyude at redhat.com
Thu Oct 20 21:10:02 UTC 2022

Hi, I saw this and had a couple questions. When you say "wayland compatibility
layer" I assumed at first this was for some reason a duplicate of nested
compositors but I think I may have misunderstood. Is this basically the
opposite of Xwayland, e.g. allowing X to act as a wayland compositor with
twelveto11 as the translation layer?

On Thu, 2022-10-20 at 13:08 +0800, Po Lu wrote:
> Over the past several months, I and some other individuals wrote a
> Wayland compositor that runs on common X setups.  The code can be found
> here:
>   https://sourceforge.net/projects/twelveto11/

Also JFYI - seeing as this is a freedesktop/x.org adjacent project you're more
then welcome to use our gitlab instance if you'd like something a bit more
accessible to host your code on.

> It should be a more or less complete implementation of the important
> parts of the Wayland protocol.  Buffer transforms are currently missing,
> but that's because I can't wrap my head around how they work.  If DRI3
> is extended to allow creating Xv video, it would allow implementing YUV
> image formats without a dependency on GL.
> The only major inefficiency I can think of is that buffer contents get
> copied at least once, to the offscreen storage of the toplevel window,
> which is then composited by the X compositing manager.  Buffer-flipping
> does not yet work well for fullscreen opaque surfaces, as that requires
> some additions to the Composite extension here to work well:
>   https://lists.x.org/pipermail/xorg-devel/2022-October/058918.html
> Please try it out and report any crashes or bugs that you may come
> across.  Thanks in advance.  Patches are also welcome, and the code
> should be well commented and structured, but please keep in mind the
> coding standards (which happen to overlap greatly with the GNU ones):
> https://www.gnu.org/prep/standards.

 Lyude Paul (she/her)
 Software Engineer at Red Hat

More information about the xorg mailing list