Add wayland protocol support

[Fox2Code]

With this project trying to be a modern XServer implementation, I was wondering if adding Wayland support to X11Libre could be on the table.

Some application are Wayland only, and being able to use Wayland application on an X11 desktop would be nice.

Wayland calls being translated into X11 calls would probably be the way to do so for the majority of APIs to avoid duplicating work.

I think the core wayland protocols + xdg_decoration should be enough for a start. (See https://wayland.app/protocols/)

This would ensure X11Libre long term survival in the wayland era.

[Ma5t3rful]

Basically WXLibre

[dec05eba]

It wouldn't necessarily have to be in xlibre, for example this has been done here before: https://sourceforge.net/projects/twelveto11/ although it seems to be abandoned now? For a proper wayland desktop experience you also need to support desktop portal which implies dbus + pipewire support as well, and that would be nicer to do outside xorg server code.

You can run some wayland compositors on x11 right now, such as weston, wlroots ones such as sway and cage which allows you to run wayland applications on x11; so maybe the easiest way would be to fork one of those and make it display an x11 window for each wayland window, instead of what they do now with having one x11 window for all wayland applications. This would make it significantly easier than implementing everything from scratch and also benefit from protocol updates. Having such an application run in the background and turn wayland applications into x11 applications would be possible then.

[callmetango]

There is someone still working on probonopd/12to11.

[dec05eba]

@callmetango that's a mirror of this https://git.linuxping.win/12to11/12to11

[metux]

Weston already runs ontop X11. Not actually nice experience yet (since it seems to support only single-screen), but it could be improved to support multi-window, transmitting copy buffers, etc, etc.

Feel free to implement this stuff. I'd be happy to add it to the X11Libre project :)

[SuperDuperDeou]

Weston always spans a full shell. It's a way to run a Wayland session on an X11 backend, but not individual applications.

[probonopd]

Some of us are using X11 so that we don't need more Red Hat influenced technologies like D-Bus, Portals and Pipewire.

[roryyamm]

The big players march to Red Hat's drum. Either we pretend to tolerate it or X11 will fade into history.

Though, if XLibre can implement Wayland better than Wayland can implement X11… that'd be a sight to behold, wouldn't it?

[OutOfContainment]

And pulseaudio isn't Red Hat infuenced? Or you just generally prefer non-working solutions to working ones? Though Lennart now works in Microsoft and I can tell you're a big fan of these guys :)

[oiaohm]

Weston already runs ontop X11. Not actually nice experience yet (since it seems to support only single-screen), but it could be improved to support multi-window, transmitting copy buffers, etc, etc.

It looks that way bit is not in fact true that weston support only a single-screen experience. Rail-shell used by microsoft in their fork of weston used in WSL show it possible to put a plugin shell into weston to make applications running under weston seamless so removing that limit just nobody done this upstream for weston running on Wayland or X11 backend but it is absolutely possible.

The limitation here is nothing more than the plugin shell weston has loaded. So wonder if this issue should be redirected to weston project as a feature request.

[Fox2Code]

@probonopd the reality is that Wayland became a necessity for some software (Example: Waydroid), and apps progressively dropping support for X11 in favor of Wayland only making Wayland support a necessity isn't something you can just wish away.

I believe X11Libre supporting Wayland apps might be the best way to ensure the long term success of X11Libre.

[probonopd]

See 12to11 (mentioned below).

[reaperx7]

Wxlibre would be a worthwhile addition to avoid wayland usage directly and be a way for wayland only apps to work under X. I second the motion to import TwelveTo11 and work on implementing it.

And the pipewire comment... Well at least pipewire is better than pulseaudio... I don't like Red Hat software myself, but pipewire at least behaves itself.

[givememymilk]

Wxlibre would be a worthwhile addition to avoid wayland usage directly and be a way for wayland only apps to work under X. I second the motion to import TwelveTo11 and work on implementing it.

And the pipewire comment... Well at least pipewire is better than pulseaudio... I don't like Red Hat software myself, but pipewire at least behaves itself.

You can just run a wayland compositor inside Xlibre if you want to use wayland-only apps

@Fox2Code

[nwildner]

Just to add my 2 cents to the discussion: Cage works great for running Wayland applications inside X11 environment in a kiosk-like environment.

I was able to run a full waydroid instance on it.

[reaperx7]

Wxlibre would be a worthwhile addition to avoid wayland usage directly and be a way for wayland only apps to work under X. I second the motion to import TwelveTo11 and work on implementing it.
And the pipewire comment... Well at least pipewire is better than pulseaudio... I don't like Red Hat software myself, but pipewire at least behaves itself.

You can just run a wayland compositor inside Xlibre if you want to use wayland-only apps

@Fox2Code

The idea is to not use a wayland compositor under X, but to have a built-in system (hence wxlibre) like how xwayland works but in reverse.

[givememymilk]

Honestly, that'd be too much work for something that already work well enough

[10leej]

