wasn't it thought for kiosk applications, then extended to login screens
No, that's a really pervasive myth, spread by trolls.
Wayland - or rather, Weston - first came into use in the embedded scene because things are a lot simpler to change there and the limitations of Xorg even more unforgiving... But it was never designed for that purpose alone, it was always meant to replace Xorg everywhere.
It is repeated in every single damn "Linux phone" thread, and in every single thread an answer like this is needed: No, it fucking isn't. You know exactly what everyone means, stop being a dick about it.
Yes, though it's not exactly relevant to your wishes... KWin has supported VRR for almost three years now, and HDR for 9 months too (not released yet ofc). I've been playing all my HDR capable games in HDR mode for the past few months.
For me, this is more about making it more efficient and make it work better by default.
until apps can declare on a simple config file what paths they require
They can, and always could. Apps aren't doing it, most Flatpaks have just blanket "allow ~/Downloads" or "allow all of home" permissions by default - or no file permissions, and you have to go grant them manually yourself.
Again, unless apps actually support it, no matter how good the security system is, it won't work out.
Instead of bluntly blocking things why can't Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path?
Because the user getting a hundred popups on app start for various files the app needs isn't exactly a usable experience. Also, blocking the app's main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.
Aside from apps using the APIs meant for the purpose of permission systems, there's no good way to make it work.
The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.
No, Flatpak isn't the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there's noone restricting the old / unrestricted ways of doing things... So apps usually don't port over to the portals.
Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don't get kicked from app stores for it, and because many users can still fall back to using the old system.
Plasma never had this issue in any release, VRR has worked exactly the same since it was introduced until Plasma 6 (where there's some improvements for the "always" mode)
FreeBSD isn't working on a Wayland port, that's already happened. The Plasma Wayland session has supported it for quite a while... KDE even runs a CI job on FreeBSD for every merge request, where kwin_wayland autotests are run.
Considering the amount of complaints we got when something broke recently though (which is to say, none), it doesn't look like it has a lot of users
Unfortunately Debian stable doesn't ship our bugfix releases after the major Debian version gets tagged - KDE Plasma in Debian is currently at 5.27.5, and 5.27.10 was released upstream two months ago.
In other words, you'll be experiencing bugs that have long been fixed... I'd advise to stay away from Debian for KDE Plasma because of that. If you want a Debian based distro with a good KDE Plasma experience, KUbuntu is likely a better choice, even with forced snaps. If you don't need Debian though I'd recommend taking a look at Fedora KDE or Arch (derivatives).
The 1 second present timeout still only works for XWayland
Oof, I thought the corresponding MR for Wayland was merged... But it was from Sebastian and after he got into a heated discussion again and started cursing, the MR got closed by someone else :|
realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does
SDL does handle it, but only for OpenGL; it can't do anything about Vulkan. GLFW doesn't do anything about it either, so that is pretty annoying.
I believe in the glorious Wayland future… I just wish it would get here a bit faster
Don't we all. Let's hope the current upstream approach to fix this issue gets somewhere sooner than later...
Sorry, but Debian stable is a terrible recommendation! They don't even ship bugfix releases of KDE Plasma... It's stuck with a months old version that has lots of known and long fixed bugs in it
Debian doesn't ship bugfix releases of our software. If you want a stable experience in the actual meaning of the word instead of just something that doesn't change, almost every other distro will be a better choice
No. Some people wanted to change it to that for Plasma 6, but on Xorg there's apparently no way to make that happen, as the cursor is always decided on by the window you're hovering over...
What are the not-a-bugs? Things like covering up a Wayland window will block it's rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don't want applications to know if their window is visible or not because it's mild information about a user's attention that should be private. Every game dev on the other hand is asking "WTF!?" as it causes their games to break randomly
Please don't make up what "Wayland core folks" think. You don't know it, and your claims are waay off.
It's not about security. It was intended to allow the compositor to throttle apps to improve efficiency... Which of course in practice doesn't work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.
As for why that hasn't been fixed yet, it's not as big of a problem anymore:
Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
xdg shell now contains a flag for apps to know to inhibit rendering because they're hidden. That doesn't guarantee that presentation won't otherwise block though
a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can't pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can't open and focus URL in your web or file browser. Instead they have to give you a notification telling you "Firefox is Ready" and make you do it manually.
That's not even close to how activation works on Wayland, and no, it's not just a security thing, it's a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can't cover up what you're working on just cause they need to show you an ad or an "important" pop up question or whatever. If it doesn't work for a specific app, make a bug report about it to the app.
No, that's a really pervasive myth, spread by trolls.
Wayland - or rather, Weston - first came into use in the embedded scene because things are a lot simpler to change there and the limitations of Xorg even more unforgiving... But it was never designed for that purpose alone, it was always meant to replace Xorg everywhere.