Hacker News new | past | comments | ask | show | jobs | submit login

Ok, I’m super confused, how much work is involved in supporting Wayland vs Xserver?

[editing to add: my assumption that it isn’t is due to this post - xfce is what I used to use because it was lightweight, but if such a lightweight manager requires significant adoption effort it would imply that Wayland isn’t X API+new extension]

I had thought that Wayland was still functionally an implementation of the X server protocol, just reengineered to drop any pretense of network transparency, but given the amount of work involved that’s clearly not the case?

(It has been a long time since I did anything resembling X development, and so I’ve paid literally no attention to the details)




The core wayland does not even implement the idea of a window, to show how far the differences go.

Based on experiences of an acquaintance writing from scratch support for wayland for an UI framework that shares absolutely zero code with any of the major ones, the differences in even basic things like how to implement drop-down menu are staggering.

Funnily enough, said acquaintances needs would have been fully covered by slightly more capable XRender and a way to synchronize to VSync that does not depend on GLX.


The oversimplified answer is that a Wayland compositor must include all the functionality of an X window manager and the Xorg display server. There are libraries to help implement all that, but it's still a big lift.


Wayland is an entirely new display system that's completely incompatible with X11.

X11 apps can generally run under Wayland, but through XWayland, an X server that runs nested under a Wayland compositor.


Oh, ok, so X apps can run under Wayland, because Wayland DEs can run an X server (an existing X impl, or does Wayland provide an X translation layer/impl?)

But the DE/window manager is what is actually responsible for deciding when/where to provide that interface? For actual rendering+windows etc the DE is communicating entirely through Wayland specific APIs?

I guess the operation mode is similar to how you would run X apps on Mac and windows where you could launch an x server that would act as a layer between the Mac/windows windowing system?


Wayland is written by most of the same folks who maintain xorg, and XWayland is part of xorg.

It's generally more transparent than running a separate X server on Mac or Windows -- you don't normally need to care about whether an app is X11 or native Wayland.


Xwayland is basically Xorg with a Wayland DDX layer -- and it recently got a rootful mode. So that means it's possible to run a complete X desktop, including WM, on top of a Wayland compositor.

However, the drawback is that with the exception maybe of Weston, one does not simply start up a Wayland compositor. You need to have support for logind seats and that sort of thing. So unless you want to spend an afternoon assembling the components like a piece of flat-pack furniture from Target, you basically need systemd and a distro that bundled those components for you the right way.


> You need to have support for logind seats

Not really. It's perfectly fine to just advertise a single dummy wl_seat, and use whatever non-logind mechanism there is to tell the OS that you want to be in control of the input and display hardware.


There is no reverse equivalent of Wayland->X11 to my knowledge. Just the X11->Wayland via XWayland .


You can run any wlroots- (and possibly smithay-) based Wayland compositor nested inside an X11, but it won't be rootless; you'll get a separate window that all the Wayland apps will be drawn into.

There's really no reason why someone couldn't write a "WX11" or something of that nature, but I'm not sure it would be worth the effort.


Weston has (for the time being) an X11 backend.


A desktop environment in X11 is leaning on the X server. One on Wayland has to have libs for most of the things. There is no window manager. A compositor is like a server and a window manager in one. There are libs, but the process is much more involved and the API is much more tight so not everything is easy to get as in X.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: