Black/Darker Areas/Screen during "inactivity" with cm="hdr

[Vanadiom]

Hi,

The problem seems to be bound to display surfaces, and appears only after some time of "inactivity".

As a non-well-informed and frankly absolutely incapable graphicsAPI user, this "feels" like a swapchain issue, where the one "image" is corrupted (only on some surfaces example: top half of browser/waybar/the browser CTRL+F hover window thingy) and a frame update causes it to appear and disappear.

• The wallpaper always seems affected when the effect appears
• Moving stuff really fast (mouse windows) makes the issue go away, especially when the mouse is above the affected area.
• Mouse is always rendered cleanly ABOVE affected areas.

info:

OS:                  Arch Linux x86_64
Hyperland Version:   Hyprland 0.55.1 built from branch v0.55.1 at commit a47147bc095e5b3be3eb8bd04f0ac242b968cd4d clean
GPU:                 AMD Radeon RX9070 XT
Monitor:             AW3425DW

monitor.lua:

-- Base monitor setup
hl.monitor({
  output              = "DP-2",
  mode                = "3440x1440@240",
  supports_hdr        = 1,
  supports_wide_color = 1,
  bitdepth            = 10,
  cm                  = "hdr",
  sdrsaturation       = 1.2,
  sdrbrightness       = 1.2,
})

hl.monitor({
  output    = "",
  mode      = "preferred",
  position  = "auto",
  scale     = "auto",
})

config.lua:

-- Config stuff 
hl.config({
  general = {
    gaps_in     = 4,
    gaps_out    = 8,
    border_size = 1,
    layout      = "dwindle",
  },

  input = {
    -- KB stuff
    kb_layout     = "us",
    kb_variant    = "workman",
    kb_options    = "compose:menu",
    -- Mouse stuff
    follow_mouse  = 1,
    sensitivity   = 0.0, --nochange
  },

  dwindle = {
    preserve_split = true,
  },

  render = {
    cm_enabled = 1,
    send_content_type = 1,
    cm_auto_hdr = 1,
  },

})

Also different cms that should fit make colours seem weird, I'll get into that another time

[Vanadiom]

Yes, I have seen #14579
No, I don't believe it's the same issue, (could be tho, didn't really understand exactly what's described)

[ScottKane]

I am getting the same issue with:

monitorv2 {
    output = desc:Samsung Electric Company Odyssey G95NC HNTL100168
    mode = 7680x2160@240.0
    position = 0x1440
    scale = 1.5
    bitdepth = 10
    cm = hdredid
    sdrbrightness = 0.5
    sdrsaturation = 1.0
    sdr_min_luminance = 0.006
    sdr_max_luminance = 1015
    min_luminance = 0.006
    max_luminance = 1015
    max_avg_luminance = 604
    supports_hdr = 1
    supports_wide_color = 1
}

I also can't take screenshots with grim since updating to 0.55, it just screenshots the compositor desktop (including waybar) but not the content

[Sirnatu]

I had the same issue. Weirdly enough, it seemed to capture fine until it flickered. After which it would remain broken unless i edited my config and reloaded.
In my case i narrowed it down to any sdr related options. sdrbrightness, sdrsaturation, sdr_min_luminance, etc. as soon as i removed these, the issue of flickering on inactivity (or second monitor activity) and everything apart from wallpaper, waybar and cursor being invisible on screenshots/captures, was resolved. Also fixed blur being transparent. This does mean, however, that sdr content was incredibly dim so i opted to ditch cm = hdredid for auto hdr, much to my dismay.

[Evan555alpha]

Similarly here with:

hl.monitor({
	output = "DP-1",
	mode = "5120x1440@240",
	position = "0x0",
	scale = 1,
	bitdepth = 10,
	cm = "hdr",
	sdrbrightness = 1.15,
	sdrsaturation = 1.05,
	vrr = 1,
	sdr_min_luminance = 0.005,
	sdr_max_luminance = 203,
})