So just install Cage and load your wayland only application in that. All compositors can be launched as windows. Just make a wrapper to launch the window in one. Much simpler solution than say a Xwayland inspired alternative.

[reaperx7]

I would say we might be able to actually go without wayland in any capacity.

Waydroid is the only application I have found that requires usage of wayland, and it's honestly one of the biggest half-assed android emulators out there and it breaks easily with a bad configuration and can't be recovered. You can get around waydroid rven then with the Android SDK suite which has it's own emulator, though it's a bit cumbersome to use.

[roryyamm]

Problem is, GTK 5 and maybe even QT 7 want to drop X11 entirely, so even if Waydroid is the only app that NEEDS Wayland now, it may not be the last.

[dec05eba]

You can use this to run wayland applications on x11: https://git.linuxping.win/12to11/12to11 which I have also contributed to now. Just add it to system startup and you will be able to launch wayland applications and they will appear as x11 windows.

[Samueru-sama]

Alright I've been testing the 12to11 binary, works great.

The only issue I have is that it gives me this warning: Warning: the X server does not support a new enough version of the DRI3 extension. and OpenGL apps default to lavapipe as result.

Checking my xorg log DRI3 is running, so I don't know what I'm missing or if this is a bug. Note I'm using xlibre from the Artix repos.

[dec05eba]

Are you using nvidia? there is some type of issue where nvidia cant use hardware acceleration for some reason

[roryyamm]

That happens on AMD, as well. I can repeat the problem (On X11, but still) and I've got an RX 6700.

Again, I think this should be a project XLibre takes under its wing. That way we on GitHub can file bugs for 12to11.

[dec05eba]

Oh right I forgot, you have to run 12to11 with egl renderer, like so: RENDERER=egl ./12to11

[Samueru-sama]

Oh right I forgot, you have to run 12to11 with egl renderer, like so: RENDERER=egl ./12to11

That worked, I also have AMD: RX580 2048sp.

I noticed a bug that my mouse cursor has a square shadow when using egl though, it is not the compositor since I tested killing it.

[reaperx7]

12to11 would be ideal to import in somehow. This way we have a sort of future proof system should anything go fully wayland.

[xgui4]

yes i will love that !!!!

[probonopd]

Here is another way to run Wayland applications under X11: https://github.com/1999AZZAR/use-waydroid-on-x11

[xgui4]

I am feeling lazy, i do not wanna manually editing .desktop file.

[shakeyourbunny]

My question is, if KDE goes full Wayland only in KDE7 is this then a way to yank it back to x11 ?

[darkhog]

My question is, if KDE goes full Wayland only in KDE7 is this then a way to yank it back to x11 ?

