If I remember, there was another display protocol being developed as an answer to Wayland for BSD. I don’t remember what it was called, but that project was basically about an open source MacOS.
I think the predecessors to RavynOS, it was called HelloSystem I think. In that project, they were talking about an alternative display server protocol.
Does Wayland allow for the running of a program on a big powerful server (where many users live) and display on a smaller desktop machine that is only providing a screen and keyboard? If not, are they working on that? If it does not and they are not working on it, is it even possible under the way that Wayland works?
Waypipe is not Wayland. Wayland does not natively support this workflow, which is why Waypipe was created. Please don’t confuse the two as being one thing.
You are giving me the impression that Waypipe is an extension to Wayland like XRANDR is to the X11 protocol. I didn’t get that impression from the blogpost. I’m not trying to place value on them being an extension or a separate tool. I’m just trying to figure out if it was a shortheaded response or if Waypipe is an extension to the Wayland protocol.
This may be “moving the goal posts”, if so I apologize in advance. With Waypipe can I have local windows and remote windows on my laptop? Will Waypipe work over a VPN (Tailscale is a VPN right?)
I used to be super excited about Wayland but it’s been 15 years, now I’m too old to care.
My favorite distro still runs on xorg and it runs so well that I don’t remember why we needed Wayland in the first place. (I am not saying that there is none)
Tearing videos and games have been fixed on xorg when Wayland was supposed to be the only solution.
I am sure Wayland will eventually make X completely obsolete and will be a much needed modernisation of the Linux desktop stack.
But I can’t help but notice that it is not there yet, is old enough to carry it’s own significant technical debt and might never bring the simplification and streamlining that it once promised.
It is a tiling Wayland compositor that is only a couple of megs in size. On Oasis Linux, I launched into Velox, opened a terminal, and checked the memory usage. It was under 30 MB of RAM. That is for the whole system!
That experience made me think differently about Wayland.
There was only one Xorg. For me, the evidence that it was big and complicated is best expressed by the fact that, over decades, the number of projects that competed to provide X had dwindled to one. There was loads of unhappiness with it and yet, there were no forks. Why?
Now Wayland. There are new Wayland compositors all the time now. I just saw one yesterday—Louvre. The basis for Velox above is SWC. There is Wayfire. There is Weston. There is of course wlroots. And both KDE and GNOME have made their own. I think somebody even wrote one for Haiku! For me, this is evidence in itself that making a Wayland compositor is easier than implementing X.
It also means that all these Wayland compositors can compete with each other and drive each other. It means that I, as the end user, can pick a super stripped down version when that is what I want and an all-singing, all-dancing version when that is what I want instead. In some situations I will be happy with, and thankful for, Velox and in other situations I will want GNOME.
It is taking a long time and the journey has not been smooth. That said, I am becoming quite confident that we are in a much better place. For normal uses, Wayland is in a good place now. The level of innovation is very high. Dev can start to shift from the basics to the extras. I fully expect that we are heading into an exciting time on the Linux desktop.
X has a singular fully functional implementation into which you can slot a wide variety of components. Because everything is a component that slots into the singular X implementation forking has both a low benefit and a high cost.
Wayland is just a protocol everyone must implement with a semi useless reference implementation that nobody would ever use. Nobody forks Wayland they just implement it as they must the X approach isn’t available.
It’s apples to oranges. A meaningless comparison. Its more just churn than innovation on the part of desktops.
That said, everything you said about the Xorg server could be said about wlroots. Nobody has to “implement Wayland because they must” anymore. The X approach is available in Wayland as you can build your window manager on top of wlroots and many do.
Seems fairly apples to apples to me.
Or you can choose a competing compositor library as there are now quite a few available. I think XFCE is looking at using Wayfire. Or you can control more of the stack directly and write your own as GNOME and KDE are doing.
Not only do you not have to implement Wayland to make a window manager, because compositor libraries are available, but people are writing Wayland compositors even though they do not have to. Louvre is a compositor recently released that seems expressly designed to make writing new window managers super easy.
As for innovation, there seems to be lots in Wayland. Valve just added HDR. GTK is looking at using dmabuf. There are already Wayland window managers that are not ports from X. There seems to be innovation at every level.
Building on top of wlroots is still a different scope of problem than writing a window manager for X. Pretending its the same thing doesn’t change the fundamentally different architecture even if it certainly makes it easier.
Out of all the libraries isn’t recent KDE the only fucking one that supports proper scaling of xwayland windows without turning it into a blurry mess? KDE which nice as it is lacks most of the nice tiling features of i3wm or the per monitor workspaces? Let me rip out and throw away a highly functional Nvidia GPU and come on down!
Don’t worry in another fucking 10 years all problems will be solved in the meanwhile I’ll just be fucking using non-beta software. Pardon me if I’m a little annoyed. Wayland has been the future for a while now.
Yeah, I don’t see a reason to use Wayland unless it’s a drop-in replacement for X.
I don’t have any issues with X. I’m glad it works and I don’t even know it’s there.
It doesn’t make sense for me to adopt something newer that works worse when I have something that works without issue right now.
I bet when Wayland reaches the maturity, adoption, and stability of X, people are going to be moving to the next broken thing that will be functional in 15+ years.
The same wayland bait is posted every week from new ban evading accounts which eventually also get banned.
They keep coming and getting shown the door, like Barney here.
Yea, don’t hesitate to report them.
Honestly, I literally couldn’t give a shit that anyone criticizes Wayland itself, but they’re a generally toxic user that’s easily recognizable by their constant hateboner for Wayland (among other things).
In the Networkmanager you can set that a connection is either available to all users or just yourself. If you set it to “all users” its configuration will be saved somewhere in /etc/Networkmanager (I’m too lazy to look up the real path) and will therefore be available for Networkmanager on boot. If you just make it available for yourself Networkmanager will only attempt to connect after you log in.
I think the default is to make it only available to yourself, because then you don’t have to enter your sudo password when you set it up or want to change something. The downside is of course what you describe in your post.
The only thing to boycott are GNOME dev’s mentality when it comes to things outside their DE (especially Wayland protocol adoption). It’s slowing Wayland development a lot
I agree. I am personally a fan of server side decorations. I use tiling Window managers which means I do not need to have extra buttons (browsers) or bars (looking at you, thunar) to close, minimise of fullscreen an app. Heck, one of the reasons to use a tiling wm is to maximise the usage of screen real estate and with these extra bars and buttons you’re taking some of that away!
They have no intention of sparing a thought for anything that isn’t gnome. It’s a shame considering their corporate funding and influence over the linux desktop.
Wayland xdg-shell Protocol is tailored only for GNOME needs.
What why is this a problem at all? For what’s worth GNOME is the only actually half designed and half usable thing out there. Yes they could add desktop icons and drop the “go into activities after boot” bullshit but how well, they’ve 1M€ in funding to reinvent the DE in all the unnecessary ways possible.
(And this comment is how you offend both the GNOME fans and haters at the same time. Probably also anyone else who cares about having alternatives.)
I often switch between Wayland and X. My only concern is java does not yet support Wayland and old native libraries (e.g. 3D stuff for no longer maintained Java games) will probably break, once Java actually switches. Java and some Java games work with the xwayland compatibility layer, for now, but there are glitches sometimes. There are multiple projects porting Java stuff (e.g. Swing) to Wayland. All unofficial and incomplete.
I think that’s only true for the programs, not for the JVM/JRE code. The JVM/JRE doesn’t support Wayland without the xwayland compatibility layer. Also, some games use “native” libs that do optimized 3D stuff. Those are special Java classes, not part of the JVM/JRE that interface with C libs, kernels, system calls and hardware directly. Some will stop working without an X window to connect to. Some are long forgotten and won’t be ported.
Yeah, I don’t know about Java. I often switch between X and Wayland myself, but I’m mostly on X because I use a tiling window manager (Qtile) which has a Wayland version but is still ironing out some issues before I can switch full time.
There are some hacky methods to make some Java software use Wayland. Iirc, github.com/openjdk/wakefield is the jvm version I used to test it on Minecraft and Mindustry. I did not really get that far, but it has been quite some time since I tested it so I do not remember exactly what the results were. Otherwise it is possible the subjected software itself needs extra editing to make it work on Wayland.
What they are talking about is that some of the Wayland compositors rely on things like libinput and libdrm which are Linux specific.
This is not “Wayland” really but, from the point of view of a regular user, it may as well be. As the OP points out, there is no /usr/bin/Wayland
It is not really a great criticism although it must be frustrating for the BSD folks and others. Of course, the answer like always is to contribute. Nothing stopping anybody from taking wlroots ( or whatever ) and adding abstractions that make it more portable.
Non-Linux operating systems have already added Wayland support ( like Haiku ). If I had the time, I would add it to SerenityOS myself.
Actually, if I had the time, I might write a WaylandServer for X. First, it would be funny. Second, the people that do not want to move could stay on X forever even when everything stops supporting it. I would have to make sure that my WaylandServer could run XWayland of course.
Yeah, I was going to ask if the Wayland protocol included some Linux-kernel-specific data structures or something that would make it somehow more awkward to implement on non-Linux kernels or something.
Like if I created a protocol that included sending data encoded using the Python serialization framework called “pickle”, one could say that was a Python-specific protocol in that while it would be possible to use that protocol from other languages, it would be very weird and awkward to do so at best.
Not really knowing much about the specifics of Wayland, I wouldn’t truly know if there could possibly be anything Linux-specific in Wayland. But as far as I know, it’s entirely possible theshatterstone54 knows something I don’t.
Wayland does not work properly on Intel hardware: Again, I’m using AMD, so I can’t confirm or deny this, but considering the Intel drivers are open source, and I’ve heard about many, many improvements made on the Intel side of things, I think it would be reasonable to assume it has been fixed.
Posting this from Plasma Wayland on Intel right now. If something is broken, it's something not apparent to me.
Dual monitor? Wayland on my intel works fine for single screen, but as soon as I plug in a 4k monitor, it gets black cube shadow like artifacts in KDE Plasma 5. A couple of kernel command line options for the module has not helped, either.
I'm fairly sure I have run this system dual-monitor though I don't do it routinely. I'll check sometime this weekend and let you know, if you are interested for comparison's sake.
Worked with no drama, for me at least. Hooked it to my TV because that was most convenient. USB-C to HDMI adapter, I just had to tell it where they were in relation to each other and set scaling on the TV. Fonts look a little screwy on that dialogue box, but only in the screenshot - and when composing this post I realized even there they look OK if I don't view that part of the screenshot on the 4K display.
Edit: No, untrue. I think I had the wrong glasses on. The fonts on the 1080p display are fine in reality, but the screenshot is distorting everything on that panel a bit. Again, screenshot only though. All good otherwise. I can't see any other problem after using it a bit like this though.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.