u/185EDRIVER

The typical Google user circle blob that you can click on doesn't seem to exist in the new Gemini app?

I've been daily-driving COSMIC on a Dell XPS 16 (DA16260) with the Tandem OLED panel and built out an experimental HDR pipeline because the desktop can't currently signal HDR on its own. After a fair bit of grinding I have HDR mode actually engaging on the panel, but colors look noticeably washed/desaturated compared to SDR mode and I'm running out of ideas on what's wrong. Hoping someone here has hit this and can shortcut me to the answer.

Hardware

• Dell XPS 16 (DA16260), Intel Panther Lake, Tandem OLED 3.2K@120Hz
• xe driver (not i915), Arch / CachyOS kernel
• Panel reports via EDID: DCI-P3-ish primaries, BT.2020/SMPTE ST 2084 HDR10 support, 525 nit peak (10% rect) / 400 nit full-coverage, 0.0005 nit blacks
• Connector exposes Colorspace enum (DCI-P3_RGB_D65, BT2020_RGB) and HDR_OUTPUT_METADATA blob property as expected

What works

• Connector goes into HDR mode: I set the Colorspace property + write the HDR_OUTPUT_METADATA blob (PQ EOTF, BT.2020 or DCI-P3 primaries, 525-nit max / 0.0005-nit min mastering luminance) + force max_bpc=10. Atomic commits accept and stay accepted.
• 10-bit Abgr2101010 swapchain end-to-end, no banding.
• Postprocess shader transforms desktop content: sRGB → linear → Rec.709→target gamut matrix → reference-white scale → inverse PQ EOTF → 10-bit framebuffer.
• VRR + HDR coexisting (had to disable PSR via xe.enable_psr=0 xe.enable_panel_replay=0 on the kernel cmdline — PSR + HDR + VRR was racing on this driver and freezing the session).

What's wrong

Colors look less saturated and slightly dim compared to running the same content in SDR mode. Brightness feels reasonable when ref-white is in the 250-500 range (clamped by 400-nit full-coverage ABL anyway), but the overall image looks "less punchy" in HDR than SDR.

I've tried every combination I can think of:

• BT.2020 colorspace tag + BT.2020 metadata primaries + Rec.709→BT.2020 matrix in shader
• DCI-P3 colorspace tag + DCI-P3 metadata primaries + Rec.709→DCI-P3 matrix in shader
• 0% gamut conversion (raw sRGB through, panel does its own thing) → washed
• 100% gamut conversion → still washed
• Reference white from 80 to 600 nits

In every case, SDR session looks more saturated and contrasty than HDR session. Same wallpaper, same windows.

Limitations / known unknowns