hl.monitor({
	output = "HDMI-A-1",
	mode = "1920x1080@60",
	position = "auto-center-down",
	scale = 1,
})

On Artix Linux x86_64 (Zen kernel 7.0.10) & Hyprland 0.55.2 (branch v0.55.2 at commit 39d7e20 clean)

My experience with the flicker is that select windows will render completely black for 1-2 seconds before returning to normal. Wallpaper seems to always be affected, as are fullscreen windows. It seems that any mouse movement/window content change is enough to stave off the flicker.
When the flickering starts, that's when screenshot/capture breaks. I've noticed that when trying to capture with Flameshot/OBS after the flickering starts, they will capture a cached(?) frame and not the current contents. I've had it where Flameshot could capture what was on my monitor several hours ago.

As @Sirnatu notes, reloading the config does temporarily resolve the flickering and capture issue. Removing SDR related options does work as a workaround as well.

[deivi98]

Same here. Removing HDR options fixes everything. Screenshots cannot be taken an black boxes in screen flickering everywhere

[GOLD875379]

@vaxerski any info about this? (sorry if isnt correct to mark you) i am too with this "after inactivity" flickering and its very annoying. It affect everything that is related to my terminal (kitty) like nvim, yazi and image viewers like qimgv get a black screen when changing from one image to another.

If every window is closed, only with the background (hyprpaper), after some time of not moving the mouse a big black square appear in the center of the screen and starts to flicker, when the mouse is moved rapidly the square disappear.

Every time after the inactivity if the mouse is moved slowly the flickering starts and sometimes popup windows make the screen black (need to move the mouse to show anything).

I dont want to go back to 0.54 because i already ported my config from .conf to .lua.

Some of my config that can help or be related to the problem:
Hyprland 0.55.4 built from branch v0.55.4 at commit a0136d8

Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.13.1, system has 0.13.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.12.0, system has 0.12.1

Version ABI string: a0136d8c04687bb36eb8a28eb9d1ff92aea99704_aq_0.12_hu_0.13_hg_0.5_hc_0.1_hlg_0.6
no flags were set

hyprland.lua (everything else default):
hl.monitor({
output = "DP-2",
mode = "2560x1440@165",
position = "0x0",
scale = 1.0,
transform = 1,
bitdepth = 10,
cm = "hdredid",
sdr_eotf = "gamma22",
sdrbrightness = 1.10, --1.15,
sdrsaturation = 1.45, --1.30,
supports_wide_color = 1,
supports_hdr = 1,
sdr_min_luminance = 0,
sdr_max_luminance = 500,
min_luminance = 0,
max_luminance = 500,
max_avg_luminance = 200,
})

