Zamundaaa

Also, using C++ has vtable/exception overhead. No-go.

That's just nonsense. The kernel and most other big C projects are full of structs with manual re-implementations of vtables.

If you don't want exceptions (I don't either), C++ doesn't require you to use them. KDE software builds without them.

Mostly, a good library on C++ (Qt used to be one of those, but it's started becoming annoying in the past few years) offers a lot of what Rust enforces at the language level.

I like C++, but let's not pretend that's actually true. Qt is completely full of really unsafe APIs, most of them quite old by now. It certainly doesn't offer anywhere close to any safety Rust provides.

Even something as innocent as passing a pointer to Qt's javascript engine can end up in use after free, and the signal+slot stuff goes wrong real fast once you do need multi threading.

(which is not to single out Qt specifically, the STL has plenty of really stupid and unsafe APIs as well)

xdotool should work the same in the Wayland session, assuming you give X11 apps the permission to emulate input. What about it isn't working?

uinput is not the proper way, it's emulating a hardware device.

The remote desktop portal is the proper way. Even xdotool works through that.

Plasma widgets are a gaping security hole.

Aka "thing that isn't sandboxed, never has been sandboxed, and never has been claimed to be sandboxed, is in fact not sandboxed". Just like any app from your distro repositories, or appimages, or games in Steam... Or even most Flatpaks by default for that matter.

Widgets being sandboxed would be cool and is a long term goal (which is way easier said than done!), but don't present them not being sandboxed as some irresponsible thing someone does because they don't care. Your expectations of security simply are simply completely misplaced.

What do you mean? Screen savers have been possible for many, many years...

VRR doesn't require additional bandwidth.

Try Linux on a 4k HDR 120hz TV and see what happens.

It works fine, with chroma subsampling. At least I personally don't ever notice it on the TV.

That's not to say this getting fixed isn't important, but it's mostly relevant for monitors and maybe smaller TVs that you sit closer to.

Not the person you asked, but I do have the new controller, and it works as they described it.

How it works afaik is that SDL has a driver for it, even if the kernel doesn't have a generic one yet. The controller also works in emulators without Steam running because of that.

All the distros use fprintd, but that's not related to Framework aside from the laptop using a sensor that fprintd supports.

The headset has eye tracking to make it possible, but yes, apps have to implement foveated rendering for it to work.

I think it is possible for the VR compositor to do some eye tracking optimizations for the app without the app doing special stuff, but I don't know how much that helps (or if it's even implemented in SteamVR).

There's no icc profile for it, it's just read from the EDID