• 1 Post
  • 353 Comments
Joined 1 year ago
cake
Cake day: June 25th, 2023

help-circle



  • azvasKvklenko@sh.itjust.workstolinuxmemes@lemmy.worldMany such cases
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    23 hours ago

    The problem with HDR is that it’s very difficult to get working on X11, to the point that those who tried (NVIDIA, 8 years ago) gave up long time ago and moved on. X11/Xorg is legacy solution that is still there mostly because it always was and things still depend on it.

    Wayland can get HDR and it gradually does, but it wasn’t priority for quite a long time as there was much more basic stuff missing, to the point many users wouldn’t switch until recently, and because X was still the preferred display system for most users for such a long time, it wasn’t priority to fill missing gaps on Wayland side and it wasn’t moving forward too fast.

    Now that things are coming together, over half of the user base (probably) already switched to Wayland, there are more desktop/WM options on the Wayland side, with fewer showstoppers every year, finally NVIDIA drivers start working on Wayland, color management is also getting closer to be part of the official spec. It’s already possible to play games in HDR, but with some solvable caveats: if a game runs on X11 (which for Wine/Proton the Wayland driver is still experimental) they use swap-chain hack to that’s only available in the gamescope compositor, so either in full blown Steak Deck session or wrapped in nested gamescope instance. This will be more out-of-box when:

    1. the stable color management protocol is actually in place, more compositors implement it (currently only gamescope and kwin_wayland have HDR)
    2. winewayland.drv stabilizes and implements HDR
    3. Wine and Proton run on Wayland natively by default





  • I know this issue. It’s reproducible when

    • Using AMD on Wayland
    • Only on certain screens or only on HDMI (I never reproduced that when using DP)
    • The game is running in non-native resolution, meaning the compositor is doing upscaling
    • The game window is full screen and focused - the black blocks go away if you show some desktop menu or focus other window on top - so basically looks like only happens when the direct scanout protocol is doing its thing
    • not only in Steam games, in most games in general

    The problem has long been reported in Mesa project, but nothing was done to help. My bet is that the bug sits in amdgpu kernel driver and not user space.

    https://gitlab.freedesktop.org/mesa/mesa/-/issues/8705

    EDIT: maybe it’s worth to report in kernel bugzilla or wherever amdgpu kernel driver bugs would go. I don’t reproduce this on my end anymore, because I changed my screen and it uses DP

    EDIT2: I could only reproduce it on RDNA2 and yours is RDNA3. I had Polaris (RX 570) for quite some time and it was running on Wayland. Maybe it only happens on newer cards, maybe it’s regression added along the way











  • Around 12 years ago, I was able to break Debian or Ubuntu installs on weekly basis due to certain packages being too old, something being missing from repos so being forced to compile stuff manually, dealing with junky 3rd party repos etc. Then after switching, I hardly ever messed anything on Arch while also spending less time tweaking it than I did with Ubuntu. Even if I did break something, it was my fault. And it’s not that I cannot handle Debian-based OS installs if I have to. I think those systems are fine if they work for you by default and stock repos contain everything you need (and it’s usually enough for servers) The problem is, it’s not always like that and you just have to add some custom package (prepared by you or someone else) every once in a while, not necessarily with an official support. This is just plain easier on Arch.