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

help-circle



  • Also, your blog is fantastic, I’m always happy when there’s a new post =)

    Thank you, I’m glad you like it!

    I feel like in SDR mode, the OLED is pushing brighter images. I almost feel like it’s underselling the capabilities at 270, but does so to give pixels a rest every now and then, in the hope that the bright spots don’t stay stationary on the screen. It’s a wild guess, I have no idea.

    It’s certainly possible, displays do whacky stuff sometimes. For example, if the maximum brightness in the HDR metadata matches exactly what the display says would be ideal to use, my (LCD!) HDR monitor dims down a lot, making everything far, far less bright than it actually should be.

    KWin has a workaround for that, but it might be that your display does the same thing with the reported average brightness.




  • I understand that it’s an absolute brightness standard, not like the relative levels in SDR

    The standard is also relative brightness actually, though displays (luckily) don’t implement it that way.

    why does it end up washing out colors unless I amplify them in kwin? Is just the brightness absolute in nits, but not the color?

    It depends. You might

    • have a driver bug. Right now only AMD has correct color space communication with the display, that doesn’t work correctly on Intel and NVidia yet
    • have a display that does a terrible job at mapping the rec.2020 color space to the display
    • be just used to the oversaturated colors you get with the display in SDR mode

    Why does my screen block the brightness control in HDR mode but not contrast?

    Because displays are stupid, don’t assume there’s always a logical reason behind what display manufacturers do. Mine only blocks the brightness setting through DDC/CI, but not through the monitor OSD…

    Why is my average emission capped at 270nits, that seems ridiculously low even for normal SDR screens as comparison

    OLED simply gets very hot when you make it bright over the whole area, the display technology is inherently limited when it comes to high brightness on big displays



  • enabling the built in color profile desaturates colors quite a bit and does some kind of perceived brightness to luminosity mapping that desaturates bright / dark hdr content even more

    It maps the colors to be more correct, and it does use the brightness info from the EDID for HDR content, so that checks out.

    I think there must be something wrong with my screen since the hdr reduces saturation more than anything else

    It might enable some sort of gamut mapping on the display side… HDR on monitors is really weird sometimes.

    Side note, when I turn off hdr only from kscreendoctor the display stays in hdr mode until it turns off and on again, that didn’t happen with nvidia

    I think that’s a bug in amdgpu. It should force a modeset on hdr change, but it doesn’t.


  • That has pretty much nothing to do with the color profile, when colors look very desaturated on HDR screens, that’s the driver messing up the colorspace signaling.

    What GPU do you have? Both Intel and NVidia still have major problems with this.

    Many displays (but not all, which is why it’s not exposed in the GUI) also support doing HDR without additional colorspace signaling, you could try enabling only hdr and disabling wcg with kscreen-doctor. IMO the color part is the more noticeable benefit of HDR, but you could at least have functional HDR until your GPU driver is fixed.








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




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