Wayland on OpenBSD
xenocara.org
xenocara.org
While the Wayland protocol does reuse some libinput names/enums/etc., I don't believe there's anything in it that requires those particular implementations or APIs (that is, wl_pointer and wl_keyboard doesn't have to be populated by libinput).
Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives. Granted, this would mean non-wlroots compositors would also have to implement this if they want OpenBSD support, but I'm not sure I'm convinced it's good for the OS ecosystem in general to standardize the userland interface that's provided to interact with more and more hardware.
Put another way, libinput seems fine to me, but part of the reason to have different OSes in the first place is to allow people to explore different approaches to doing things. Requiring that every OS that wants to have Wayland do things the libinput way seems counterproductive.
Relatedly, it seems silly to me to get seatd running on OpenBSD if OpenBSD doesn't support the concept of multiple seats. Compositors should just have a mode where a single, static seat is defined that owns all input and display devices.
They have thrown everything difficult out of the spec and only implemented the most trivial functionality around a security model which you must actively break to get actual work (like screen shots) done.
That Wayland is 10 years old and still barely usable should tell you how far software developers have fallen in the last 30 years.
Perhaps you could show them how it's done, since apparently you can do a better job. They've certainly been clear that they're happy for anyone who wants to take over Xorg, yet no-one from the peanut gallery ever does.
Since Wayland is a horribly complicated protocol that makes doing even the simplest tasks a major chore I would consider it sabotage. There are multiple billion+ dollar corps out there with a severe interest in a non fuctional FOSS ecosystem.
Of course, like any good conspiracy, it's very competent and expansive, managing to simultaneously secretly convince all the major distros to use it by default and cruelly suppressing any efforts to provide funding and engineering effort towards X11.
In reality, Wayland works great for most Linux desktop users (on the mainstream distros) and no-one is funding X because no-one wants to.
Also no Wayland does not work great for most Linux desktop users. Even not in reality. It works incredibly well at making the life for application developers extra hard though.
Actually, because it's ready and it works. And yes, most distributions use Xorg by default and all attempts to switch to Wayland fail, ex. Ubuntu. (maybe GNOME is an exception, but it's probably the only DE where Wayland somehow works).
This is just false. Wayland's the default in Ubuntu, Fedora, Debian (how many users is that?) etc. And it works just fine out of the box on Gnome and KDE/Plasma, the two big DEs.
Not exactly, they have thrown out everything that almost nobody uses - such as networking. They have, however, added things that most people do care about - such as different HiDPI across multiple monitors and an extremely thin (low latency) render path.
> That Wayland is 10 years old and still barely usable
And that has changed in the past 2 years (with exception to whatever Ubuntu does to screw it up, but such is Ubuntu).
And color calibration.
>such as different HiDPI across multiple monitors
I had this working with multiple X11 servers 20 years ago.
>And that has changed in the past 2 years
I was told that exact same line 5 years ago. I guess it will be just as true in 5 years again.
You had to hack around X11's shorttcomings.
X11 does not support HiDPI or multiple DPI across multiple monitors without hacks and workarounds. Wayland does. That makes X a non-starter and Wayland the only choice for many users.
Wayland has clearly chosen a set of trade-offs that are far superior for a lot of users and I fully expect anybody sticking with X11 to gradually become more and more of an outlier over time, and that's entirely fine by me.
(I use fvwm2 with a sub-40 line config that starts by turning almost all the usual features off, plain xterm, and heirloom vi, I'm already perfectly used to being an outlier and so long as I can coax it all into keeping working I don't see any reason to complain that lots of other people prefer to use things from this century instead ;)
https://trout.me.uk/X11/fvwm2rc https://trout.me.uk/screenshot4.png
That gives me a 3x3 X11 screen of my actual screen size with the laptop screen acting as a scrolling viewport, keyboard shortcuts to jump one screen or one xterm's worth of screen at once (the xterms are launched pre-tiled by a script, I like that layout but I don't get on with tiling window managers) and rely heavily on focus follows mouse to be able to e.g. type into a window that's mostly covered by another one that I'm reading stuff from as I type.
Plus I'm currently running VcXsrv in full screen mode on a Windows 10 install connecting to WSL2 over local TCP, though so long as I can get "Alt-Tab to a full screen session with no windows title bar/etc. taking up space" -somehow- I'm not really tied to the X11 protocol, I'm looking at switching over to RDP anyway (and would accept VNC, I already use that for remoting to Debian and FreeBSD system out on t'internet but the full screen experience tends to be a tad inelegant at least with the client configs I've tried to date).
Now, if those both sound like they's at least -doable- with anything up to, say, a moderate amount of pain with Windows 10 acting as a client to all of WSL2 Debian, a 'real' debian install, and FreeBSD, I'm happy to endure lots of RTFM and some faffing to get there, but last time I tried I ended up at "either this isn't really possible yet or I've completely failed to find the correct FMs to R to figure it out."
If anybody has a minute, a reply to the effect of "yeah, not yet" or "here's what you should've read to realise it is actually possible and not -too- painful so long as you read all of these links carefully" would be appreciated and I'll go do the reading and try and find time to try it out (probably with the FreeBSD system as the thing running the RDP/VNC/whatever server first since I want to move my main firefox instance there) ... but I'm very much aware that my preferences and workflow are kinda weird and there are almost certainly higher ROI things for the relevant contributors to be spending their time on so I'm pretty comfortable with "Wayland should probably be the present or at least near future for most people but I may be staying on X11 for a while yet" as a situation :)
(yes, I know, but it all works for me)
People want to move windows between their screens.
The lack of proper HiDPI support was really starting to become a problem when trying to run Linux on a laptop that isn't from the early 2000s. Fortunately, with wayland, it now seems mostly solved (at least in Gnome and KDE).
Yes, you use he fact x is a network server and run each screen as a separate client.
X doesn't like this. Wayland works much better.
Wayland doesn't have all the features we'd like it to have yet, it's missing some big things like global hotkeys and color management. It's not moving as fast as I'd like, but all those things are being actively worked on.
X11 also doesn't have all the features we'd like it to have, such as the ability to render frames without tearing or the ability to lock the screen while a context menu is open or the ability to implement a desktop environment without a ton of race conditions. Those things are not being worked on, and X11 will actually regress as new hardware is released and developers don't focus on hacking X11 to work with that hardware.
For a lot of users (such as myself), Wayland is already better than X; there's a reason lots of distros ship Wayland by default now. The situation is certainly way better now than it was 5 years ago.
But that doesn't mean you have to use it! It's ready for you when it's ready for you, and maybe X's wonkyness doesn't annoy you or you've learned to hack around it (congrats on getting different DPI scaling on different monitors to work! I haven't, despite struggling with it. I didn't even know DPI scaling was a thing 20 years ago. Anyway, it worked out of the box on Wayland.)
What exactly do you mean? My Xorg setup can render frames without tearing just fine, both in video playback (VLC) and in games.
TBH i don't really care about tearing (since it tends to come with input lag even on desktop usage) aside from videos, so i haven't looked much into it. However people are working on tearing in Xorg - see the latest commits by Sultan Alsawaf on the xfree86 subtree[0] (which is the standalone X server). Specifically this[1] commit adds a "TearFree" page flip mode in the modesetting driver for not having any sort of tearing at any setup.
[0] https://gitlab.freedesktop.org/xorg/xserver/-/commits/master...
[1] https://gitlab.freedesktop.org/xorg/xserver/-/commit/a94dd95...
Note that i do have tearing in the desktop if i -e.g.- move windows around, but this is something i want as i do not like the slight input lag compositors add (even on my 165Hz monitor). However there isn't any tearing in VLC or in games (which, depending on the game, i might also run with VRR).
AFAIK the modesetting driver got VRR support only recently and the TearFree mode only just a few months ago so if you used that you might have used some older version.
Though if you tried a compositor, i don't remember using any compositor that didn't do some form of vsync to avoid tearing. I just started KDE Plasma with Xorg in another virtual terminal with its compositor and default settings (i started it as a different user with default settings that i sometimes use for testing) and there wasn't any tearing at all even on the desktop (again using the amdgpu driver).
I myself was not a fan of wayland either, due to a bunch of functionality removed which I use in my workflow, and will stick with XOrg until XFCE forces me to switch to Wayland.
There's a lot of churn in the Linux ecosystem, and some are going to be better received than others. I didn't see the point in Wayland (but I'm not a maintainer of XOrg code to understand how bad the codebase is), I see the principle behind ideas like Flatpak (although not sure if they have a good sandboxing story now, but they sure have their GBs of layers), but when it comes to pipewire, for example, I'm very happy that it exists.
I keep hearing this: "they've added things people care about, such as..." then a shopping list of utterly irrelevant stuff I can't even see.
>1 screen with different DPI is THE ONLY thing Wayland does that I want.
I don't give a flying monkey about rendering pipelines, refresh rates, tearing, or any of that stuff.
If someone found a way to add variable DPI to Xinerama, job done, and I could continue to use X for another decade or two, and ignore the weird arcane stuff that the Wayland folks want and AFAICS nobody else cares about...
Just as with GNOME, or systemd, or OStree, or Flatpak, or almost anything else new out of Red Hat and its community in the last decade.
What does different DPI mean for you though?
Xinerama causes the server to report the same fake DPI across monitors for backwards compatibility reasons (last year or so Xorg was released with a better approximation for DPI but it apparently broke a bunch of programs so it was reverted in the next release), but applications that care about DPI can still use the RandR extension to obtain not only per-output DPI but all sorts of output-specific information.
The X server had functionality for years, from what i can tell the issue isn't on X11/Xorg/Xinerama/Xwhatever anymore but on the clients (toolkits, window managers, etc) to use it to do something useful.
1. The toolkit/applications needs to support scaling, preferably using arbitrary (aka fractional) scaling.
2. The window manager needs to obtain per-output (output=monitor) DPI and associate a scaling value for each output (note that scaling and DPI are not necessarily tied - someone might e.g. want a high scaling factor for a secondary 1440p monitor because they have it farther away than their primary monitor).
3. The application/toolkit needs to tell to the window manager that it supports scaling as well as know that the window manager supports scaling. Window properties can be used to do that.
4. The window manager needs somehow to communicate to the toolkit/application to scale a window. This can happen either because the window was dragged to a monitor (output) with different output but it could also be because, e.g. the user explicitly requested to scale a window from the window menu (e.g. for making a screencast for youtube). This "somehow" is basically a set of messages since the mechanism is already used for other things already.
5. If a toolkit/application does not support scaling (i.e. it does not have the appropriate properties) the window manager may decide to fake it itself (e.g. by redirecting the window output to a pixmap and then drawing that pixmap scaled). If a toolkit/application does support scaling but the window manager doesn't then it is up to the toolkit/application to decide, e.g. it may do its own scaling by tracking the output the window is and scaling itself appropriately (this will need some heuristics to avoid being too janky as the toolkit/application is essentially taking over part of what the window manager's job and toolkits/applications may just not want to do that).
If it isn't already obvious, the issue here is that this concerns multiple entities:
1. There needs to be some sort of commonly accepted messages and properties for the window managers and applications to communicate scaling.
2. Toolkits (and applications that use custom toolkits) need to implement support for scaling and handling the above messages and properties.
3. Window managers also need to implement the above messages and properties, implement some sort of scaling configuration and use the appropriate RandR functionality to setup initial per-output scale configuration.
AFAIK of all the above the only thing that exists is that the X server can provide the necessary information and Qt supports fractional scaling. AFAIK it also can use its own root property to set per-output scaling but it does the scaling itself independent from the window manager so it is far from ideal.
For the rest basically the toolkit and window manager developers need to be convinced to work on it and also come up with a common message/property protocol, both of which IMO are the hard parts - compared to that, the technical side is easy :-P.
You say:
> If it isn't already obvious,
None of this is obvious. I think to most Linux users, that is impenetrable. It is to me, I'm afraid.
But you could potentially do the X.org world a big favour by developing that comment into a detailed blog post, with examples and hypothetical proposals of how to do it.
Given (a lot) more info, I would like to write about this.
ISTM that X.org and X11 in general is on the threshold of dying from neglect in the next year or two, and unless the people who understand the issues step up and explain them to the general FOSS world, so that someone can see if maybe they could start to work on them, it will die... just because nobody could be bothered to keep it alive.
And since there isn't a single Wayland environment I personally can stomach using, that would be a very bad thing IMHO.
Currently the choices are two raging trash fires of CADT development and vanity, and a handful of weird tiling window manager things.
FWIW i don't exactly know "who" needs to do what either - that is the issue really, in order to get that in the X11 world you need several different people and projects to care to work together. AFAICT most don't really seem to care to make an organized thing.
The main reason Wayland sidesteps some of that is that a Wayland compositor combines the graphics system, the window system and the window manager in one program, meaning that one project can solve everything itself (even if all compositors need to solve it separately), however with X11 you need all window managers and all toolkits to coordinate with each other.
The other reason is that Wayland has buy-in from the two major toolkits, Gtk and Qt. I have a feeling that even if there was an X11 coordination to implement mixed DPI functionality at least Gtk wouldn't bother with it as they want to remove X11 support in Gtk5.
> None of this is obvious.
Well, that was tongue in cheek, i meant that the obvious thing was that it is a mess :-P.
> ISTM that X.org and X11 in general is on the threshold of dying from neglect in the next year or two [...] And since there isn't a single Wayland environment I personally can stomach using, that would be a very bad thing IMHO.
IMO any news of Xorg death are somewhat exaggerated, as i wrote in another reply a couple of days ago, both Xorg and Wayland compositors use the same underlying kernel APIs to access the hardware so if nothing else your current environment will keep working for the foreseeable future. Also i've dabbled a bit in the Xorg code myself and i'm certain it isn't that hard to keep it in working condition - the biggest issue might be people interested in merging patches and making releases but so far it seems to be people who are interested in that.
100% believe that and that it's a big problem.
I've seen some say that Xenocara in OpenBSD is the only project with some active R&D going into this today. Any comments on that?
> AFAICT most don't really seem to care to make an organized thing.
Definitely. Of course, if someone somewhere were paying it might be different...
> The main reason Wayland sidesteps some of that is that a Wayland compositor combines [...]
If I may attempt, and this is not meant to be rude, to say what I think that would come across to most even quite nerdy folk as:
Wayland combines tech, tech and tech, but tech still has to tech, whereas with X11, you have to tech, tech and tech separately, and then tech some tech alongside a tech.
I am using [TECH] in the way it was apparently used in Star Trek scripts: https://memory-alpha.fandom.com/wiki/Technobabble
> The other reason is that Wayland has buy-in from the two major toolkits, Gtk and Qt.
That's a much bigger issue.
I suspect GNOME 4, aka 3.40, aka 40, is revealing a bigger problem. Just as all the other desktops got up to speed with Gtk 3, GNOME yanked the rug out from under them with Gtk 4.
The GNOME team don't seem to me to care at all about other desktops, and they don't care much about their users' preferences either.
The attitude seems to me to be:
"Hey, Steve Jobs just gave them what he thought they needed, and they loved it, so we can do the same! He took away all their buttons and ports and slots and so on, and made it super simple, and the company is worth trillions! So we can just take away all those options and buttons and functions, all the junk we don't use, like themes and stuff, and they will love it!"
Any project that isn't directly affiliated with GNOME will come to regret using Gtk in time, I suspect.
Qt sounds better, from my uninformed outsider perspective, but I don't know much at all. AIUI the price of entrance is you must use C++ or have a 2nd class experience, and a lot of people don't like C++.
Maybe this is the big chance for the GoLang or DLang folk to prove themselves: do some better, modernised version of one of the other toolkits, say one from olden times like XForms or something, and offer a compelling alternative that's 100% FOSS, and accessible from other languages, not just their pet one.
If it's a tractor, it's quite an old one. Give me that new tricyle instead: https://www.youtube.com/watch?v=wy8MZuAwNZc
After X11R7.7 the Xorg project changed its release model so that instead of making a single release that contained everything, it was split into separate packages each one having its own releases, versioning, etc and being independent from each other.
So depending on what you are looking for you'll get different results for the latest dates, though pretty much all of them would be more recent than 2012. For example when people mention "Xorg" they usually mean the standalone X server xorg-xserver. This had several releases this year with the last being xorg-server 21.1.8 released in March.
None of the apps I use regularly need XWayland: they've all been ported to talk directly to the Wayland server.
I like Wayland.
Aside from specialized distros, i don't see why they have to choose only one or the other instead of providing both. Most distros - especially the Debian derivatives - have a ton of alternatives for projects that do more or less the same thing and a bunch of obscure projects, having an X server surely isn't that much of a deal.
Of course those that provide a default DE or whatever out of the box will most likely need to choose a default setting, but that is just that: a default setting. Just because my openSUSE Tumbleweed installation came with KDE doesn't mean i had to stick with it instead of replacing it with Window Maker.
Can you separate just the parts that make X.org a display server from the parts that implement mouse input, keyboard language mapping, general-purpose IPC, 2D graphics drawing, font rendering, userspace graphics driver abstraction, joystick device handling, SPICE display driver, and three different 2D graphics acceleration APIs? Because then you might be able to make a comparison between X11 and Wayland.
To be honest I associate 'barely usable' more with X11. I haven't forgotten the good old days when I had to hack various configuration files just to get a working desktop and then hack some more to work around issues with tearing, video acceleration, etc.
Wayland on the other had has just worked right out of the box since Debian 11. I have not touched a single file, line or character to get Wayland to work optiminally. That is a remarkable achievement IMHO which X11 took years and years to achieve.
It's at least 2 decades old, if it was ever a real problem in the first place.
It definitely used to be a huge pain in the arse. There used to be pages after pages after pages of random "HOW TO ..." style guides for people to configure X11 config files around the net (many just working for specific hw).
It was an incredible mess, with pretty much nothing positive about it. ;)
But it was indeed around 20 years ago that it was an issue.
X has a lot of code in it which needs to be elsewhere in the design envisaged for Wayland. Once support (for example, for kernel mode setting) is available for Wayland to use it, it makes a lot of sense to also use it with X.
With a compositor other than the Gnome one?
Is that using the Gnome compositor?
Or is all maths broken because I found a calculator that doesn't have a working addition key?
Having to worry if your WM supports your GPU is like having to worry if your web browser supports your NIC
A wm has always been trivial compared to a display manager, people just mistake one for the other.
Qt/KDE is lagging behind and there are no easy way for them to catch up. Had the display server been a single implementation, Qt/KDE can focus on WM/Widget..
They want to have everything built in-house, they could join forces with Sway/WLRoots but when approached they declined.
I am fine with having multiple implementations, we don't want to get stuck with a defacto standard, but don't blaming KDEs choices on Wayland.
Wlroots is there for those who wants it and can agree with its design tradeoffs and it is used by plenty niche wms, so I think we have it as good as is feasible in a bazaar style, “everyone works on what they like” fashion. Without a higher power to spearhead a single project there can’t really be a difference.
* A set of utility X applications, like a panel and launcher
* A recommended window manager
* A recommended display manager
And then this all runs on top of a separate X display server
Generally the last two are easy to replace, for example I have used both Compiz and Xmonad on Gnome 2 and XFCE. Gnome was probably a bad example for me to pick since modern Gnome does merge the first two bullets into one, but it's still separate from the display server and can be launched from other display managers, or none (just startx)
Again, it would be like Firefox needing to talk directly to my network card rather than the actual packet sending be managed by the layer below (the OS in that case)
Gnome/KDE/wlroots are akin to separate browsers implementing the same (HTTP) protocol. It’s a lot of work, plenty choose to rather fork an already existing code base (chromium based ones), but with time people will consolidate on a few ones. But you surely wouldn’t want an all-Safari, or all-Chrome browser “ecosystem”, right? (Though unfortunately we are not far from the latter). That’s what Xserver gave practically.
[1] There is some compatibility but let’s forget about that for now.
I think this is the point, but maybe in the opposite way you mean: X was the wrong architecture for what we want to achieve with a display system these days.
Some of that is about security, some of that is about which piece knows about what is responsible for what to make the system work. Wayland changes the responsibilities significantly. This is a GOOD thing - it's why things like HiDPI can be made to work in Wayland and fundamentally don't in X (unless you control a lot of variables very carefully).
They don't have the financial backing that Gnome does, but doesn't accept itself as a smaller project.
Such as having a modern wide gamut/HDR display, or a display without a blue spectrum spike. Or printing anything in color. Or doing photography or digital painting. Or switching to another compositor on a non-default keyboard layout (as Wayland doesn't have the replacement for this basic X functionality, compositors are forced to reinvent the wheel).
It's fine to have the "works on my machine" attitude for a user discussing this on the web. I just hope the devs of what is being pushed as a replacement for what works don't have it. (and the signals aren't good)
The people "pushing" Wayland are the people who previously worked on X. They stopped because it's ancient, broken and untenable.
> However broken the past was, replacing it with something that is similarly broken but in different non-overlapping ways is not the proper way forward.
That "opinion" is well founded. Most people don't care about network transparency (to pick one example), and those that do can club together and keep X alive. Or write an extension for Wayland. Open source is easy in that it gives you many chances and ways to contribute!
Personally, I'd prefer those "LOOK IT'S MY DESKTOP OVER THE INTERNET" people kept their weirdness out of my compositor, but that's just my take.
- Screenshots and sharing the screen;
- Global hotkeys;
- Alternative / switchable / tunable keyboard layouts and input methods. Not fancy stuff, just, say, typing Latin, Cyrillic, Greek, and Japanese characters.
All these things are is some sort of disarray under Wayland currently. Once they are properly implemented, I may consider switching.
I want Wayland to succeed. But it's not entirely there yet.
Works for years.
And global hotkeys are not trivial - no, that “everything listens to everything” that X did is not a proper solution.
I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
Also do keep in mind this is about more than global hotkeys; there are several accessibility paradigms that simply don't and can't work on Wayland.
It never worked "fine", it was always a failure from security and usability perspective.
> I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
You know that apps have security vulnerabilities that can be exploited over the network? Screen grabbing, keyloggers, input injection(you have open root terminal? let's type some commands there). And more.
Do you personally audit the source code to every piece of software you run on your computer? Do you have the expertise necessary to even do that if you wanted to?
FOSS isn't magically immune to security exploits. Everything we build should assume any other software it interfaces with might be defective or even hostile.
No more than Wayland users have audited the process protection code.
I was illustrating why Wayland's security paradigm is important. It doesn't assume all the apps it renders are safe. It can still (and probably does) have security holes, but it is already starting from a much more secure foundation than X11 ever had any hope of having.
Similarly, my web browser probably has not publicly known exploits that I haven't bothered to discover myself, but that doesn't mean I should be OK with using a browser that doesn't sandbox its javascript engine.
A malicious PDF file is enough to break havoc with a simple memory bug, so unless you claim that open source is also bug-free, or that you don’t use any external data (but visiting this site already invalidates that assumption), then you are just being naive.
There is nothing inherent that couldn’t work with Wayland - there is nothing preventing the relevant teams agreeing on a new interface to broadcast accessibility information to the wayland server, that can thus share that with specific accessibility software (which is explicitly permitted to do it).
Ideally, what you want, is for the client expose a set of (described) actions, with suggested key bindings. Users can then enable / disable / change the bindings in some central place, which would also take care about collisions, reserved global keybinding or reserved local keybinding (key shortcuts, that are always supposed to be available to the focused app).
Here's a screenshot I just took on my plasma / wayland desktop.
Here's a screenshot of me sharing a window in firefox:
> Global hotkeys
I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
> Alternative / switchable / tunable keyboard layouts and input methods. Not fancy stuff, just, say, typing Latin, Cyrillic, Greek, and Japanese characters.
I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
> All these things are is some sort of disarray under Wayland currently
This all basically worked out of the box. I'm really not seeing where this disarray is. Have you actually used wayland, or are you regurgitating taking points from 5 years ago?
You forgot to mention that it doesn't work without portals and Pipewire dependency, and portals have to be implemented individually for each DE.
> I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
Because the KDE developers went to a lot of effort to make it work. That doesn't mean it will work well in other DEs and that is Wayland's problem.
If the maintainers of the DEs are happy with the effort, then I don't see a problem? (unless you're a DE maintainer, in which case - fair enough).
[1] When I first wrote this sentence I wrote "X is hard to implement" using X as a metasyntactic variable before I realised that was incredibly confusing in context!
- that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...).
- that it can be delegated to 3rd parties or implemented later when the time comes.
Neither of that is true. Color management is just another word for correct rendering of everything that comes through your stuff. Every pixel must have a well defined path from the physical input to the application to the physical output, you can't just implement a part of it and move everything else out of scope. To display anything in HDR, you have to build your entire pipeline around color management from the ground up.
The reason you are ignoring it is that you're using an sRGB display, in any other case it would be immediately apparent to you. sRGB also needs color management but everything assumes sRGB so you're able to mostly get away with it. This no longer holds in the modern hardware. You need a properly managed pipeline for gaming, movies, web, YouTube, GUI, smartphone family photos, and basically everything else.
Wayland developers actually found it the hard way, and are trying to implement it for, what, 3 years? That this wasn't a feature of a display server protocol from the start is a massive design flaw.
Same with the input methods handling being forced to be lumped up together in the downstream software, without at least specifying how it should be done. They took a well understood problem, and moved it out of scope; it might not have been an issue, but the lack of a spec will lead to fragmentation and less options. This affects most of the userbase, not "weirdos with remote desktops".
Should colour management be in Wayland? Sure. Could it have been designed better to cater for it? Absolutely. Wayland's got its warts, sure. But for most people it's good enough, and that's what matters in software. It'll get fixed, and the more people who care about it actually contribute, the faster it'll get fixed. Open source is amazing!
Color management is need for full HDR support, it uses Wide Color Gamut instead of sRGB
For some people, Wayland isn't there yet. For a whole lot of other people, Wayland is already better than X. Are distro developers supposed to ignore that and keep pushing X, despite it being the worse option for most of their users? Isn't it enough to provide X as an option for people who need something Wayland doesn't do yet?
Plus, Wayland is getting better, X isn't.
Maybe. I just hope the transition is more smooth, and the wayland fanboi don't try to belittle X users.
There you go again with your mythical screen tearing that I've never seen.
You should learn to enable V-Sync in your compositor or in xorg.conf (the option is called Tearfree in Mesa).
> the screen locker doesn't even engage if you have a context menu open
For some reason, it worked for me.
sleep 5 && xflock4
then I open the context menu and wait 5 seconds. After 5 seconds the screen locks successfully.
> vital things like compositing are hacked on in janky ways
Bullshit. Compositing in Xorg is done properly and it's not mandatory in cases where it's not needed. Besides, the compositor in Xorg can be changed to any other compositor regardless of the window manager (exceptions - compiz).
> For some people, Wayland isn't there yet.
Essentially all people who use their computer for more than just a Google Chrome launcher.
> Are distro developers supposed to ignore that and keep pushing X, despite it being the worse option for most of their users?
The only thing that works in all use-cases is Xorg.
> Isn't it enough to provide X as an option for people who need something Wayland doesn't do yet?
Thank you, but no.
> Plus, Wayland is getting better, X isn't.
No, it's not improving. It's adding more crutches, we haven't seen such crutches even in Xorg.
I'm happy for you that you get a tear-free X11 desktop. A quick Google search should make it obvious that I'm not the only person who experiences tearing with X though.
I don't know the details of your system, but the screen locker issue seems to definitely affect xfce4-screensaver; this issue is still open: https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/75. And just for fun, here's the same bug for Ubuntu (just for a different screen locker): https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/..., still open. Maybe try to follow the reproduction steps listed in those two issues and see if you're affected or if your system is magically immune. Maybe inform those projects that the issue is fixed?
Finally:
> The only thing that works in all use-cases is Xorg.
Xorg doesn't work for my use case. I have multiple monitors of different refresh rates and different DPI settings and I demand a tear-free desktop, Wayland is the only option which works for that use case.
Not sure that anybody who "has a problem" has stepped up to really do much about it (most X development in the past few years is to support Xwayland), so it can't be that much of a problem.
Did you reply to the wrong comment? How does this address what I wrote?
> If I had to guess I would guess that when Linux distro grow tired of the new shiny they will switch to a port of Xenocara for their display systems.
Linux distros are not going back to Xorg. Xenocara is basically just that adapted to OpenBSD, but all the Xorg developers remaining pretty much work for Linux distros so if they did go back they would just switch to what they already package and ship today.
There never going to fully "leave" Xorg (Debian still ships token ring software FFS so the idea that they'll stop shipping X is just a weird fantasy some people have for some reason) so in that sense they won't "go back". Void is already working on packaging Xenocara and I doubt they'll be the last one; OpenBSD will just become the team that provides both a display server and a secure remote shell for lots of the Linux ecosystem.
Obviously we're talking about using it as the default display server, and to that end they are and will. X will stay around for compatibility for quite a while of course.
> so in that sense they won't "go back".
No, so they won't switch to some other Xorg system, they'll just keep using what they have.
> Void is already working on packaging Xenocara and I doubt they'll be the last one; OpenBSD will just become the team that provides both a display server and a secure remote shell for lots of the Linux ecosystem.
I'm not sure about every last esoteric Linux distro, but the big ones. To that end, they are the ones actually paying people to develop Xorg and have been for many years. I don't see why they would move to something else even if they did go back to X, which they won't.
Feel free to set up a fund and sponsor X11 maintenance - there is surely a price where people will start working on it.
Most Linux graphics development is not unpaid.
As if it ever worked properly on X. I’m sure every professional used linux for tasks requiring color accuracy.
The problem is that it's "works on my machine" on both sides of the debate. Elsewhere in the comments is someone saying that they've never seen screen tearing and have perfectly good HiDPI on X.
I will make one statistical argument - Fedora is Wayland-by-default now. Plenty of people still use Fedora and have no problems.
Factually false, and easily known. Starting with most distros defaulting to wayland, Myself using it full time with zoom, screenshots I'm sure many things you say don't work
> far software developers have fallen in the last 30 years.
You can't be serious
> They have thrown everything difficult out of the spec and only implemented the most trivial functionality around a security model which you must actively break to get actual work (like screen shots) done.
You must really hate HTTP as spec. HTTP is so lazy. Could not even implement transport security or even TCP like functionality. Composability and layers are quite overrated
But I guess I should just not feed the troll
So if X is so great, why exactly have the very developers who worked on it all switched to Wayland? Like, if they could made something you believe is good, shouldn’t you trust their expertise in this also?
> security model which you must actively break to get actual work
That’s literally how security models should work: you put tiny holes into a solid block. You can’t plug a swiss cheese’s holes after the fact.
> That Wayland is 10 years old and still barely usable
What exactly is your thought process here, what kind of process could change such an inherent protocol in a bazaar style ecosystem faster? It’s not apple who can just say “we are using this protocol from next year. If you wanna work, port your software”. Even if something is so much more superior than the status quo, it would need a huge amount of time to spread. Also the first 5 years of Wayland was very different from the last 5 - and it has definitely reached critical mass in the latter 5. A year now may easily introduce more progress than 5 at the beginning, from the cumulative effect of more contributors, more testers, etc.
And that barely usable part is pure bullshit again — how else would it be the default protocol for plenty distros already?
Because some developers love greenfield projects. See https://news.ycombinator.com/item?id=36642796
> And that barely usable part is pure bullshit again — how else would it be the default protocol for plenty distros already?
A default that broke half of the programs I use. Thank you.
To be fair, lots of progress in the past two years. It went from 90% broken to 50% broken..
Believe me, they would have been more then happy to pop into existence a 100% backwards compatible change, but that is impossible.
I'm currently streaming X11 over my LAN which is something I can't do with Wayland. Give me a fucking solution instead of telling me I'm doing it wrong.
Yes, I'm tired of seeing all this bullshit, too. I'll switch immediately when Wayland gives me want I need to make me productive. Until then, I'm absolutely sick of this cocky attitude.
Waypipe is the solution.
Compare: https://access.redhat.com/documentation/eses/red_hat_enterpr....
With: https://access.redhat.com/documentation/eses/red_hat_enterpr...
Waypipe is the solution.
Compare: https://access.redhat.com/documentation/eses/red_hat_enterpr....
With: https://access.redhat.com/documentation/eses/red_hat_enterpr...
You can. It'll use XWayland. I'm assuming you are speaking about ssh -X or its friends. It's transparent for you, you don't have to configure anything for this. Yes, it's still using X for this use case, but I don't see how it is a Wayland issue. The protocol that talks with your hardware / local graphic stack does not have to be the same as the one talking on the network. The problematic thing is that it has X11 limitations like not changing the DPI of the window when moving it across screens, but that's also true on a X11 session.
I'm still using X11 but I'm close to switching to Wayland, KDE on Wayland has improved a lot recently.
"Don't feed egregious comments by replying; flag them instead." (a.k.a. please don't feed the trolls)
...we'd appreciate it.
It’s a never ending source of amusement for me. If what you do is broken, just go see your OS provider and ask them to fix it. Why do you even care about how things are working under the hood and how developers chose to spend their time?
Also they may have bent software to their liking and when you change something so important as the way images are rendered, then their particular workflow can go haywire.
I was in the community for less change (wayland, systemd, etc.) however now I tend to agree with you, I don't really care if I can still send emails, watch my DVDs and play some games.
But they really don't. They might have familiarized at one point of time, but that snapshot is not where the world is at now. They cannot really expect that the world around them will stop developing, so their know-how and hacks stay current.
It is still this, all over again: https://www.youtube.com/watch?v=ZTdUmlGxVo0. 12 years later and we still argue in circles.
Maybe we have different experiences. I am not working in a computer related industry so the people I know who use Linux are the only one following tech news, self hosting services, etc. So in my experience they are more familiar with their software. But my point of view is necessarily incomplete.
What I wanted to say was that people who do not know enough to be able to not run in circle, do it because they feel attached to them after becoming familiar with them after so many hours learning their paradigms, their inner workings, etc.
Again, it may be my incomplete POV but I have never seen any Windows user look at source code to try to understand a particular function to adapt the software to their workflow. I've seen numerous Linux users do this.
It exists, but in smaller numbers than you'd hope for.
Eg, Slashdot is full of greybeards who apparently believe computing peaked in the 90s, learned next to nothing since, and as a result can't understand why systemd does what it does.
I don't mean they disagree on the technical merits, but like they're confused as to why would a Linux system needs functionality that caters to a modern desktop laptop user, and it's not enough to have what was required in a server room in the 90s.
lmao this is basically every discussion about wayland, systemd, the gpl, red hat, you name it. People feel the need to argue about things especially in the linux/foss world. reddit, hacker news, et al would have far less traffic if people didn't want to argue about display servers or init systems.
I'm not a Windows user, but macOS behaves the same way. If an application wants to capture the screen, you need to give it explicit permission to do so.
Absolutely no content worth commenting on, but guaranteed to start a holy war type argument on a thread that should be about some guy's hobby project about a thing he likes and does in his spare time.
Truly - Well done sir. Class act.
At least on Linux, Xorg and Wayland compositors use the same underlying APIs, so the chances of Xorg not running somewhere Wayland runs are pretty much zero - unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it and/or to write a new Xorg driver for the new API.
And this is actually really unlikely for Wayland, isn't it? The whole idea is that each desktop environment implements its own display server using the modesetting API. That's why there's all kinds of drama about Nvidia "not supporting Wayland"; their kernel driver exposes some nonstandard APIs, and they can patch Xorg to support those APIs, but they can't patch every Wayland compositor in the world.
I guess Xorg could hit bugs in the modesetting driver that the most popular Wayland compositors don't hit. IIRC that was an issue for Asahi Linux's Apple M1 video driver.
Xorg is open source and drivers can be fixed as long as there are enough people to notice and care. Worst case you can run an X root window on top of Wayland compositor and pretend the latter is just a graphics driver :-P.
Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasingly simply not bothering to go out of their way with X if something isn't possible to implement over it. So X use case is going to further deteriorate, that's inevitable.
What exactly do you refer to? Note that i meant the kernel APIs to drive the hardware as what i replied to was Xorg not keeping up with newer hardware, not toolkits.
What you describe is a minor annoyance at most, not at all on the same level as being unable to use X because of newer hardware. Even if it isn't fixed, one can still be worked around or just ignored, but the other just makes the whole thing literally unusable.
And X won't have parity for hardware features anyway. Like HDR - it will be Wayland only. And so on and so forth. So X is fried on all ends in the long term.
It's not that it's not possible to use kernel interfaces - it's just no one will bother putting an effort in developing X. It's already happening.
Same goes for other similar use cases that aren't tied to Wayland protocols, but are critical for Wayland compositors to function and before used to be handled by Xorg in some unified fashion.
My (shallow and likely out-of-date) impression was that wlroots the library baking in Linux things was a more serious problem for porting than Wayland the protocol actually mandating anything seriously Linux-specific (I understand how the choice to use Linux key codes might be annoying, but still, meh). Have they gotten around to excising the event loop library out of there, for example?
This could finally let me dive into the only BSD that really catches my attention for potential to switch over - I applaud this effort!
There is significant overlap between former X11 developers and Wayland developers. They didn't drop it because they are incompetent which seems to be what your are implying. The people that decided to drop it are probably the people that know X11 the best.
It started working poorly when X clients started rendering everything locally in the client and simply pushing pixels to the display server.
Which means it works poorly for modern apps. Modern apps use the GPU for client-side rendering.
And it absolutely worked poorly even in the 90s. It was virtually impossible to run X apps over anything but a fast local LAN. That's what "Broadway"/LBX was about. It was kind of a failure.
RDP has been a better networked display protocol than X for a couple decades now. Let's not fool ourselves that X isn't obsolete on every axis.
I'm not sure who you're replying to here, because it certainly isn't me.
Well in my experience, running X11 applications using network transparency works perfectly fine. It can be a life saver when your server is a proprietary UNIX, these are still in many Fortune 500 companies.
I have/still use network transparency as: Linux/BSDs <-> BSDs/Linux and Linux <-> AIX.
I even ran a few (Xlib/Motif) applications as "Linux <-> Linux <-> AIX" where the middle Linux was a pass through server without any issues.
So, No issues with network transparency, that is why I will avoid Wayland as long as I can.
To the article, Wayland on OpenBSD looks like a very extremely project, wish you luck.
It might be useful to be able to run Wayland applications remotely.
But this will be a useful stopgap for those who stubbornly cling to X11 (or are forced to, e.g. by NVIDIA hardware) as more and more useful software drops X support and goes Wayland-only.
I can't think of any such case, any example?
Besides even if X support is dropped by an application, 12to11 - or any other Wayland implementation that runs under X - will keep it working. It isn't like most programs use X directly anyway.
GTK5 might be more of an issue but so far programs barely use GTK4, let alone 5. I'm not sure GNOME applications are used much outside of GNOME. In either case i'd expect something 12to11 to work with those by then (if it doesn't already).
And TBH i'd expect there will be X compatible programs for a very long time to come.
X has to do that with DRI and client side rendering too, doesn't it?
> As long as Wayland doesn't deliver a remote rendering protocol, the best path forward seems to be shipping Javascript apps to a browser on the end user's machine (where his GPU will be available).
Why does that seem like the best path forward? Seems crazy. For incidental things, admin, etc., software rendering would be fine. The right path forward for a high performance application that needs to ship data to a client that can render it would be to transfer that data, not the drawing of it.
1. Well I assert that it was not an architectural mistake. So that doesn't really move the conversation. 2. Whether or not it was a mistake, does not change how things are. So you can't really use that as a point against Wayland for X.
> and Wayland wants to cement that. That’s why we see so many webapps where we would have expected remote windows driven by a backend server; Javascript became the GPU-local end of a lot of opaque rendering protocols to fill the gap.
Client side has been driven overwhelmingly by Windows in the past decades though, so I don't see how that is the reason. The number of javascript apps caused by DRI in X must be approximately zero, and caused by Wayland exactly zero.
I imagine a man surrounded by the X11 books (which is how O'Reilly got it's start) strewn around a messy desk, 2 large monitors and a small desktop system beside them. On the floor, a Sun Enterprise E450 in its deskside enclosure.
In my experience, when combined with SSH compression (ssh -XC) it works well enough that even running Firefox over Internet is usable (although with noticeable latency). Without compression, it is unusable (for Firefox) even on gigabit LAN.
Back when X11 was gaining traction the LAN was 10mbps and WAN was 1.5mbps.
Now people have true 1Gbit connections to the WAN and can easily have 10gbit or much more on the LAN...
The last time I had it working well was in 2005 using a full desktop session across a local network. The bit about only getting the one application across has always been a bit wonky. That's not to say that you can't do it, but it's not really a daily driver sort of thing.
And no, I don't think the developers are incompetent, they obviously have different priorities than I do. Being able to shift an entire desktop environment over a network is something I've done since I started using the internet in various ways and I'll echo the sentiment that it seems incredibly useless to remove this feature in today's world.
To be quite honest I'm tired of this holier-than-though attitude. They dropped it because they are lazy or just don't want to support it and they should just be honest about that. They certainly didn't do it because it makes my life easier and I wish they would stop telling me I'm in the wrong.
I don't know the incentives are there for a conspiracy in this case.
You still have ssh -X functionality just fine without any network transparency required, e.g. waypipe or rdp (e.g. builtin on gnome) or vnc, .... Of course that is not going away.
So very few new things that require remote operation in the past 20 years should have baked in the requirement for a networked GUI.
RDP works great in LAN (win-win win-linux) and ok over DSL.
Plain ssh/X11 over DSL is a disaster but may be passable on a LAN.
RDP is the better protocol here and pipewire mimics it (I think) which is the correct thing to do. X11 was designed for throughput and not latency and that kills any desktop interactivity.
As somebody that my job depends on it I don't worry too much about the future of display networking. I think we would be ok at the end.
It seems like so much stuff is broken but the devs deny it is broken? And even with that situation - every major distro is making in roads to adopting it?
Is that a fair characterisation or am I off the mark?
So I put wayland is broken, because it doesn't allow what x11 did in the same way, ideally stomping on the others into the same category. For screenshots and capture, there's an API now (controlled, user is in the control, cannot be done behind his back. Scoped also, with granularity from window to desktop). For global shortcuts, there's an API in the making.
This is kind of the problem, though. X11's model of 'everything can access everything' is obviously bad, but when wayland went with a more restrictive model they didn't provide a means for legitimate functionality like this. That's basically the origin of all the objection: things that worked on X11 don't work on wayland, because wayland's developers seem to be very slow to recognise and provide for things which were extremely common on X11. It's been 14 years and the API for global shortcuts is still in the making!
(And I know there's DE-specific interfaces for a lot of these things. But when you tell app developers this they're either going to implement it for their DE or not bother to implement it at all, as opposed to going through each DE and working it out, especially if it's more complex to support granular permissions and so on. So then users will see that app functionality breaks on wayland, and blame wayland, somewhat fairly)
On the other hand, Rome wasn't built in a day either. You want to do it right, not quickly. The final solution will be there for decades, so it better be not drag on maintenance and further development. Especially one, where the requirements are not so clear (no, register random key combo by random client isn't going to be it).
When you add memory protection to a system you don't just say "you cannot have process communicate", you give them the tool to do it in a safe way.
> You want to do it right, not quickly.
You want to do it right in reasonable time, otherwise by the time it is done it is obsolete. Given the time it took to add basic functionality, I would say that the design is not a good one.
In particular I suspect that the unstated premise was that everybody would be using Gnome by now, so that offloading to Gnome all of that functionality was a smart idea. Unfortunately people stubbornly continue to use the software that they like, so now we are in this situation.
> The final solution will be there for decades
There is no final solution, in 40 years the needs will be quite different that those of today, so it is not easy to satisfy both. You need an architecture that can evolve with the needs.
Remember the excel effect: each feature which was previously implemented by snooping and injection may only have a small number of users, but there are many of them and most users will use at least one of them. If you want to replace a system and not have users hate you, you need to implement all the little fiddly bits as well: my personal example is krita, which is not supporting wayland until it has support for tablets and qt has support for that, as well as color management (these aren't even things which were insecure on X11!). So for the forseeable future an app I'm unwilling to abandon is not even looking to start with wayland support until wayland has sorted itself out, and then it looks like it'll take them a few years to actually deal with it. And so it grates when I hear 'why is anyone still on X11?'
We see also arguing that something is missing, while it was there for years (like screenshots and capture), or nitpicking on global shortcuts. Global shortcuts are so incredibly long tail feature, so pointing it out is actually a a good thing. It means that Wayland is already here and nobody can find anything better or more important to point out (if it were up to me, I would agree with you on color management, but that is something that X never really had).
App support is something entirely different; apps like Krita can run under Xwayland just fine and transition on their own schedule.
It's neither bad nor good. That's the default. All the "no security" cries are nothing more than whining (not a single person has been harmed in 20 years). If security features were so necessary, people would have been implementing them a long time ago - https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv....
> but when wayland went with a more restrictive model they didn't provide a means for legitimate functionality like this
Furthermore, this model is embedded in the core architecture and cannot be fixed except by crutches.
The question then becomes whether you believe every major distro is part of some giant conspiracy to kill X despite them being in competition with each other and having incentives to keep supporting X if users want it, or if X may indeed have severe problems that Wayland fixes.
In practice most things run absolutely fine under both Wayland and X, but some programs integrated tightly with X back in the day and for various reasons they cannot be rewritten because the devs have moved on, died, or simply because there is no budget for it. Users of those programs are quite upset that the X developers have collectively decided that putting extra effort in X is no longer worth it because its problems are effectively unfixable.
For using it, you can try
nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-netbsd.libcpuid
nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-freebsd.libcpuid
It seems even in BSD-land, people are thinking seriously about moving on from X.
Netcraft sure as hell confirms it now: X11 is dying.