Curious from people who follow its development closely.
- What protocol are about to be finally implemented?
- Which ones are still a struggle?
- How many serious protocols are there missing?
please don’t post that site. I just need a few more things to work well with Wayland like Nvidia Drivers.
Last updated: 31 October 2022<
Five years on wayland here, it’s been great as long you don’t have single Nvidia gpu or need https://xkcd.com/1172/ kinds of x11 features
Just waiting on kde 6.1 for remote input so input leap can work
XFCE doesn’t support it yet so I’m not on it.
Also last I tried, autoclickers weren’t working
I haven’t tried it but the website lists ydotool as an alternative.
Lol XFCE. If your reference is a bunch of software thats sole purpose is to be “traditional”, stable and not change, then well.
Btw LXQt will have complete Wayland support soon.
For anybody else following along, XFCE is working on Wayland support. In fact, the only component not already supporting Wayland in Git is XFWM4 itself. Wayland will ship officially as part of the 4.20 release.
They are creating an abstraction library that will allow XFCE to support both X and Wayland. Other desktop environments are going to use it as well.
XFCE is my preferred DE when I’m using one. It’s got a long lineage going back to FVWM and the setup remains consistent between new updates. I appreciate how it stays out of the way.
I just want my steam link to work on KDE Wayland.
I just get a black screen with a mouse that I can’t move with a connected steam controller
sunshine/moonlight works for me, even though steam link crashes after 10s
Ah, for me moonlight just “searching for connected computers” forever with no controller buttons working at all and no ability to cancel it to put in the IP of the sunshine PC.
Moonlight on my phone works fine though, moonlight on steam link seems to just have a problem.
That site’s great.
The main thing I wish for is for ffmpeg to start supporting the wlroots screengrabbing api.
I truly believe the answer to this question is going to be yes around the May - June timeframe when Nvidia releases their explicit sync enabled drivers. All aboard the Wayland hype train babyyyy!
Nah. Wayland is buggy as hell on AMD too. That’s not the only issue.
Hadn’t had a single issue on my AMD igpu. If you experience issues it’s most likely coming from a different source than Wayland itself, it might be worth tracking it down and reporting the issue, so it can be fixed in the future.
Already daily driving it on my laptop, which uses AMD graphics, and my work laptop, which uses Intel graphics. For Nvidia, there’s missing explicit sync (which should be fixed soon), and Steam completely freaking out (might get fixed by explicit sync). Kwin also seems a bit unstable on Nvidia, but I haven’t tested it for extended periods of time.
I also have a computer with display on an Nvidia card via reverse prime, which suffers performance issues on Wayland. Might be improved on Plasma 6, but that computer runs OpenSUSE Leap, so it won’t get that for some time.
There is also the issue of picture-in-picture, but that can be worked around with Kwin rules.
No problems running on the AMD graphics?
Slightly OT but hasn’t Fedora gone all in on Wayland? Maybe it’s an attempt drive critical mass of adoption and concentrate developers’ minds to closing the gap between now and fully production ready. As such, maybe moving to Fedora will net you the best support and smoothest Wayland implantation.
No, Workstation is still supporting XOrg and there just is a change proposal for to drop Xorg on Workstation 41.
The KDE Spin and the Atomic KDE Variant have no wayland anymore, but there is a COPR repo and you can enable that and reinstall the packages.
You mean the KDE spin and Atomic KDE variant have no X11 anymore?
Yes
I’m happy with Wayland
I can’t run xscreensaver in wayland :(
The real problem right here
Wake me up when there’s a working, native non-wsl waypipe client with sound for windows and android, that can hand off applications seamlessly to other hosts. (Think two computers, two monitors that feel like one).
Also working screensaver and monitor power options
Also working screensaver and monitor power options
?
My first experience in wayland, us discovering I couldn’t control monitor sleep/standby function. I found how to reinstall X and managed to escape it since.
I dont know what that means. Normally the monitor turns off when the PC stops sending a signal. In KDE i can easily configure when to dim, turn off, lock etc. the screen.
I needed to do that from the console, xset didn’t work. As far as I could tell there was no other command.
What did you want to do?
A command to place the monitor in standby mode
What does this mean? Like unplugging without unplugging? Keeping one screen active and only turning off the other one?
I mean in the KDE monitor options I can choose [mirror,extend to left,extend to right,only external,only internal] so this is 100% possible.
That sounds like problem with specific software configuration, like missing packages in some distro or something being badly built. There’s nothing about Wayland that would prevent it from working.
Tried xset, not compatible. Tried searching equivalent command, there was none. That was in 2022.
Wayland is not a standalone server like Xorg and it doesn’t have standard utilities to control stuff like DPMS. That functionality goes to compositors that are effectively individual Wayland server implementations. Compositors can provide utilities to control display, and they usually do. For example, on KDE Wayland you can call
kscreen-doctor --dpms off, wlroots compositors (Sway, Wayfire, Hyprland,…) have inter-compatible tools, likeswaymsg output DP-1 dpms off. If that’s what you meant anyway.
I use an accessibility tool called Talon Voice. It is x.org only. Will the shift to Wayland kill these tools, or is it a case of the developer needing to rewrite for wayland?
On X11 apps can scan and read what they want. This is not even very good, but developers dont need to implement accessibility really, just make all text scannable.
If this is a screenreader you are talking about.
Apps need to send the reader specific texts that shouls be read, like push notifications. And this needs to be implemented, because on Wayland no app can just scan everything.
So rather than having one single app that deals with screen reading, it’s now down to every individual application to make accessibility a priority.
Huge retrograde step.
We can all agree that authors should all value accessibility, but we also all know that they won’t.
So because they won’t, those who need accessibility, will require x.org… forever?
GUI frameworks should implement this, just like any app built on GTK, Qt, Iced or possibly others have native wayland support.
But yes I agree this is not a good situation. There should be something like “accessibility permission” on Android, where apps can basically read anything.
That’s one of the huge problems with Wayland. The core protocol is super minimalistic so it falls to each and every individual app to (re)implement everything: accessibility, clipboard, keyboard, mouse, compositing etc. etc.
The fact this was done in the name of security is a solution looking for a problem. Inter-window communication was never a stringent security issue on Linux.
It’s like advising people to wear helmets in their everyday life. Sure, in theory it’s a great idea and would greatly benefit those who slip and fall, or a flower pot falls on their heads, or are in a car accident and so on. But in practice it would be a huge inconvenience 99.99% of the time.
The largest part of all Linux apps out there will never get around to (re)implementing all this basic functionality just to deal with a 0.01% chance of security issues. Wherever convenience fights security, convenience wins. Wayland will either come around or become a bubble where 99% of Linux userland doesn’t work.
it falls to each and every individual app to (re)implement everything: accessibility, clipboard, keyboard, mouse, compositing etc. etc.
I haven’t read so much nonsense packed in a single sentence in a while. No, apps don’t implement any of these things themselves. How the fuck would apps simultaneously “implement compositing themselves” and also neither have access to the “framebuffer” (which isn’t even the case on Xorg!) nor information about other windows on the screen?
Please, don’t rant about things you clearly don’t know anything about.
I still can’t stream screens via discord and my autoclicker relies on a lib that only works with X
It works fine with Firefox funnily enough
Discord would work if they ever updated their electron version.
Or just use it in a web browser. I don’t really want to run their proprietary spyware outside of a sandbox anyways.
deleted by creator
Or Vesktop, which is a client mod that allows streaming (even with audio)
The problem is it’s completely unwatchable. Streams are 2 fps no matter how low or high quality you set the stream :c
It enters a loop in discord and doesn’t work. There was a bug recently I was reading about it. Makes you go insane. All the other alternatives basically make you lose the krysp and auto microphone sound detection.
I’d love to find an alternative to xdotool’s auto type feature (or ClickPaste from Windows).
There is
wtypebut unfortunately it doesn’t work in KDE nor GNOME because neither of them support the right protocol. I’ve run into the “<DE> hasn’t implemented $PROTOCOL” a few times in the past and it’s certainly a bit annoying.Aside from when that comes up, I don’t really have any complaints. A tool we used for work was never going to be fully functional on Wayland because of its dependence on Xinerama (I think) but thankfully we’ve moved away from it.
I like ydotool, uses a systemd user service, but fulfills my needs of KB shortcuts to paste text into vnc sessions
