• 0 Posts
Joined 1 year ago
Cake day: June 11th, 2023


  • KDE did bother, this does neither happen with KScreenlocker, nor do non-screenlocker windows show in another way, because the screen locker is integrated with the compositor.

    If the compositor crashes or gets disabled somehow ofc though, that integration doesn’t help either and you have to rely on a mountain of bad hacks as well as the hope that the screen locker doesn’t also crash for nothing to happen in that case, but it’s as close to secure screen locking as you get on Xorg… in the end the solution for secure screen locking is still Wayland.

  • Fedora just has

    polkit.addRule(function(action, subject) {
        if ((action.id == "org.freedesktop.packagekit.package-install" ||
             action.id == "org.freedesktop.packagekit.package-remove") &&
            subject.active == true && subject.local == true &&
            subject.isInGroup("wheel")) {
                return polkit.Result.YES;

    in /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules. If you put the same file in there, it should work.

  • 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.

  • Most displays provide settings to modify the colors of your screen; mine has like 10 different “picture modes” that strongly modify gamma curves, colors and the whitepoint. The EDID only describes colors of one of them, so if you change display settings, the data no longer applies.

    More generally, the information isn’t used by Windows or other popular video sources by default, so manufacturers don’t have much of an incentive to put correct information in there. If it doesn’t make a difference for the user, why would they care? Some displays even go so far as to intentionally report wrong physical size information, to make Windows select the default scale the manufacturer wants to have on that display (or at least that’s what I think is the case with my cheap AliExpress portable monitor)…

    That’s not to say that the information is actually often completely wrong or unusable, but if one in tenthousand displays gets really messed up colors because we toggle this setting on by default, it’s not worth it. We might add some heuristics for detecting at least usable color information and change this decision at some point though

  • it falls to each and every individual app to (re)implement everything: accessibility, clipboard, keyboard, mouse, compositing etc. etc.

    I haven’t read so much nonsense packed in a single sentence in a while. No, apps don’t implement any of these things themselves. How the fuck would apps simultaneously “implement compositing themselves” and also neither have access to the “framebuffer” (which isn’t even the case on Xorg!) nor information about other windows on the screen?

    Please, don’t rant about things you clearly don’t know anything about.