They are known. But they are probably not fixed in 6.8 (as you can read on the article linked in the initial post of this thread).
Hej @breakingspell,
yes, same here on Plasma 6.5 on FreeBSD with wayland.
Don’t know if it helps, but I currently work around with kwin’s window rules to make windows appear where I want them to stay. Well, mostly… there’s e.g. thunderbird defying it and doing its own thing, but it works for most of the others.
But IMO changing from xorg, it’s an awkwardly solution to a regression of the former UX
1 Like
Can you be specific ?
If you refer to the first post here, Going all-in on a Wayland future or it has no linked bugs…
That was mostly about old Nvidia GPU support…
Nvidia issues are mostly out of the hands of KDE devs. It is a nouveau/NVK/Nova challenge.
Nvidia has mostly left behind their old GPUs not providing drivers for them. Nouveau was made despite Nvidia, full reverse-engineering…(at least this is much better nowadays).
It is not like those are already unsupported on Windows.
And like Wayland support was in shambles until last year even for recent Nvidia GPUs.
How long do those old GPU owner intend to keep using those ?
No hardware neither its support is forever.
Eck, I have x86-32 bits home server at home that I need to replace due to x86 now being amd64 only, for even debian. And that’s both sad and normal.
Still there has been some support still being worked on for those: https://www.phoronix.com/news/NVK-Kepler-Vulkan-1.2 https://www.youtube.com/watch?v=g2r-sRsp3B8 (section Blackwell enabling and Kepler enabling in particular).
I am speaking about the “going in” article and quote:
While we can’t promise all problems will be completely gone […]
There is also a link named significant known issues, speaking about window management.
I replaced my NVidia GPU before I switched over to Linux. Even on Windows I had no good experience with drivers (used the more stable studio drivers). No way that I want to deal with that garbage company any longer, even if I would stay on Windows. (Also because of other things as power connectors and other hardware decisions and of course about Palandir cooperation.)
I’d prefer to use Wayland but when I looked up prime render back when it came about I arrived at the conclusion that this won’t work for my reverse PRIME 2 monitor setup. Can’t remember which article confirmed it though.
Given your comment I decided to give it a shot and switched over to prime and Wayland but got stuck again. Second monitor won’t show.
Unfortunately X11 is now broken as well, xrandr won’t offer a virtual output any longer with the new prime drivers and without a virtual output there`s no target for intel-virtual-output.
Running out of time now, will have to restore the old OS 
Hey yes, to an extent, Window Rules are a half-workaround for some apps on the positioning issue. For a time i used it for initial position of startup apps in X11, but they all behave properly now without rules.
Like you mentioned though, Mozilla apps have trouble with this workaround.
I noted in another Wayland thread that it’s time to come out of the woodwork and press to make sure every X11 feature has a Wayland alternative.
If something critical to anyone’s workflow is not already on the show-stoppers list, now is the time to speak up.
1 Like
While Wayland support in the proprietary NVIDIA driver was quite rocky a few years ago, it has matured tremendously. Graphics cards still supported by the manufacturer work just fine nowadays
And here is me with the latest Nvidia card/drivers/Plasma unable to sign in into Wayland 
Wayland + Nvidia, black screen with cursor
Accessibility is a very broad topic, so it’s hard to make any definite statements, but we’re generally on par with the X11 session. All the basics already work as expected, including screen readers, sticky & bounce keys, zooming in, and so on.
However, accessibility features provided by third-party applications may be worse in some aspects
The problem is that there is no first-party accessibility on-screen keyboard, and most third-party ones are broken (especially non-basic).
For Onboard there is a fork and people say it works with the GDK_BACKEND=x11 flag, though as I understand it breaks some Wayland ideas, not sure if can cause issues. Plasma 6 and Wayland no on-screen keyboard working - #47 by INVICTRA
Also tools that perform any UI manipulation are broken, such as Talon (voice control) wayland-accessibility-notes/talon-requirements.md at main · splondike/wayland-accessibility-notes · GitHub
Maybe a partial workaround could be via ydotool 
I just force them to get into this position since “initial” does not work. But you cannot do it with multi window applications or at least I did not find any way to position sub windows.
2 Likes
Yes! I can confirm that! I have two nvidia gpus and wayland works. In the past I had issues but everything is fixed now since the 560 drivers as you can see in my following post
Wayland could still use quite a bit of polish.
Not the big stuff everyone is talking about, but the little stuff.
For example: Yakuake
It by design gets reopened on a different screen with a different size and position, and when running on wayland, this does not work reliably.
It also does not fail reliably.
And it’s small enough to not break things, therefore nobody is fixing it.
On wayland the screen scaling on my primary monitor sees to affect the dpi setting of my mouse (if I increase the scaling on the primary monitor it also moves faster on the other ones).
This is also not really breaking (I just change the setting accordingly).
This type of random wonkyness is still rather present in wayland, especially with multiple displays.
Before going wayland only stuff like this should be addressed to reduce frustration.
2 Likes
On Wayland, Yakuake consistently opens on the screen where your mouse is. That’s the default setting since 2013: Window → Open on screen → At mouse location.
If it’s not doing that on X11 then the bug is the other way around.
Did you mean something else? I feel like maybe you’re referring to when you set it to spawn on a specific screen, but that also works consistently here.
It’s set to open on the screen, the mouse is at, it just doesn’t (consistently).
Looks to me like it uses some sort of cached mouse position rather than the current one.
Open it, move the mouse to a different screen, reopen it.
It opens on the wrong screen.
If the screens are not identical in terms of resolution/scaling it will also open at the wrong position and with the wrong size.
It’s worth separating Wayland (the protocol) and “switching to wayland”. They sound like the same thing, but they’re not.
If you need the window positioning thing, you can force that app to run in XWayland. No reason to hold everything else up.
1 Like
Yeah, I don’t have that issue here.
Well either it just got fixed (my distro did not have an update for 2 month), or there is another side condition we don’t know about (might also depend on where the active window is…).
I have an odd combination of screens and GPUs (the System does not even fully boot with all screens connected to the same GPU), which tends to find interesting bugs.
Let me list some more:
If I open the hamburger menu in Firefox, it opens offset or even offscreen.
The kde system information claims I have 3 4090s (which is wrong).
The touchscreen has either multitouch or pen input, (depending on if the wacom kernel module is active) but not both.
I have no clue, who is to blame for what, and I know my use case is odd, but I know these issues go away if I switch to X11.
I am on wayland, because I want per screen scaling, but boy is it wonky.
Sorry, “switching to kwin powered by Wayland”. Insert the GNU/Linux copypasta.
Firefox in XWayland just disagreed, and spawned my windows smaller than the tiles they were left in. It seems XWayland can’t re-tile windows upon restore.
If XWayland tiling isn’t already a bug, I’ll open one, but this is not the solution. That positioning protocol is.
The little standards committee sitting on ext-zones need to take this to heart. Only with that standard can apps start implementing proper window positioning natively under Wayland
1 Like
This is also a issue in X11 on my kubuntu 24.04 machine.
Kubuntu 24.04 is on Plasma 5 to my knowledge.
Session restore with tiling has worked consistently for me in Firefox on X11 since at least Plasma 6.1 (last summer).
Addendum, I almost forgot that I did find CSD-based tiling bugs for Wayland and X11 that were summarily fixed by Mozilla around the same time.
It can’t tile its windows on Xorg either, it’s literally not exposed to the application. Not even KWin’s session restore for X11 apps currently restores tiles (though that could be fixed).
Apps being able to position themselves does not make them do session restore, quite the opposite, it removes an incentive to implement it and is likely to cause bugs with it (like session restoration restoring tiling state, and then the app moving its window out of the tile).
Going all wayland? So, Wayland is clear this issue?
[Tablet pen and mouse do not sync cursor positions when using Wayland]
Now wayland or future wayland is sync position of graphic stylus cursor position and mouse cursor position?
I use graphic stylus of wacom. I use Krita, gimp, DAW, blender… so many creator application.
I used old Wayland system is not sync cursor positions. That is terrible. If I little touch mouse on use graphic stylus pen, cursor position is go to panic .
I back to X11 now. I hope fix issue before X11 EOL.