Probably by forking the last X11 release, like Trinity folks did with KDE3 (which right now doesn't have working packages on opensuse tumbleweed and that makes me sad penguin). Would be a huge undertaking considering how complex KDE is, maybe even bigger than forking Xorg is.

[xgui4]

My question is, if KDE goes full Wayland only in KDE7 is this then a way to yank it back to x11 ?

Probably by forking the last X11 release, like Trinity folks did with KDE3 (which right now doesn't have working packages on opensuse tumbleweed and that makes me sad penguin). Would be a huge undertaking considering how complex KDE is, maybe even bigger than forking Xorg is.

I don't think a fork will happen as most users probably does not care about the display server if it work for them. Like if all they do is using a web browser, wayland can do the job. But if it more than that maybe they will care, but will probably go to tritinity or a x11 window manager as making a forking take a lot of ressource, time and knowledge espcially for a project as complex as kde like darkhog have been saying but i dont think a fork will happen unless a plasma7 user will get so frustated and fork it , it probably wont happen.

[Daniel-Abrecht]

I think something like 12to11 is the way to go. There may be one problem left though. If a program speaks both, X11 and wayland, how does it know which one is native / which one it should prefer?
I think some kind of standardized environment variable for this would be good. Normally, something like this would be added to https://specifications.freedesktop.org/ I presume?

[dec05eba]

There is already a standardized environment variable for this: XDG_SESSION_TYPE. Not all applications listen to this though.

[Samueru-sama]

I noticed GTK apps will use the wayland socket when 12to11 is running, they ignore XDG_SESSION_TYPE. This is fixed by setting GDK_BACKEND=x11.

I don't have this issue with Qt apps.

However I don't know what would happen if I try to run a wayland only app that uses GTK, will GDK_BACKEND=x11 prevent it from every trying to use wayland? not sure.

[bonkmaykrQ]

I like the idea but I can literally only think of one application that is Wayland only that has some widespread appeal (Waydroid) and it has alternatives. If there are more, they are niche. This is obviously not including the few Wayland-only WMs like Hyprland.

Not that volume of demand should be a prerequisite for a feature but rather would the effort really be worth it? Compared to something like XWayland where there's obviously an immeasurably large supply of programs people rely on.

As Weston is the reference implementation of Wayland and the protocol is ultimately controlled by RedHat Inc. I don't think there is any benefit to having a Wayland server inside of XLibre as any extensions that could make our variant of Wayland actually useful are unlikely to receive developer support. XLibre sets itself apart from all of the X12 wannabes by being the only actively maintained alternative post-mortem from XOrg, having a large following and being spun off by a former XOrg maintainer thereby giving it some credibility in the future of X protocol extensions. (And X version 11 itself predates Linux & RedHat by decades). Not so for Wayland, I imagine most use of Wayland by GUI programmers would be aimed towards the official implementation which all the people still interested in Wayland are already using.

If we're talking future support from programs that bite the bullet and remove X support, then I guess it's a necessity, but the sentiment within GUI frameworks used by most software seems to be (from my observation, feel free to correct me) that X is not going soon.

[darkhog]

Perhaps a better idea would be to fork Waydroid then and make it into an X11 app (Xdroid?)

[ghost]

I guess 12to11 is already mostly feature complete so working on making it function well as a plugin for Xlibre would work well, then not even dropping X11 support will prevent apps from running on Xlibre

[xieyuheng]

You can just use wayland for that, because unlike xorg, wayland as a project is not being killed by anybody.

[ghost]

It's definitely being stifled by its creators. If Wayland launched with a sister project like wlroots that actually did the legwork the Wayland project doesn't it would've been better adopted by no and wouldn't have the problem with everyone making a different implementation that have key compatibility issues with each other

[xgui4]

i love this idea! or at least why not create a Wayland-libre fork and compositor!

[reaperx7]

You know... That might not be a bad idea.

Yank wayland out from under FreeDesktops by not only feature tracking them with a fork, but then fixing broken and implementing missing protocols. Big money team versus indy free team, yet again.

Then build a compositor as part of the whole, not separate, that brings in the same features as Xorg as part of the project by extension. Have X as part of the compositor, not like xwayland, but built-in. X and wayland working together, not separately. Instead of using OpenGL and Vulkan by default, have a fallback system for the old DDX/Xshm(?) rendering driver, especially for virtual machines. Save some damn resources.

And one other thing...

Have a conf script system similar to xorg.conf.d scripts to allow tuning the rendering server by the user and admin of the system. Make it easy to control. Give the user/admin control.

And don't call it wayland-libre. Too obvious.

Call it... wayroot.

[xgui4]

but i do not have enought knowledge of linux system yet for that and that will take way tooo much time and energy that i do not have

[notbabaisyou]

I've been working on integrating 12to11 on a fork of Xorg, got compilation with Meson build scripts and it being used as a standalone library working, but there's a lot of work regarding getting it integrated into the display server (my concept is to have it be an X module) and having 12to11 take advantage of hardware acceleration through the display server.

Another gripe is that 12to11 is full of bugs, an example is it crashing GLAMOR randomly (at least on my dev machine) which means your session crashes.

[darkhog]

I think once probono (don't want to ping him unnecessarily) starts working on 12to11 again (as there is demand and there are some apps that require wayland or seemingly work better on it) the bugs like the one you describe will get fixed. The best idea would be to make issue about this and other bugs in 12to11 so that these can be fixed.

[callmetango]

Thank you for your contribution! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the Good Ideas For Later category.

[shakeyourbunny]

Edit: didn't saw that work is already done in that regard, but maybe it's still a summary for what that is about.

There is a project called "twelveto11" that is 3 years old and the packaging on the tin reads that it is able turn Wayland in managed X11 windows:

https://sourceforge.net/p/twelveto11/code/HEAD/tree/README#l27

preferably with a compositing manager running.

It is not yet complete.  What is not yet implemented includes support
for touchscreens, and device switching in dmabuf feedback.

It is not portable to systems other than recent versions of GNU/Linux
running the X.Org server 1.20 or later, and has not been tested on
window (and compositing) managers other than GNOME Shell.

It will not work very well unless the compositing manager supports the
EWMH frame synchronization protocol.

Building and running this tool requires the following X protocol
extensions:

  Nonrectangular Window Shape Extension, version 1.1 or later
  MIT Shared Memory Extension, version 1.2 or later
  X Resize, Rotate and Reflect Extension, version 1.4 or later
  X Synchronization Extension, version 1.0 or later
  X Rendering Extension, version 1.2 or later
  X Input Extension, version 2.3 or later
  Direct Rendering Interface 3, version 1.2 or later
  X Fixes Extension, version 1.5 or later
  X Presentation Extension, version 1.0 or later

In addition, it requires Xlib to be built with the XCB transport, and
the XCB bindings for MIT-SHM and DRI3 to be available.

Maybe it is worth a look integrating it into XLibre as a full-blown extensions and/or contacting the developer about it.

[callmetango]

12to11 has got a new repository at 12to11/12to11 - LinuxPingWin git server and work is underway there.

[darkhog]

12to11 has got a new repository at 12to11/12to11 - LinuxPingWin git server and work is underway there.

A bit offtopic question, but can a rando nobody make a repo on linuxpingwin? I am considering mirroring code for TuWiM there in case github shits the bed (would commit to both github ant LPW, with github being the main platform for now).