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

help-circle

  • The real one? It was fine on Xorg though

    When an app (in your case, Steam) uses X11 APIs to move the cursor, that of course works on Xorg, but Xwayland merely emulates it - so it moves the X11 pointer for X11 apps, but not the pointer from the Wayland compositor.

    Some compositors allow Xwayland to request moving the real pointer instead of doing emulation, but River apparently doesn’t.


  • I have some problems with X11 cursors and that’s quite normal with Wayland obviously

    It’s not. There is no Wayland specific cursor format, it’s all just images on disk, and the most widely used format hasn’t changed away from Xcursors yet.

    For example, my cursor can become invisible if my screen sleeps

    That’s either a compositor or driver bug, please report it (as I’ve never seen that on Plasma, to your compositor first).

    Additional controllers that control mouse cursor don’t control X11 cursor, however they still work, I just don’t know where the cursor is unless it highlights something.

    That’s because it moves the X11 pointer but not the real one. A cursor theme can’t change that.








  • You don’t need to use steamtinkerlaunch, putting gamescope --hdr-enabled --fullscreen -W width -H height -- %command% into the launch options is enough.

    Will the Gnome version of Bazzite work for HDR on an Nvidia GPU, or for that matter any other OS as long as I’m using gamescope to run the game with HDR enabled?

    Gamescope can’t make a different compositor support HDR. Until Gnome supports HDR and the protocol used by gamescope, it won’t work.





  • 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