I know this is just a "hack it together" effort, but I wonder if it even makes sense to emulate/support libevdev and libinput on non-Linux OSes.
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.
I think this is about preparing for a post X11 future. As Wayland continues to mature, classic X will attract fewer developer resources. I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware.
> I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware.
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.
> unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it
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.
Might be unlikely but not impossible - after all if people cared about not breaking existing software Wayland itself wouldn't exist in the first place :-P
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.
> Xorg and Wayland compositors use the same underlying APIs
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.
> Not really. KWin has Wayland specific paths that simply don't work on X
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.
How does that have anything to do with X not keeping up with new hardware or using the same kernel APIs as Wayland for communicating with said hardware?
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.
That means that X case will become increasingly broken. It won't work and won't be supported, newer hardware or not.
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.
Not sure what your comment has to do with mine? I'm not debating whether or not X11 will stick around, or whether getting Wayland working on OpenBSD is a good idea or not. I was talking about the specific software dependency choices used for this rough port.
Wayland is a replacement for X11 in the same way that a tricycle is a replacement for a tractor.
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.
> They have thrown everything difficult out of the spec
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).
«
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.
»
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.
> If someone found a way to add variable DPI to Xinerama
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.
It is exposed reliably already, it is just that to get workable mixed mode HiDPI support (i.e. multiple monitors of different DPIs) you need the window manager and toolkits/applications to cooperate:
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 lay this out as a list of numbered bullet points, and it is great to see it enumerated like this, but I can only tell you that, as a non-programmer myself, I can barely follow a word of that, and have absolutely no idea what is needed from who and where in there.
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.
> and have absolutely no idea what is needed from who and where in there.
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.
> in order to get that in the X11 world you need several different people and projects to care to work together
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.
> 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.
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.)
> X11 also doesn't have all the features we'd like it to have, such as the ability to render frames without tearing
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.
I don't know what sort of magic you're doing. I haven't been able to get a proper tear free experience on X11 across a very wide range of hardware and distros and desktop environments/compositors.
I'm using the amdgpu driver with Window Maker, i didn't need to do anything special for it to work. FWIW variable refresh rate also works (my monitor has VRR support and displays the current refresh rate in an overlay), though it needs an option in xorg.conf to enable.
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 am actually using amdgpu myself but i mentioned the modesetting driver since that is new development to show that people actually still work on that stuff.
> I had this working with multiple X11 servers 20 years ago.
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).
Xinerama came with the price of not supporting mixed DPI. It was logically a single screen, just with irregular shape, so all screens had to be same DPI (and bit-depth, but that's not an issue nowadays).
Bit-depth is certainly an issue these days. I've got a 1920x1080 60Hz 8-bit/color 24" monitor and a 3840x2160 144Hz 10-bit/color 27" monitor. Different resolutions, refresh rates, color depths, sizes, and DPIs, on a very modern system.
honestly explain to me, if it's work as perfect as you seen to say, why i never heard about it outside of openbsd, why any distro adoped it to resolve it Xorg problems
> I had this working with multiple X11 servers 20 years ago.
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.
I love X11 dearly but I'm still happy using a single non-HiDPI screen because my normal working environment is basically 2x2 tiled 80x24 xterms (with multiple sets of them on different virtual screens) so the limitations just don't really affect me.
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 ;)
Thing is, my fvwm config might be short but my setup is (arguably rather more than) a bit esoteric (feel free to declare tl;dr but I may as well get an explanation of my requirements down so I can stuff it in a file somewhere for future reference):
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 :)
This is a better comment than your previous one, in which you just dismissed the project and the work people have been doing without touching on any key issues you might have with wayland.
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 use Wayland daily and haven't run into the issues you mention. It has worked better than X11 as a daily driver for a few years now. I appreciate may not work for some <1% of edge use cases but for most people Wayland works just fine. Things like screen tearing, issues with video acceleration, etc are all a thing of the past.
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.
> I use Wayland daily and haven't run into the issues you mention. I appreciate may not work for some <1% of edge use cases
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)
> 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.
If Wayland just existed on its own, nobody would have had a problem. The people pushing Wayland are not just its authors, but the distro devs, and the entire fuss is about Wayland being declared as the "future" by certain distro developers recently. This future has an issue - it only supports an opinionated subset of maybe 3/4 use cases of the "past". 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.
The problem is, X is terrible. It's janky as hell, screen tearing is everywhere unless you're running extremely particular driver + hardware + X configurations, the screen locker doesn't even engage if you have a context menu open, vital things like compositing are hacked on in janky ways.
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?
> It's janky as hell, screen tearing is everywhere unless you're running extremely particular driver + hardware + X configurations
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.
You don't strike me as a very serious participant in this conversation. "Wayland is not improving"? Spare me. If you have anything serious to say on that topic, you'll have to describe what differentiates a well-engineered solution and a crutch in your mind, and then explain why things like the proposed color management protocol or whatever else falls in the "crutch" category.
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.
I disagree. The distro devs are pushing it because it furthers their mission, which on the face of it (for a lot of them) seems to be "ship software that works for people and have them stop bugging us".
> 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.
This is a strawman. There's a reason I mentioned color management in particular. Most people who aren't aware (even software developers) tend to make two assumptions:
- 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".
The vast majority of linux desktop computer users are likely using sRGB displays to look at things in the sRGB colourspace.
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!
- 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.
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've moved the goalposts on this argument now. "$Thing is hard to implement on Wayland and requires quite a lot of effort by each DE"[1] is a very different argument to "$Thing doesn't work on Wayland". Pretty much everything you listed works well in Fedora with Gnome/Mutter.
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!
If something requires effort from each DE / compositor to implement, it's not "implemented in Wayland", but rather Wayland does not preclude it from being implemented.
It's worked fine for X for decades now, so simply claiming "it's not a solution" is kind of silly.
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's worked fine for X for decades now, so simply claiming "it's not a solution" is kind of silly.
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.
As I have said many times, a good intentioned program with a bug only needs bad intentioned data.
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).
> 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.
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.
You're not really addressing my argument here. Of course Wayland users don't audit the Wayland source 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.
It is more than event routing, you do not really want for any client to be able to claim any combination, without any further insight by either compositor or user.
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).
The existence of Wayland does nothing to detract from the existence of X or its users or developers. Nothing stops anybody from maintaining and developing X. You can download and install X for your Wayland distro.
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.
This is about OpenBSD, whose team continues to maintain and update Xenocara. 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.
> This is about OpenBSD, whose team continues to maintain and update Xenocara.
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.
> 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)
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.
> 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 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.
> 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.
As if it ever worked properly on X. I’m sure every professional used linux for tasks requiring color accuracy.
Your memory of config file nightmares (I had them too) is a decade old now. X11 works without config for the vast majority of users. Yes it took a while to get there, but it's been there for a good while now and not really anything for Wayland to point at as a differentiator.
Indeed, given it's often the same developers working on both, a reasonable amount of the effort put into getting X to work without needing configuration was people actually working on Wayland but also taking the time to pull X along for the ride where possible.
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.
> ... 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. ;)
I've been using Linux for 20 years now and I've never needed more than 5 lines of Xorg config, only a couple lines of which has had meaningful information.
I've been using Linux since Slackware 3.0; at the time, there were X servers that were specific to a certain card manufacturers/chipsets and you symlinked the correct one. Then you configured xf86config.
It was definitely a real problem. Things would work for a while and then break. Sometimes you had to choose between one thing that worked and another. I spent many unhappy hours tweaking X config.
But it was indeed around 20 years ago that it was an issue.
It's more like replacing an old calculator with a new shiny graphing one that can solve ODEs but the basic addition is declared "out of scope" so it doesn't have it. Well, now you need another calculator to add numbers built into your toaster, with every vendor implementing it differently.
But why is my window manager now also my display server? The (relatively simple) program that decides how to lay out my windows is clearly a separate concern to the (complex) program that actually interfaces with the GPU to render the screen
Having to worry if your WM supports your GPU is like having to worry if your web browser supports your NIC
Gnome is not your window manager - it’s your display server. You can trivially install/write an extension to manage your windows differently and reuse everything gnome provides for example.
A wm has always been trivial compared to a display manager, people just mistake one for the other.
Yes that's the point I'm making. It is now a display server. On X it was just a desktop environment. Traditionally that comprises
* 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)
The Firefox one might be a good analogy to continue: a window manager is akin to a web extension. They are browser-dependent, a firefox one won’t work on chrome, and vice versa [1]
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.
> Yes that's the point I'm making. It is now a display server. On X it was just a desktop environment.
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).
I still think having multiple display server implementation is a mistake.
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..
It’s not ideal, but what is the alternative? We couldn’t even agree about an implementation language, and there are many more decisions that are display-server specific.
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.
I totally agree. X11 is a tractor trying to be a supercar, a bus, an airplane, and a farm implement.
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.
> That Wayland is 10 years old and still barely usable
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
Yeah, please repeat the same bullshit for the umpteenth time. This happens under every goddamn wayland-related thread from people who have never ever touched anything graphics related with this typical cocky attitude - at this point this is just fake news.
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?
Please don't post in the flamewar style to HN. We've had to ask you this before. Instead, if you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules, including:
"Don't feed egregious comments by replying; flag them instead." (a.k.a. please don't feed the trolls)
in the comment session of that HW post there was a lot of people saying that they hate to create projects and prefer to maintaing code, if even the mainteiners don't want to work on it, just proves how complex it was
Half the programs you use? Are you OK with all of these programs having access to each other? Would using XWayland not solve the issue? The main issue I have with X programs in Wayland is that I use 4k and the scaling is off. But its still usable.
> Yeah, please repeat the same bullshit for the umpteenth time.
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.
> I can't do with Wayland. Give me a fucking solution
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.
Taking a screenshot isn't breaking the model, it's using a portal. It just means that instead of every application having complete access to everything on the display, you move the trust to the compositor.
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.
You refer to an old release model that was packing everything "X" into one thing. Nothing uses this release anymore.
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.
This has been a talking point since wayland was announced. No one is buying it. Wayland is a very clear successor to X11 and OSs are going to choose one or the other at the end of the day.
> OSs are going to choose one or the other at the end of the day.
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 someone explain to me why Linux users seem so interested about having this long heated discussion about very low level piece of the OS infrastructure they actually have no expertise about and don’t really care about in a direct way?
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?
I think it is because Linux users tend to be more familiar with their software than users of other OSes. They chose it and they configured them, sometimes for hours.
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.
> I think it is because Linux users tend to be more familiar with their software than users of other OSes.
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.
> 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.
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.
> 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.
>Can someone explain to me why Linux users seem so interested about having this long heated discussion about very low level piece of the OS infrastructure they actually have no expertise about and don’t really care about in a direct way?
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 love this comment. Arrogance, fear, entitlement, and ignorance rolled into a giant blob, salted with a touch of insult and nostalgia.
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.
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.
It's a matter of funding. X11 development is not funded anymore whereas Wayland is heavily funded through proxies like Collabora or Igalia. It is unclear who are the originators of that money since those proxy orgs don't disclose who funds them.
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.
> 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.
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).
> 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.
EEE was a conspiracy theory as well until the Heloween documents were published.
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.
Oh, can I also get some of that sweet Wayland money? I’m sure that sub-3% desktop users is such a good market. Seriously, these conteo people really have trouble with rational thought — a goddamn chrome extension would be a bigger market.
The money is paid for Wayland to make sure the FOSS desktop will stay sub-3%. You obviously don't understand the concept of sabotage. (And yes literally millions of dollars have been invested into Wayland)
I think standardizing on libinput is a big deal, even if it's not required for Wayland use case. Otherwise it would have become a constant reinvention of the wheel.
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.
> Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives.
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?
I've been wanting to give OpenBSD an honest shot on the desktop for years, but going back to X has always been a deal breaker for me (HiDPI and mixed/scaled DPI support, and tear-less graphics, are hard requirements that X handles horribly - yes, before the X apologists brigade me, I know because I used to hack X into horribly supporting these things).
This could finally let me dive into the only BSD that really catches my attention for potential to switch over - I applaud this effort!
OpenBSD is pretty sweet! been daily-driving as desktop OS (as in, not a server) for ~2 years now. Though, on a 1366x768 ThinkPad, so not too concerned about DPI hahah
I as a user haven't seen any reason to care about Wayland. And losing/dropping X11's network transparency seems rather surprising in a heavily networked world...
In my experience, running X11 over a network worked very poorly.
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.
>In my experience, running X11 over a network worked very poorly.
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.
I haven't tried it (because i do not really need network transparency and i'm using Xorg anyway) but supposedly this project[0] implements the Wayland protocol on top of Xorg in a way that integrates mostly seamlessly with X11-based desktops (instead of creating a window and running Wayland inside it as if it was a monitor isolated from the rest of the desktop).
It might be useful to be able to run Wayland applications remotely.
Waypipe can run Wayland applications remotely in a more modern fashion that doesn't suck ass on all but the fastest network links.
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.
> 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.
Well I believe there is foot. GTK devs ae planning to drop X11 support in gtk5 and they will start work on that after gnome 45 release so in a couple of years, all gnome apps
Foot was made with Wayland in mind and there are tons of alternative terminals anyway so i don't think its existence is going to inconvenience or even affect at all any Xorg users.
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.
Since GTK4, GTK is a dead framework. I don't even have it on my system. GNOME killed GTK, so I'm waiting for the community to finally fork GTK3 and make a compatibility layer for GTK2, because there are a lot of GTK2 applications.
Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU. 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).
> Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU.
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.
It was an architectural mistake to start bypassing GLX and depending on DRI at each app, 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.
> It was an architectural mistake to start bypassing GLX and depending on DRI at each app,
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.
> 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.
It has worked great for me for decades and I currently stream live video over X11 on my LAN.
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.
X11 over a network, even a LAN is a "last resort" kinda thing for me. It's neat an all, but as much as I dislike remote desktop and VNC, it's still better than X11.
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.
> In my experience, running X11 over a network worked very poorly.
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.
In my experience running Firefox over X11 remotely is fine as long as you only use X11 and don’t wrap it in SSH, i.e. instead you expose your local X11 server port to the computer running Firefox and use the DISPLAY environment variable to point it at you local X11 server. Secure the connection with Wireguard and it’s fine. With SSH I’d see frame tearing all the time, regardless of compression options.
x2go/freenx it's must better than the old X11 protocol. OFC, if you use legacy systems, no problems using your old Irix machine or similar, but from modern *BSD's/GNU's, you can compile x2go in a breeze and get a much better support on rendering/speed and detaching.
It worked well for me at my university in 1990. We had a large room full of 1024x1024 X terminals. We run our programs on some HP-UX shared server and displayed the pixels on those terminals over a 1 Mb/s LAN. No glitches.
The networking parts weren't used that much and due to the way modern apps work, I think the networked parts were essentially transferring images instead of graphics primitives. So it was essentially doing stuff that a remote desktop app does but with potentially more security issues (e.g. apps listening into keystrokes intended for other apps).
I keep seeing friends who run Wayland have embarrassing issues with global hotkeys, screen sharing, etc., and I'm running X11 with a default config and standard drivers without literally any issue. I too don't see the point in switching when I'd be switching from a fully functional system that has basically no issues (and yeah, I don't get where multi-DPI setup issues come from; I have multiple screens with different resolutions and no issues, one of them is at 2560x1440 and the others are just 1080p standard) to a system that by most accounts seem to have at the very least 2-3 issues that impact basic workday things.
Short comment: ssh -X is not what network transparency means.
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.
Network transparency at the GUI is not the way the "heavily networked world" is going though. In a lot of ways it doesn't scale. You want to administer and run things in a programmatic way, which means command line or an application specific protocol (which would have front-ends) so you can script and write tools for it and have that work over 1 or N machines.
So very few new things that require remote operation in the past 20 years should have baked in the requirement for a networked GUI.
This looks like sabotage from the Wayland-centric mesa developers who didn't add TearFree to the core xorg modesetting driver because the older one had this feature. Use V-Sync in the compositor.
Where is your pull request? Don't you think it is more likely that graphics software developers are just proposing the best software they can offer? Why would they deliberately push bad software? Wouldn't that make their product offering worse, and also make their own experiences worse and future development more difficult?
I don't know the incentives are there for a conspiracy in this case.
TearFree was only recently added to modesetting. But there's no release yet. In any case, the fact that it hasn't been in Xorg for so long looks like sabotage.
As a user who doesn't want to spend hours fiddling with config to make my PC work, Wayland is good for me. Plugging and unplugging monitors is now generally predictable correct in a way that it didn't used to be.
xpra saves the day when you have to go over a DSL line. If you have a direct LAN connection it may not absolutely required but it still helps.
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.
If you use the DRI2/3 extensions, or Xft fonts, and chances are you are, you don't benefit from X11's network transparency. Anyway, you can do forwarding with waypipe under wayland.
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?
It not broken. The complains on the linked gist remind me complaining, how introducing protected memory broke applications. And you couldn't read or write i/o ports directly in our app anymore, you had to go through so-called kernel! So much bloat!
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.
> 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)
> This is kind of the problem, though. X11's model of 'everything can access everything' is obviously bad,
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.
Things "worked" by the virtue of being able to snoop on everything and inject anything; which is exactly what is wrong about the approach.
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).
Snooping was just the mean, not the end. Nobody is asking to be able to do that, people ask to get the same result.
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.
Sure, but you can understand why people are not so keen on moving to an unfinished system, then? Or at least one which has not yet reached parity with its predecessor for a large proportion of its users.
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?'
It is never finished; there's always something missing. It took X almost 4 decades to get where it is and during the ride it was abandoned as a mess. It was never finished either.
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.
The "it's actually already there" effect is usually either one of two things: either poor communication, or poor rollout of actual support amongst apps. Both of those are hindered by a slow standardisation process. And I do wonder what makes you think global shortcuts are a long-tail feature: they're extremely commonly used! And app support is 100% key: it doesn't matter if wayland supports something if the apps don't actually use it!
Wayland never was intended to be drop-in replacement for X11, so it's not surprising that it isn't. It's a much smaller scoped, lower level building block, which pushes more responsibility to DEs. It's not just different implementation, it's new model where the hows, whats, and wheres of desktop are getting re-evaluated.
> every major distro is making in roads to adopting it?
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.
We've been doing some BSD cross work with Nixpkgs. A hope is that if we can extend that to NixOS too, and then it should be quite easy to checkpoint and share work like this for anyone to reproduce and pick up the baton on.
If OpenBSD manages to get Wayland working just the way they want it, with Pledge, Unveil, privileged separation and what have you, I would not be at all surprised if they also came up with their own compositor / window manager thing and a plan for removing X11 in future releases a few years later.
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.