• I don't have another DCI-P3 OLED HDR-capable laptop to A/B against, so I can't confirm whether this is panel-specific weirdness or genuinely a math/pipeline bug.
• I don't know what GNOME's mutter or KWin do differently on the same xe + Tandem OLED hardware (haven't installed them on this machine yet).
• Auto Brightness Limiting (ABL) on this panel kicks in around 400 nits full-screen — I don't know if there's a way to coordinate that compositor-side or if it's purely panel firmware.
• Panel's native primaries are BETWEEN DCI-P3 and BT.2020 (R/G closer to P3, B closer to BT.2020). Neither standard exactly matches, so some firmware-side mapping is unavoidable.

Code is public

• HDR shader + KMS pipeline: https://github.com/jibsta210/cosmic-comp/tree/feat/hdr-experiment
• smithay atomic-DRM HDR state staging: https://github.com/jibsta210/smithay/tree/feat/hdr-experiment
• Tiny GUI to live-tune the shader: https://github.com/jibsta210/cosmic-hdr-tuner

The shader is at cosmic-comp/src/backend/render/shaders/offscreen.frag (the color_mode == 5.0 branch). Math sources: BT.2087 Annex 1 for Rec.709→BT.2020 matrix, ST 2084 / BT.2100 for PQ inverse EOTF, BT.2408 for ref-white concept.

Asks

If you've seen washed-out HDR on Linux on a DCI-P3 OLED panel and figured it out — what was it? Specifically:

1. For a panel that reports (DCI-P3, BT.2020/SMPTE ST 2084) in DisplayID, is the canonical HDR10 transmission BT2020_RGB + BT.2020 metadata primaries? Or do P3-native panels actually want DCI-P3_RGB_D65 + DCI-P3 primaries?
2. Is sRGB → linear → matrix → PQ the right order, or should the matrix run in a different space?
3. Is there a known xe driver param or kernel quirk I'm missing that affects HDR output color?
4. Anyone gotten HDR working "correctly looking" in mutter/KWin on a similar Tandem OLED — any chance of a dmesg snippet or settings dump for comparison?
5. EDID quirks for these Dell XPS 16 panels?

Open to "you're obviously missing X" answers — could be something basic.

Honest disclosure: this was AI-paired iteration. I drove the architecture and field-tested every cycle on the actual panel; Claude helped chew through the GLSL/atomic-DRM details fast.

I've been daily-driving COSMIC on a Dell XPS 16 (DA16260) with the Tandem OLED panel and built out an experimental HDR pipeline because the desktop can't currently signal HDR on its own. After a fair bit of grinding I have HDR mode actually engaging on the panel, but colors look noticeably washed/desaturated compared to SDR mode and I'm running out of ideas on what's wrong. Hoping someone here has hit this and can shortcut me to the answer.

Hardware

• Dell XPS 16 (DA16260), Intel Panther Lake, Tandem OLED 3.2K@120Hz
• xe driver (not i915), Arch / CachyOS kernel
• Panel reports via EDID: DCI-P3-ish primaries, BT.2020/SMPTE ST 2084 HDR10 support, 525 nit peak (10% rect) / 400 nit full-coverage, 0.0005 nit blacks
• Connector exposes Colorspace enum (DCI-P3_RGB_D65, BT2020_RGB) and HDR_OUTPUT_METADATA blob property as expected

What works

• Connector goes into HDR mode: I set the Colorspace property + write the HDR_OUTPUT_METADATA blob (PQ EOTF, BT.2020 or DCI-P3 primaries, 525-nit max / 0.0005-nit min mastering luminance) + force max_bpc=10. Atomic commits accept and stay accepted.
• 10-bit Abgr2101010 swapchain end-to-end, no banding.
• Postprocess shader transforms desktop content: sRGB → linear → Rec.709→target gamut matrix → reference-white scale → inverse PQ EOTF → 10-bit framebuffer.
• VRR + HDR coexisting (had to disable PSR via xe.enable_psr=0 xe.enable_panel_replay=0 on the kernel cmdline — PSR + HDR + VRR was racing on this driver and freezing the session).

What's wrong

Colors look less saturated and slightly dim compared to running the same content in SDR mode. Brightness feels reasonable when ref-white is in the 250-500 range (clamped by 400-nit full-coverage ABL anyway), but the overall image looks "less punchy" in HDR than SDR.

I've tried every combination I can think of:

• BT.2020 colorspace tag + BT.2020 metadata primaries + Rec.709→BT.2020 matrix in shader
• DCI-P3 colorspace tag + DCI-P3 metadata primaries + Rec.709→DCI-P3 matrix in shader
• 0% gamut conversion (raw sRGB through, panel does its own thing) → washed
• 100% gamut conversion → still washed
• Reference white from 80 to 600 nits

In every case, SDR session looks more saturated and contrasty than HDR session. Same wallpaper, same windows.

Limitations / known unknowns

• I don't have another DCI-P3 OLED HDR-capable laptop to A/B against, so I can't confirm whether this is panel-specific weirdness or genuinely a math/pipeline bug.
• I don't know what GNOME's mutter or KWin do differently on the same xe + Tandem OLED hardware (haven't installed them on this machine yet).
• Auto Brightness Limiting (ABL) on this panel kicks in around 400 nits full-screen — I don't know if there's a way to coordinate that compositor-side or if it's purely panel firmware.
• Panel's native primaries are BETWEEN DCI-P3 and BT.2020 (R/G closer to P3, B closer to BT.2020). Neither standard exactly matches, so some firmware-side mapping is unavoidable.

Code is public

• HDR shader + KMS pipeline: https://github.com/jibsta210/cosmic-comp/tree/feat/hdr-experiment
• smithay atomic-DRM HDR state staging: https://github.com/jibsta210/smithay/tree/feat/hdr-experiment
• Tiny GUI to live-tune the shader: https://github.com/jibsta210/cosmic-hdr-tuner

The shader is at cosmic-comp/src/backend/render/shaders/offscreen.frag (the color_mode == 5.0 branch). Math sources: BT.2087 Annex 1 for Rec.709→BT.2020 matrix, ST 2084 / BT.2100 for PQ inverse EOTF, BT.2408 for ref-white concept.

Asks

If you've seen washed-out HDR on Linux on a DCI-P3 OLED panel and figured it out — what was it? Specifically:

1. For a panel that reports (DCI-P3, BT.2020/SMPTE ST 2084) in DisplayID, is the canonical HDR10 transmission BT2020_RGB + BT.2020 metadata primaries? Or do P3-native panels actually want DCI-P3_RGB_D65 + DCI-P3 primaries?
2. Is sRGB → linear → matrix → PQ the right order, or should the matrix run in a different space?
3. Is there a known xe driver param or kernel quirk I'm missing that affects HDR output color?
4. Anyone gotten HDR working "correctly looking" in mutter/KWin on a similar Tandem OLED — any chance of a dmesg snippet or settings dump for comparison?
5. EDID quirks for these Dell XPS 16 panels?

Open to "you're obviously missing X" answers — could be something basic.

Honest disclosure: this was AI-paired iteration. I drove the architecture and field-tested every cycle on the actual panel; Claude helped chew through the GLSL/atomic-DRM details fast.

I built a hacky solution to add hotpspotting back but I was very surprised to see this fully missing from the UI...

I'm going to work on a full UI integration into the wifi ui

LONG Trulieve (TRUL) thesis:

• DOJ just rescheduled medical marijuana from Schedule I to Schedule III yesterday
• This removes the 280E provision that prohibits businesses from deducting business expenses, making the effective tax rate 25% (down from 60%+ for Schedule I companies)
• FCF should go up 2-3x
• Recreational marijuana has not been rescheduled yet but there is a hearing on June 29th to do so, the administration purposefully did a 2 track process to avoid challenges
• TRUL also has $630MM of Uncertain Tax Position (UTP) that could be reclaimed, the DOJ order yesterday "encourages" the Treasury and IRS to consider "retrospective relief" from Section 280E
• TRUL trades at 5.5x EBITDA, 60% gross margin, 36% EBITDA margin
• First wave buying would just be from cash flow inflection to delever and grow
• Second wave buying would be massive if the Feds provide a new Cole memo or SAFE banking act to allow marijuana companies get proper banking services, get uplisted to NASDAQ (require custody services), and US fund flows
• TRUL should be up 50-100% on cash flow alone, and possibly 100%+ if recreational marijuana is also rescheduled and/or expanded banking services
• No narcotics have been permitted for one use but not another; chances of a rescheduling of recreational marijuana is high

In at 12.04 for 3500 shares

LONG Trulieve (TRUL) thesis:

• DOJ just rescheduled medical marijuana from Schedule I to Schedule III yesterday
• This removes the 280E provision that prohibits businesses from deducting business expenses, making the effective tax rate 25% (down from 60%+ for Schedule I companies)
• FCF should go up 2-3x
• Recreational marijuana has not been rescheduled yet but there is a hearing on June 29th to do so, the administration purposefully did a 2 track process to avoid challenges
• TRUL also has $630MM of Uncertain Tax Position (UTP) that could be reclaimed, the DOJ order yesterday "encourages" the Treasury and IRS to consider "retrospective relief" from Section 280E
• TRUL trades at 5.5x EBITDA, 60% gross margin, 36% EBITDA margin
• First wave buying would just be from cash flow inflection to delever and grow
• Second wave buying would be massive if the Feds provide a new Cole memo or SAFE banking act to allow marijuana companies get proper banking services, get uplisted to NASDAQ (require custody services), and US fund flows
• TRUL should be up 50-100% on cash flow alone, and possibly 100%+ if recreational marijuana is also rescheduled and/or expanded banking services
• No narcotics have been permitted for one use but not another; chances of a rescheduling of recreational marijuana is high

Position - 3500 shares @$12.04

I set it to 0 or 100 it is still the same speed?