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.
Suspend works just fine with Fedora KDE on my AMD Framework 13. I don’t know about hibernation, since I use FDE and Linux still doesn’t support encrypted hibernation.
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
Literally no other desktop has this functionality…
Yeah, afaik MacOS can do it too.
ICC profile is built-in in memory of my laptop screen?
Yeah. Surprisingly, nearly every display comes with somewhat accurate color information in its EDID.
Even Windows can’t do it
Afaik they did actually implement something in this direction in Windows 11, but it’s not exposed in a user friendly way yet.
There is no saturation slider, though. I’ve seen it on some screenshots.
It’s currently always shown if the built in color profile, HDR or an ICC profile is used. IIRC it wasn’t visible with the color profile in some older version of Plasma though, maybe that’s why you don’t see it.
Afaik Youtube is doing that, not Pulseaudio, and there’s nothing that can be done about it.
what about color managed apps?
Colord isn’t running and no icc profile is set on Xwayland, so they should assume sRGB as the target and be fine.
Do note that nothing is applied “to the full screen”, color management is done on each individual surface during compositing. If an app uses the color management protocol to use some colorspace, it gets taken into account.
Are you sure you can affect saturation system-wide with color profiles?
Yes, I wrote the relevant code in KWin.
Because in Gnome it’s not possible.
That’s because Gnome’s color management support is still limited, they don’t apply the full ICC profile yet.
That’s wrong. You can’t stream from the SteamOS game mode specifically, but streaming from a Linux desktop works.