Vouch request for willmtemple

[willmtemple]

(Sorry, I missed the note to keep this concise so I edited it to put details in a collapsible thing

Repos I am interested in contributing to

I'm hoping to contribute some fixes and enhancements to aquamarine, Hyprland, hyprland-protocols, hyprsunset, and xdg-desktop-portal-hyprland, among others (anything would be on the table, I hope).

What I want to contribute right now

It's a long list, all about issues in the HDR metadata and compositing pipeline. I've been studying compositing and colorimetry for a few months and think I could help with this in Hyprland.

List of issues I want to look at

• aquamarine stops scanning EDID extensions after the first CTA block, missing HDR metadata and colorimetry in further extension blocks (I PR'd this against aquamarine earlier which is how I found out that vouching is required).

CTMs:

• CTMs are wildly inaccurate on HDR outputs, IMO requiring a protocol revision to hyprland-ctm-control-v1 that allows negative matrix elements with finer precision, built in linear light with defined primaries
• hyprsunset then needs to speak the revised protocol and calculate CTMs accurately
• hyprland then needs to speak the revised protocol and apply the CTMs accurately
• hyprland needs to apply CTMs in the cm shader on linear light instead of using KMS

xdph portal layer:

• hyprland-toplevel-export-v1 has no way to distinguish a transient failure from a failure that occurred because a toplevel was closed (maybe intended and FAILED should always mean to close the stream?)
• xdph does not emit portal Closed events in screenshares when a window closes and the capture session becomes FAILED
• xdph should consider using ext-iCC instead now that hyprland supports it (any portal impl that calls ext-iCC could work with hyprland, so maybe xdph is not even needed in that case)
• xdph does not tag portal sessions with colorimetry information

hyprland HDR compositing:

• SDR brightness level is applied inconsistently across surfaces. Reference white image data should composite to the same paper white as SDR content at full white in every configuration, but it doesn't because the 0.2/80 nit reference is confused for an output target luminance incorrectly.
• When bitdepth is not explicit, it should automatically switch to 10 bit if cm = hdr/hdredid is set (there are FIXMEs related to this in the code), because the default is to do nonstandard 8 bit PQ and display a config warning in the session.
• 0.2/80 nit reference is for an old CRT and 0/203 is a much better default per BT.2408 (this will look much better out of the box on virtually every HDR display with default settings).
• Windows/scRGB presets have wrong default luminances until a game sends metadata, so some games (tested with Elden Ring) are washed out.
• Capture formats are cached and go stale when an output switches from 8 bit to 10 bit scanout, which can deadlock capture clients.
• HDR mastering metadata goes stale when config is changed, because it's only recalculated on a transition to HDR from SDR.
• tone mapping is slightly off and runs in the wrong color spaces (though the existing implementation is quite serviceable)
• captures have several issues with gamut/tone mapping (or lack thereof) for HDR content when the SDR brightness or max luminance is raised to an acceptable level
• a hyprctl command to dump CM information would be extremely useful for debugging.
• etc. etc.

I have some patches ready to go (aquamarine, hyprland-protocols, hyprsunset) to get discussions started, and some that I'm reworking, testing, deslopping parts that AI helped me write (especially its insane overwrought prose) etc..

Why the above bug / feature specifically?

I've been using hyprland for around two years. I am developing a small native cross platform application framework that supports compositing in fp16 extended-linear sRGB (a.k.a. scRGB), which requires me to run Hyprland with "always on" HDR (cm = hdr/hdredid), and I have many bugs/annoyances with this setup. I can provide photos/videos, data, measurements, etc. that demonstrate the problems and motivate the fixes. It's very difficult to get an HDR desktop experience that looks right and has screencaptures that look good on current hyprland, though the experience has materially improved over the last several versions. Though I'm not a particularly experienced developer with modern C++, I can help address those issues.

I'd also like to, in the future when the Wayland protocol proposals have matured, support efforts to improve color-managed capturing (proposal is ext-image-capture-color-management-v1) for use cases like recording HDR video footage of the desktop, capturing HDR screenshots, etc. I do also have a separate prototype of this using a scuffed implementation of the proposed protocol in hyprland and grim.

Thank you for all your hard work on my favorite wayland desktop experience, and I hope to contribute myself!

I acknowledge that:

• I have read the AI Usage Policy and agree to follow it.

• I have read the Code of Conduct and agree to follow it.

• I wrote this request with my own hands, my own keyboard, and in my own words.

[vaxerski]

Sounds good. Welcome aboard! You might get on well with ujin, he's the one who did most CM stuff in hyprland.