Hyprland version
Hyprland 0.56.2 built from branch v0.56.2-b at commit efb50993780079460b0cbed1363e2166a2de1d9f clean ([gha] Nix: update inputs).
Date: 2026-08-05
Tag: v0.56.2, commits: -1
Libraries:
Hyprgraphics: built against 0.5.1, system has unknown
Hyprutils: built against 0.14.1, system has unknown
Hyprcursor: built against 0.1.13, system has unknown
Hyprlang: built against 0.6.8, system has unknown
Aquamarine: built against 0.14.0, system has unknown
Version ABI string: efb50993780079460b0cbed1363e2166a2de1d9f_aq_0.14_hu_0.14_hg_0.5_hc_0.1_hlg_0.6
flags set:
nix
I’ve been trying to set up HDR properly but I’m running into a bizarre issue that only affects specific applications, that being Obsidian and mpv. It’s possible if I installed more applications I would find more, but of the ones I have on my system, these are the two it applies to.
These are my monitor settings: hl.monitor({ output = “DP-1”, mode = “2560x1440@170”, position = “0x0”, scale = 1.0, bitdepth = 10, cm = “hdr”, supports_hdr = 1, supports_wide_color = 1, max_luminance = 250, sdr_min_luminance = 0.0, sdr_max_luminance = 203, sdrbrightness = 1.25, sdrsaturation = 1.0 })
Which I derived from this post: A proper HDR configuration, actual is wrong · hyprwm/Hyprland · Discussion #14682 · GitHub . I have tried many other combinations of these settings, but none of them help with the problem. I really don’t know why it’s specific programs that are very different in function and backend. Is this a wider reported issue than here?
These two applicatioons render visibly dim/dark on the screen, but whenever I take a screenshot, the screenshot captures them at absolute maximum brightness. If I could keep them in this fullbright mode all the time, that would be an acceptable workaround, btw.
Because this issue is occuring on two completely unrelated application backends (Electron for Obsidian, Vulkan/GPU-next for mpv), it feels like a compositor-level surface mapping issue. Is there a specific window rule or protocol flag I wuld need to prevent color-managed apps from getting crushed under a 250-nit HDR surface mapping? I didn’t have this issue on Gnome if that helps, I do not know how this is done on Gnome however, to compare it to.
I can take a screenshot if that helps, but I don’t think it would, it wouldn’t actually show the apps dim anyways.
These are from my monitor’s DRM_Info:
Max display mastering luminance: 250 cd/m²
Min display mastering luminance: 0.0000 cd/m²
And these are the general specs, if it gives any clues to what would be happening:
Panel Size (inch) : 27
Aspect Ratio : 16:9
Display Viewing Area (H x V) : 596.74 x 335.66 mm
Display Surface : Anti-Glare
Backlight Type : LED
Panel Type : IPS
Viewing Angle (CR≧10, H/V) : 178°/ 178°
Pixel Pitch : 0.233mm
Resolution : 2560x1440
Color Space (sRGB) : 130%
Color Space (DCI-P3) : 96%
Brightness (Typ.) : 250cd/㎡
Contrast Ratio (Typ.) : 1000:1
Display Colors : 1073.7M (10 bit)
Response Time : 1ms MPRT
Refresh Rate (Max) : 170Hz
HDR (High Dynamic Range) Support : HDR10
Flicker-free : Yes
I am on NixOS, if that is relevant.
Update
"mpv --target-colorspace-hint=no “[file]” works around this issue for it, I have put that in my mpv config. Obsidian being dim isn’t a big deal, especially since you can edit the files with any frontend. So the main concern is I just want to figure out why some apps are having this issue so I know how to mitigate it in the future.