long press for imitating a right click, but text selection with popup copy/paste/etc buttons would also be useful.
Unfortunately that’s not something that can be done system wide, apps have to handle that themselves.
afaik not packaged for any distro
It’s packaged in every widely used distro.
Writing graphics code in a unified model is quite a bit different from the conventional x86 model.
It isn’t. The difference is pretty small, and it’s just optimizations for when copies can be skipped and not a radical change in the approach of how rendering is done.
Intel would need their own equivalent to Metal if they wanted to do a similar move.
Not at all. If big-ish changes were required, they could be exposed as Vulkan extensions.
I don’t know enough about Vulkan to say if it’s compatible with this kind of approach
Of course Vulkan, the graphics API used on all modern phones except Apple’s, supports using integrated graphics efficiently.
It is closed in the sense that all the ISO specs are closed - you have to pay a decent sum of money to see the specs, and you’re not allowed to just copy them and show them to people that haven’t bought access.
They are not closed like HDMI though - if you implement them, copy constants from the specs into the Linux kernel for example, that’s fine. Having actually open standards like Wayland would be a lot better though ofc…
Does Wayland only encompass communication between clients and the server?
Yes
Is requesting VRR a part of Kernel Mode Setting, then?
Also yes
via the Wayland protocol
There’s no Wayland protocol involved, Mutter directly talks to the kernel
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).
It’s a driver bug, it doesn’t reject buffers that the GPU can’t actually handle correctly.
We’ve switched to a different way of doing multi-gpu in Plasma 6 that hits at least fewer such bugs.
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
Yes. Flathub wants to become a platform where people and companies can sell their software
Thst might change with Flathub’s ambitions to become an actual app store though
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:
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.
That sounds like your TV is temporarily disconnecting at random, or at least doing something that the GPU detects as a disconnect.
Most likely, AMD’s hotplug detection is too aggressive. You can report that at https://gitlab.freedesktop.org/drm/amd/-/issues
The very next words are “but it was my responsibility”… what exactly is bad about that statement if you don’t intentionally cherry pick a bad quote?
SteamVR in Flatpak functions but you will get rediced performance because it can’t set CAP_SYS_NICE for vrcompositor. I haven’t checked if setting it manually could work though
Nah, for most people SteamVR works ootb with the Index… but SteamVR is also quite buggy.
How well does it run? I tried to play it on the Deck a while ago but it was too laggy for me
That’s because Windows has a system provided toolkit that most apps use