hl.config({
render = {
send_content_type = true,
cm_enabled = true,
cm_sdr_eotf = "gamma22",
cm_auto_hdr = 0,
direct_scanout = 0,
use_fp16 = 1,
keep_unmodified_copy = 1,
use_shader_blur_blend = true,
},

hl.window_rule({
match = {class = "kitty"},
opacity = "0.97 0.99",
})

[Dsverre]

I've been experiencing the exact same issues for a while myself.
I unfortunately believe it started occurring when the Vulkan/fp16 rewrites started in mid/late April.
I say unfortunately, since those rewrites enabled me to get quite a performance boost in regards to color management on my LG TV. The gains are such that I actually just live with the black boxes, since it primarily happens while idling in a terminal or on a static web-page, which I seldom do.

I have similar config to most people here, but sport an NVIDIA GPU and I use cm=hdredid and not cm=hdr, so it seems like it's not dependent on GPU or monitor..

    render = {
        direct_scanout = 0,
        --non_shader_cm  = 0,
        cm_auto_hdr = 0,
        use_fp16 = 1,
        use_shader_blur_blend = 1,
    },

hl.monitor({
    output = "HDMI-A-1",
    mode = "3840x2160@143.99",
    position = "0x0",
    scale = "2",
    bitdepth = 10,
    cm = "hdredid",
    --vrr = 1,
    --sdrbrightness = 1.35,
    sdrsaturation = 1.15,
    sdr_min_luminance = 0.005,
    sdr_max_luminance = 200,
})

Hyprland 0.55.0 built from branch main at commit 88262e1f860adc56f528ef68b2909ee33a27186b clean (tests/misc: remove isDirection(char)).
Date: Mon Jun 15 21:21:34 2026
Tag: v0.55.0-187-g88262e1f8, commits: 7477

Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.13.1, system has 0.13.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.12.1, system has 0.12.1

Version ABI string: 88262e1f860adc56f528ef68b2909ee33a27186b_aq_0.12_hu_0.13_hg_0.5_hc_0.1_hlg_0.6
no flags were set

GPU information: 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD103 [GeForce RTX 4080 SUPER] [10de:2702] (rev a1) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64  610.43.02  Release Build   

To summarize and confirm symptoms:

• black boxes when idling on a terminal, often my entire waybar, the entire terminal or just the cursor.
• screenshots and screensharing breaks immediately after first black box appear.
  • sometimes just transparent screen but waybar showing
  • other times a frozen picture that was on screen - could be hours ago.
• occurs on both cm=hdr and cm=hdredid
• screenshot/sharing-functionality returns when reloading config.

[9oOzv]

Hyprland 0.55.2 built from branch v0.55.2 at commit 39d7e209c79d451efab1b21151d5938289da838d clean (version: bump to 0.55.2).
Date: Sat May 16 12:59:19 2026
Tag: v0.55.2, commits: 7319

Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.13.1, system has 0.13.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.12.0, system has 0.12.0

Version ABI string: 39d7e209c79d451efab1b21151d5938289da838d_aq_0.12_hu_0.13_hg_0.5_hc_0.1_hlg_0.6
no flags were set

I think I am experiencing the same issue. Window goes black after idling for a second. Happens frequently but not sure what triggers it, not consistent. Seems to happen mostly when idling on a kitty terminal.

• cm="hdr"
• RTX 5070
• Arch Linux
• nvidia-open-dkms 610.43.02-2

[waltmck]

Hyprland 0.55.4 built from branch v0.55.4-b at commit a0136d8c04687bb36eb8a28eb9d1ff92aea99704 clean ([gha] Nix: update inputs).
Date: 2026-06-11
Tag: v0.55.4, commits: -1

Libraries:
Hyprgraphics: built against 0.5.1, system has unknown
Hyprutils: built against 0.13.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.12.1, system has unknown

Version ABI string: a0136d8c04687bb36eb8a28eb9d1ff92aea99704_aq_0.12_hu_0.13_hg_0.5_hc_0.1_hlg_0.6
flags set:
nix

I can also reproduce this issue, using monitor string

DP-1, 3840x2160@240, 0x0, 1.5, vrr, 1, bitdepth, 10, cm, hdredid, sdrbrightness, 1.65, sdrsaturation, 1.1

[MicroTransactionsMatterToo]

I found that render:keep_unmodified_copy = 1 caused the issue even with HDR disabled on the screen in question. Given it's automatically enabled when SDR modifiers are set by default, it seems the likely culprit. Setting it to render:keep_unmodified_copy = 0 fixes the issue while HDR is enabled on the display, but breaks grim (the section that should include the HDR screen is just blank), and causes intense flickering if you try to screenshare the HDR screen.

Used monitor settings below:

monitorv2 {
    output = DP-3
    mode = highrr
    position = 0x0
    scale = 1
}

[neonvoidx]

I did a git bisect 5ba33f8 , for me the issue starts here with portrait mode or rotated monitors flickering

[neonvoidx]

turns out to be setting use_fp16 to 1 instead of 2, in case you have some hdr and some non hdr monitors

[neonvoidx]

also seems related to direct scanout being set