render_bit_depth 10 does not work

[e00E]

sway version 1.8.1

sway.log

config:

output DP-1 {
    mode 3840x2160@59.997Hz
    render_bit_depth 10
}

My monitor is the Dell P2723QE. It is capable of accepting 10 bit color depth. Sway is configured to use 10 bit color depth. The monitor in its menu reports that the color depth is still 8. This is a bug because it should be 10.

I have verified that 10 bit color depth works on the same hardware by booting Windows and setting the appropriate option there. There the monitor reports the color depth as 10.

Edit: After testing again I now see the monitor reporting that 10 bit color depth is in use. I've made no changes to software or hardware. It seems like something is fickle. I'm going to leave this open for this reason. Maybe there is something useful in the debug log. Feel free to tag me to test again in a year so we can close the issue if starts working reliably.

[FakeMichau]

The manual says

Successfully increasing the render bit depth will not necessarily increase the bit depth of the frames sent to a display.

So I think the devs are at least aware of this.

[e00E]

I interpreted that sentence and surrounding text as meaning that the feature is experimental and might not work for that reason. In that case a bug report like this is useful to improve the feature. I expect that it works correctly on some monitors.

[emersion]

No, it's not about the feature being experimental, it's that the driver might pick a lower bit depth for the wire encoding because of bandwidth limitations. Can you share a drm_info dump? I'd like to look at the max bit depth prop.

[deprecated-dot]

Regarding drm_info what's the property called? I get a heap of output, so I'm trying to narrow it down.

Side note, on the vulkan backend ( WLR_RENDERER=vulkan environment variable) setting render_bit_depth 10 with the latest wlroots commit ( https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/5adf325333602d5b1e7ccdeb122633bbc8040ace ) causes the color to wash out and look oversaturated, almost like bad HDR on Windows. I reverted to the previous commit and it works like it did before, but I don't know if 10-bit is actually working. I don't know if that's on wlroots, or if sway just hasn't chased the change.

Thanks for any insight you may be able to provide!

Edit: this is on an AMD GPU ( Navi 10, 5700 XT ) on Gentoo, using git ebuilds of mesa, sway, wlroots, vulkan-headers/vulkan-loader etc.

[emersion]

The prop is https://drmdb.emersion.fr/properties/3233857728/max%20bpc

But you can post the whole dump. Yeah the Vulkan renderer thing is a known regression.

[deprecated-dot]

Excellent, thank you. I'm not the OP, but that property reads:

drm_info | grep bpc
│   │       ├───"max bpc": range [8, 16] = 10
│   │       ├───"max bpc": range [8, 16] = 16
│   │       ├───"max bpc": range [8, 16] = 16
│           ├───"max bpc": range [8, 16] = 16

The only 10 is on the only DP that's connected (Alienware AW3423DWF) so I imagine it is indeed working at 10-bit.

[emersion]

Yeah, there's nothing Sway can do here. The kernel driver picks a different bpc and we have no control over that.

[e00E]

You shouldn't have closed my issue because of someone else's drm info. Here is mine drm_info.txt .

"max bpc": range [8, 16] = 8
"max bpc": range [8, 16] = 8
"max bpc": range [8, 16] = 16
"max bpc": range [8, 16] = 16

This was captured while 10 bit was again not working. As I said in the main post, it's fickle.

If this is isn't a Sway bug, then is it a kernel bug? Where can I report it? It seems like a bug somewhere because it reliably works on Windows with the same hardware.

[emersion]

Hm, sounds like that one has the connected connector with max bpc = 8, and a 10-bit buffer on the primary plane. Probably a bug somewhere.

Did you toggle the render bit depth at runtime or something? Because that probably won't bump the max bpc.

[e00E]

My sway config contains render_bit_depth 10 for the monitor. I didn't toggle this while sway was running. I do use this monitor from several computers and change which input the monitor is displaying in the monitor settings sometimes. I also sometimes turn off the monitor while Sway is running. Maybe this is more bug prone.

I also have a second monitor that supports 10 bit. With that monitor I have no way of verifying whether it is getting 10 bit input because its menu doesn't show this information. I unplugged that monitor before capturing the drm info to make it less confusing.

I'm going to do another test now where I reboot with the other monitor unplugged and without changing any inputs on the first monitor. We'll see if anything about the drm info changes.

[e00E]

drm2.txt was captured on the tty before starting sway. drm3.txt was capture after starting sway. The monitor reported 8 bits while it was captured.

I will try to capture an info when I see 10 bit working.

[Kagukara]

I'm getting the same, max bpc reporting 8. Let me know what I can do to help provide more information.

Taken after a reboot in tty1: drm_info-reboot_tty1.txt Taken in sway after running it in tty1: drm_info-sway.txt

EDIT: I got max bpc to output 10. What I had to do was toggle temporarily the mode the display was using so I ran a mode my display wasn't using:

swaymsg 'output "Samsung Electric Company Odyssey G7 H1AK500000" mode 3840x2160@120.000Hz'

drm_info | grep bpc output:

│   │       ├───"max bpc": range [8, 16] = 10
│   │       ├───"max bpc": range [8, 16] = 16
│   │       ├───"max bpc": range [8, 16] = 16
│           ├───"max bpc": range [8, 16] = 16

Then back to my default:

swaymsg 'output "Samsung Electric Company Odyssey G7 H1AK500000" modeline 1498.25 3840 4192 4616 5392 2160 2163 2168 2316 -hsync +vsync'

Here is the output of drm_info after toggling the mode: drm_info-toggled_mode.txt

I also have to do this when waking up from sleep,