[mikkupikku]

That sort of solution is cancer if you want to do anything the display server authors didn't think of. I've got a script that I invoke with a global hotkey that determines the window title of the currently focused window and fuzzy matches it against pipewire audio stream names so I can mute the focused window with a single keypress. If I want that to work in Wayland I'm pretty much up shit creek because somebody with their head in the clouds thinks that my needs are super dangerous or something.

[ethin]

Wayland devs for the longest time thought implementing what was needed for accessibility (mainly, global keyboard hooks for Orca to work) was a security problem. Nevermind the fact that nobody hacks X servers, or your wayland compositor, because if I wanted to hook your keyboard with a keylogger, I'd hook it through evdev. And then you wouldn't even know let alone be able to do much about it if I did it properly.

[array_key_first]

Wayland doesn't say "this is impossible", it says "this is out of scope of the core display protocol, implement this somewhere else".

Which, well, we do. Practically all the X usecases are covered on Wayland systems now. Screen sharing, screen clipping, global hotkeys, file pickers, getting the window title like you said... I can do all of that on KDE, right now, under Wayland.

[mikkupikku]

Can you do it in a way that isn't KDE specific, and will work if you change your DE one day on a whim?

[tuna74]

If you change to another DE that has less capabilities than KDE, of course you can't do it. Emacs and LibreOffice Writer will have vastly different capabilities and people can choose what they want based on the capabilities they desire.

[ethin]

