About Wayland , xwayland and the near future developement

[thealio]

Hi everybody,
I consider myself a very xmonad enthusiast user.
I was pretty happy when I read that something is moving to the right direction about future plans about Wayland compatibility ( here : https://discourse.haskell.org/t/xmonad-for-wayland-call-for-help/7812/6 ) , because the project could stand for years to come.
Yesterday, an user in a Linux Telegram chat said he was able to start xmonad under Wayland (I suppose under Xwayland) , installing it after a Plasma installation on arch Linux.
I never tried such thing, but this make me to ask you some question about xmonad , wayland and the imminent development choices :

• Will a possible xmonad Wayland port have a bad impact about usability , flexibility and features ?
• How about xmonad under xwayland?
• Is technically possible to extract all the necessary components of xorg that are needed to xmonad to work and patch them into a single package ( or into a group of packages) that can work together with xwayland , and adopt it as "middle step" while working on a full wayland compatibility? Can another "middle step solution" be eventually adopted?
• About the near future development: since works on Wayland requires time & effort, and the project is quite feature-rich , can be convenient to do a "temporary new features freeze" after the next major release, and then working only on stability , bugs correction and Wayland compatibility, and begin again to add new features only when Wayland port will be completed?

Thanks in advance for the attention .

I hope that my questions can be good points for a positive discussion and ideas sharing

Thank you Again

[geekosaur]

Addressing your questions in order:

1. We don't know; that's one of the things that needs to be determined by someone who knows Wayland. See the early discussion in that Discourse thread for an example.
2. xmonad under XWayland probably can't usefully get at anything resembling WM_CLASS, which will impact manageHooks. This apparently requires hooking into the compositor to fix, per the Discourse thread.
3. Likewise, most of the things we would need can't be extracted from X11; they need to be extracted from the Wayland compositor directly.
4. The core doesn't need to be frozen (it has been bug fixes only for a long time), and contrib will probably need to be rebuilt from scratch because the X11 calls used by contribs can't be readily converted into Wayland protocol calls. So there is little point in doing this.

[thealio]

Thank you for your answers. About the already mentioned points:

2. Can it be achieved by writing a brand new haskell module? Would working to Xwayland compatibility before woking to a full Wayland port be a good "middle step" to do?
3. About xmoad-core and xmonad-extras , can be convenient a this point to merge them together doing a "code cleaning", to make easier an eventual wayland port?

[geekosaur]

Re 2, a new Haskell module would not help unless XWayland somehow exports things that Wayland considers private to the compositor. I don't think XWayland can even access them as a result, but as with writing a full Wayland compositor, we don't know enough.

Re 3, that would not make it easier, it would make it nearly impossible. It is not core calls but Wayland vs. X11 calls that need to be rewritten, and xmonad currently uses XLib instead of XCB (which would be much easier to port to Wayland).

[thealio]

Thank you for your answers again
It seems more tricky than I expected.
I hope someone with more Wayland knowledge than I have can join this discussion and put in some good suggestions

[geekosaur]

Okay, a quick search confirmed what I had suspected: you can run an X11 window manager under XWayland in "rootful" mode, but it can only manage X11 windows, not Wayland windows. So that is not a useful transitional path.

[thealio]

Re 2, a new Haskell module would not help unless XWayland somehow exports things that Wayland considers private to the compositor. I don't think XWayland can even access them as a result, but as with writing a full Wayland compositor, we don't know enough.

Hi,
I still think that , as intermediate step, offering a good Xwayland support can be useful

I found this , it may help

https://blog.alphabit.org/2023/06/running-xmonad-in-wayland.html?m=1

BTW, are there any news about Wayland support? Unfortunately, time is running fast , and Wayland is still pushed, despite its current limitations / issues

[geekosaur]

We still have not made a decision. But time is not running any faster than it was 2 weeks ago, and due to Red Hat's contractual obligations we have at least several years.

[thealio]

The real problem is not about xmonad using xorg (absolutely fine for me) or Redhat contractual obligations, but is instead about :

• how developers will deal with Wayland support, because, I'm pretty sure, some popular programs will drop xorg support "for political reasons" , and windows managers and DEs that will not follow the transition will be out of the rest of "ecosystem" around them, practically unusable by average users
• how the average Linux user consider the Wayland transition, currently the silliest way : "Wayland is perfect because the major propaganda says that, so stuff that doesn't support Wayland is obsolete/insecure , and I've to stop using it". People just think like that, and a good mount of users will simply stop to use xorg stuff
  Long story short, do not support Wayland will mean to lost a good amount of userbase, in most of the cases