Related to yesterday’s post about NetBSD switching to ctwm:
After I posted about the new default window manager in NetBSD I got a few questions, including “when is NetBSD switching from X11 to Wayland?”, Wayland being X11’s “new” rival. In this blog post, hopefully I can explain why we aren’t yet!
The short answer? Wayland is too Linux-specific to be easily ported or adapted to NetBSD, so don’t expect it any time soon.
That’s all a bit sad, at multiple levels. Does anyone know what the problem with having a dumb-framebuffer fallback with Weyland is? That seems like a non-negotiable starting position to me, not a “nice to have”. I had been fostering a vague hope that the wheel of reincarnation might have turned enough that a workstation could usefully be built around a 100+ core CPU (with SIMD: an Arm V1 perhaps) and a dumb framebuffer (just DMA the pixels out of GDDR or HBM memory) and drop the proprietary GPU completely.
It was GPU support (lack thereof) that drove me off FreeBSD lo those many years ago. I guess I’ll have to be an Apple workstation customer for a while yet…
For an OS like NetBSD that’s primarily used over a network (e.g. with “admin” logging in from a different computer somewhere else); network transparency and remote rendering seem like a non-negotiable starting position to me. 😉
What’s the real use of remote gui access for netbsd? That seems rather odd to me. I mean there are Linux render farms that are in use in the movie industry that I guess kinda makes sense sorta, even though they’re mostly headless. But maybe the real reason is products that build upon Netbsd ? There are a lot of *BSD in the networking world that have gui interfaces. I think most have them now have web based guis instead, but I’m sure there are outliers, And those are the kind of companies that sponser *BSD devs, so maybe that’s the reason?
Any additional use cases would be very interesting.
On the PC, GPU support on FreeBSD is nearly equal to Linux. It implements DRI and KMS in the kernel, All the open source GPU drivers work, and NVidia keeps their FreeBSD releases current. Really the only thing missing is the proprietary AMDGPU Pro stuff, but that’s based on the opensource AMDGPU driver anyways.
But, the problem the article talks about seems mostly related to the Linux-specific libinput as a requirement for Wayland, and them refusing to accept patches upstream that would add support for the NetBSD’s input system.
And I might add all the opensource drivers work on NetBSD as well – it too has current DRI/KMS support.
It does seem to have been getting closer to working, but we’re clearly at the point where X11 has been declared EOL but the replacement isn’t finished yet: finished as in the default that everyone uses. Not only not finished, but here we are, twelve years since it started and there still isn’t a good story about screen locking and screenshots? Even on Linux the graphics situation appears dubious: a colleague recently “upgraded” to a new mini desktop machine that had (seemingly) the latest integrated intel GPU, nominally supported by intel themselves in the Linux and X11 driver stack, but Ubuntu 20.4 didn’t work in graphical mode at all. Crashed without even the decency to log an error. I think that he had to go back to 16.something to even get a desktop up.
Twelve years is longer than it took for NeWS to start, become the dominant workstation GUI and be obsoleted. It’s longer than it took NeXT to become Quartz, or Android surface flinger to get up from nothing. I’ve been waiting for it, but I’m starting to suspect that it just isn’t going to happen, and Linux/Unix workstations will be a mouldering mess of X11 odds-and-ends forever.
On the up-side, X11 does have (or did the last time I looked) a working dumb-framebuffer software implementation to fall back on…
areilly,
This has happened to me as recently as this year, although in my case it was the discrete GPU that stopped working and the integrated one that worked. I predict things are not going to get better for the foreseeable future because we’ve already had decades to sort it out and the willingness isn’t there. Neither the linux devs nor manufacturers are willing to make the necessary compromises for both stability and transparency. It’s always going to be hit and miss especially if you don’t buy from linux vendors that work to proactively resolve issues before customers are impacted.
The vesa software framebuffers always used to be extremely reliable in my experience. For me anyways it’s always been the other drivers that didn’t work. Sometimes the live/boot media would be programmed to always use vesa graphics and work correctly, but when the system boots for the first time it goes to a blank screen… so frustrating. I agree it should always be there as a backup.
Wayland is a train wreck. Not sure why they thought it was a good idea to make each desktop environment have its own window server and leave a lot of functionality completely up to individual implementations. Once Wayland becomes more popular, there will probably be quite a few applications that only work on the major desktop environments, whereas with X11, it’s rare for window managers to cause any serious application breakage (at least in my experience). Another issue is that things like VNC and screen sharing are a lot more difficult with Wayland because either each server will have to implement VNC and other remote desktop protocols itself, or a VNC-specific window server with only limited functionality will have to be used instead. Yet another issue is that lots of high-level functionality gets pushed into the window server, leading to more surface for vulnerabilities and crashes (a good X11 replacement would remove all high-level components from the window server, rather than just replacing one set of high-level components with another).
There’s no good reason why a modern compositing window system can’t be split into a minimal server that handles client connections, secure hardware multiplexing, and event delivery; and a compositing window manager that runs on top of the window server and only handles compositing, window positioning, and window decoration (the window server itself could still incorporate a very minimal fallback compositor in case the real window manager crashes, but it wouldn’t function as a compositor otherwise). X11 compositing window managers could be ported to such a window server relatively easily since it’s not all that different from X11 (mainly the parts where the WM directly interacts with the server would have to be changed).
I think if the official replacement for X11 had gone with an architecture that maintains the separation between window server and window manager, it might have been rolled out a lot more quickly since each DE wouldn’t have had to implement its own window server. However, that probably isn’t the only factor though.
Graphical experience on Linux is top noch for me, managing different screen at different resolution. Sure I avoid to use a 1080p beside a 2160p screen because of scaling but when I do, I simply don’t span a window over two so different screen, i don’t see the point anyway.
X11 is EOL but it works. My experience with FreeBSD on Intel and nvidia was quiet ok.
At least, nothing justifying me enough to move to Windows or OSX as main daily drivers, i do have a mbp though and I am not impressed.
I’m sorry, as a person using compute heavily… FreeBSD GPU support is nowhere near Linux.
NVIDIA does support it somewhat, but it is in mainly in maintenance mode, and there’s no guarantee of future support.
OpenBSD uses its own custom X server, why couldn’t NetBSD or even all the BSDs do the same with Wayland?
There isn’t a single “Wayland server” package, unlike with X11. Every desktop that wants to support Wayland is required to reinvent the wheel and implement its own Wayland server. The only parts that are shared between Wayland servers are the base Wayland protocol and kernel event protocol libraries (both of which are rather low-level) along with the OGL/Vulkan libraries. They would basically have to either pick an existing Wayland server implementation to fork, or implement their own from scratch, and it wouldn’t be possible to switch WMs/DEs like with X11.
Indeed. The BSDs could just dump GNOME/KDE altogether and concentrate their efforts on wlroots + a tiling wm if Wayland becomes unavoidable in 20 years.
okay
There are many basic mistakes.
1) every major desktop environment with X11 these days has their own compositor. Yes this can bring complete desktop to a grinding halt under X11. Reality X11 server has no longer been core for a long time.
Wayland not having a server implementation is the reality that X11 server had been highly bypassed. Working around with wine you have bug reports that only effect gnome or only effect KDE or only effect xfce… all under X11 server.
2) Vesa driver with X11 is not in fact simple.
https://kimbriggs.com/computer/x11-xorg-conf-vesa-driver
Vesa driver in fact requires you to run X11 with root privileges. Gets worse only works with 32 bit and 64 bit x86 systems at the moment it use to work with Alpha as well but currently does not. Vesa does not work with arm or anything else not x86 or alpha based.
The reality is Kernel Mode Setting in OS kernel is meant to take over the role of setting up a basic buffer for output.
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#frame-buffer-abstraction
Yes Kernel Mode Setting is meant todo all the buffer setup. Yes different Linux distributions if you don’t make X11 server root again you cannot use Vesa driver mode and in future even doing that will not work.
3 libinput. Now this is the elephant in the room that people nicely walk past. What is the generic input driver for X.org X11 server officially. That right libinput. Next question are there any BSD developers working on libinput so the generic X.org server input driver in fact works. The answer is nop. Freebsd has worked on adding enough linux input emulation that libinput works but NetBSD has been doing their own non up-streamed input driver for a long time with X.org X11 server.
The reality with the change to KMS means a lot of functionality that was in the X11 server ceases to be in the X11 server and is moved into the kernel. Wayland also has a lot more stuff that is now expected to be done kernel side that use to be X11 server responsibility. Yes libinput also has a lot of stuff moved out of X11 configuration files and into generic locations as well.
Yes a lot of people compare wayland compositors to X11 Windows managers the reality is wayland compositors align to X11 compositors for issues they cause.
Yeah, you’re really not selling that situation as a win, in my book.
Is there any way, do you think, from “here” to a working, reliable, GUI system, where apps have stable APIs to build against, and you don’t end up with different bugs depending on which “desktop environment” you’re running? If yes, then how long? Another ten years?
A search made right now, about writing a weyland client application found this page: https://jan.newmarch.name/Wayland/ProgrammingClient/ with the warning “hasn’t been updated since mid-2017. Wayland has moved on since then, so the information here may be out of date”, and another, later: “Wayland is a “work in progress”. What this generally means is that the documentation is completely out of sync with the code, examples you find on the net don’t work and getting things to work is – at best – tricky. Wayland conforms to this. The Wayland reference manual describes the client API in its Chapter 5. You might as well ignore that, because it isn’t helpful as well as being incorrect.”
So, that’s comforting!
All (all!) of the other search results on the first page were related to how to write a wayland compositor. As though that’s something that anyone outside a few core projects would care about and something that isn’t a long-solved problem.
Still smells like car crash to me.
The reality here is the search results are deceptive. Its more people not being willing to work on documentation what
you are seeing.
https://wayland.freedesktop.org/docs/html/
Project Wayland API/ABI core is solid has been that way since 2012 so all the examples in that site you linked to in fact still work. Heck older stuff still works because the ABI is solid. The extensions to the Wayland are a work in progress so are the extensions to X11 server. The wayland protocol has a hand shake for the client to get from the server what Wayland extensions it has and supports the toolkits gtk/qt are adaptive as they will work with the first version of wayland protocol compositor Weston yet take advantage of extensions in wayland of newer compositors.
Also by the way there are a lot of X11 documentation that is also incorrect.
We even tried to create the necessary software for it and it was very difficult, besides it really required a lot of skills and knowledge on this topic. It’s also good that my friends and acquaintances helped me just how to make the necessary software, they told me exactly where to go to help with such a project. It is good that I have addressed to professionals here https://writemyessay4me.org/capstone-project , I recommend to look, for any student it will be useful, I already know simply by itself. Good luck, I hope that somebody really managed to help.
Do you want to spend a lot of time writing an essay? Then you need to find some money to order it https://expertpaperwriter.com/essay-typer-review/ on a specialized service.