And that is exactly the problem. Now things like accessibility (or, really, any feature that the maintainers of the core protocol didn't think were "necessary" because they like minimalism) have to be implemented by each and every compositor. If the compositor doesn't implement it, your screwed unless either you convince them to add it or you add it yourself. Talk about causing huge amounts of fragmentation for absolutely no reason.

The proper thing Wayland should've done is waited until Wayland had reached feature parity with X, then released it to the world and started acting like it's the future.

[kmeisthax]

Wayland was specifically built to support things that aren't desktops, so feature parity with X was never a design goal of Wayland. The idea was that Wayland would be a super-flexible "you give me a window and events, I give you rendered bitmaps" kind of protocol, and then desktop functionality would be layered on top for people who wanted a desktop. Not everything needs to be a desktop (e.g. car infotainment displays, KDE Plasma widgets, etc), and some protocols would be super limited if they had to fit in a desktop mold (e.g. VR displays[0] with apps in non-planar windows).

The main mistake FD.o made is that they didn't get consensus on a "Desktop Profile" extension, so all the DEs wound up implementing their own thing. This is still fixable, just very annoying until we have agreement on this shit. I think that's what you meant by "feature parity with X".

[0] Currently, every desktop VR setup has to have two layers of compositors. VR applications have to communicate with a special VR compositor that then draws normal desktop windows with the contents of what should be hitting each eye of the VR display, all so it can pretend to be two normal displays.

[somat]

I could say the exact same thing about X, A lot of the problems people had with X historically was that developments goal was to "create mechanisms not policy" and people just wanted a desktop environment that worked.

An antidote on non desktop use of X: the other day I wanted to show a program on my phone, there are many good ways to do this, but I picked none of them. Instead I had just installed a terminal on the phone and noticed they had an X11 package, So A few minutes later I was the proud owner of an X server on a phone. And you know what... It was pretty great. My gaming system load and temps dashboard were displaying just fine.

Despite using X for many, many years, I had never just sat down and played with a bare X server, I had only dealt with it through the lens of a locked down, encumbered desktop system. It was like having a network attached monitor. From whatever system I was using as a desktop system I could just go "display this on that monitor", in this case a phone. Based on that experience I put a raspberry pi on my TV running a bare unprotected X server because having a network attached monitor rocks.

[ethin]

Yeah, pretty much. I would be less disagreeable about Wayland if they had solved this problem early (and yes, they should've thought about this early during Wayland because the most prominent target is desktop environments). But they didn't, and I don't even know if they'll come up with some unified solution that all DEs/WMs can agree on or whether they'll just keep allowing DEs/WMs to do their own thing. Either way, fragmentation is never a good idea on what, I think, many would consider critical functionality. At least, I consider the requirements to implement accessibility to be rather critical, which is the primary reason I still use Xorg.

[gf000]

If I have a kiosk terminal, why would I want the overhead of, say, screensharing? Also, isn't this the point of libraries, so that you only have to implement stuff once, and you can reuse it in different projects? Like you can build on top of wlroots just fine.

> The proper thing Wayland should've done is waited until Wayland had reached feature parity with X

How on Earth would you expect a fundamental protocol to be developed behind closed doors?! Wtf even.

[ethin]

> If I have a kiosk terminal, why would I want the overhead of, say, screensharing? Also, isn't this the point of libraries, so that you only have to implement stuff once, and you can reuse it in different projects? Like you can build on top of wlroots just fine.

Yeah but again this fragments the ecosystem massively. If people really wanted flexibility they could've just made it a configure option or something equivalent?

> How on Earth would you expect a fundamental protocol to be developed behind closed doors?! Wtf even.

Your making a pretty big assumption here, aren't you? I never said it had to be developed behind closed doors. It's the "lets just obsolete X11 even though Wayland can't even replicate a quarter of it's functionality right now now now because of security security security" that irritates me. If they had worked on Wayland and obsoleted it once they had reached feature parity, that would be releasing it to the world. Then they would've had far less friction and the transition would've been a lot smoother. Would it have delayed Wayland by maybe a decade? Sure, but I see little issue with that. IMO that probably would've made Wayland even better.

[rcxdude]

That's the issue. Because wayland punts on so much functionality that used to be available with standard interfaces in X11, it fragments the ecosystem to such a degree that all these useful little utilities just don't really have a means to grow.

[yjftsjthsd-h]

> If you change to another DE that has less capabilities than KDE, of course you can't do it

It's not inherent. If I change to another X DE, I can keep all my other programs and the features they implement.

[dev_hugepages]

:(

[lelanthran]

> Practically all the X usecases are covered on Wayland systems now. ... global hotkeys ...

Are you sure? I looked at that earlier this year for a personal tool I wanted to create and found no way to do it on Wayland (On X, I did it just fine).

I had a long back and forth about this very thing with both Claude and ChatGPT, and neither conversation was fruitful: every option had some dependency (like switching to KDE, or similar).

[LtWorf]

As I understand, blind people can't use wayland right now.

[ethin]

I know some blind people who tolerate it but yeah, I find it completely unusable at the moment. I haven't tried Gnome recently but last time I tried it I had apps like Bitwarden malfunctioning in some very, very weird ways that just... Never happened on Xorg. If I remember right, it was things like forms not being read properly or something, can't remember off the top of my head now. But it certainly didn't leave me with a good impression; it made me think this Wayland thing was just half-baked. Also, Orca modifiers were passed-through directly to the compositor and Orca wasn't allowed to intercept them either, which made just using my computer feel awkward since I'd always need to remember to turn off caps lock every time I wanted to do something even remotely complicated. I've heard that Gnome has solved this but as I said above, I think this may be a Gnome (and at most KDE) thing, and not something that everybody has decided to just do.

[justin66]

> That sort of solution is cancer if you want to do anything the display server authors didn't think of.

Hey come on man, a locking screen saver is a totally niche application. No demand for that.

[mikkupikku]

xscreensaver works just fine. It only needs to keep nosy roommates out, not the NSA. Not that Wayland would stop spooks anyway.

[justin66]

It doesn’t lock the screen properly under Wayland. There’s an abyss of complaining about Wayland on jwz’s blog.

https://www.jwz.org/blog/2025/07/xscreensaver-wayland-and-lo...

[ethin]

For some weird reason I can't access it, it just redirects me to this image about hacker news. Did he just configure his webserver to just universally display that image? Even if I manually enter the address into my address bar it does that so I assume that that's what he did...

[josefx]

The page sets a cookie when you visit it from hackernews and will redirect you to the image until you delete the cookie.

[justin66]

That’s new. Argh.

[justin66]

The author of xscreensaver holds hn in a certain amount of contempt, yes. Just go with it.

[justin66]

Also balls

[udev4096]

Totally unrelated, I like your nickname :)

[tuna74]

You can write a Gnome Shell extension or whatever the KDE equivalent is.