Re: [BUG] qcom: x1: GAMMA_LUT corruption on DPMS wake

[Daniel J Blueman <daniel@quora.org>]

On Sun, 14 Jun 2026 at 18:27, Daniel J Blueman <daniel@quora.org> wrote:
> On Mon, 1 Jun 2026 at 13:37, Daniel J Blueman <daniel@quora.org> wrote:
> > Since Adreno X1-85 GAMMA_LUT support was introduced in Linux v7.0 (eg
> > Ubuntu 26.04), when waking from DPMS-off, palette corruption is
> > frequently seen; this manifests as purple banding. If GNOME night
> > light or similar is enabled, the visual impact is greater.
> >
> > Further, on larger panel monitors or laptops eg the Lenovo Yoga Slim
> > 7x (2944x1840), a second INT2 block is used for the right half of the
> > screen, which may remain totally blank on wake; major usability
> > impact.
> >
> > Intuitively, the symptoms feel like the LUT SRAM clock isn't being
> > driven soon enough during the wakeup, thus state loss may depend on
> > silicon binning/variation or related. No such symptom is seen in
> > Windows on the same hardware. I found a workaround supporting this
> > mechanism is to activate the GNOME night light and adjust the slider
> > to update the LUT - any black right half of the screen always
> > reappears.
> >
> > Please can someone with X1-85 Adreno insight check the Linux clock and
> > power domain behaviour around GC_EN, Layer Mixer, INTerFace and INT2
> > on DPMS wake? Happy to test changes; this is a stunning platform
> > otherwise.
> ...
> > Link: https://gitlab.freedesktop.org/drm/msm/-/work_items/89
>
> Just a heads-up on this with additional findings. Note this issue
> could be the only remaining daily friction on X1 laptops with suspend,
> once my video decode reboot workaround or similar is merged. Also note
> in my case, without GNOME night light active, only a few LUT entries
> render purple so visual artifacts often go unnoticed until a gradient
> eg in an image is visible.
>
> From DPMS wake on a dual-LM panel (>2560 pixels wide) with
> INTF_5/DSPP_0 (master) and INTF_6/DSPP_1, I find DSPP_1's registers
> are intermittently unresponsive just after MDSS resume. DSPP_0 doesn't
> exhibit this issue, suggesting some missing slave/second unit setup,
> despite booting clk_ignore_unused pd_ignore_unused.

Guys, further debug reveals the Windows driver (which doesn't exhibit
the issue) doesn't use the same register access as Linux to reprogram
all LUT entries on DPMS wake. Instead, it appears to submit a DMA
descriptor to fetch LUT values which get internally loaded in a stable
manner.

Is it possible for Qualcomm to attempt a minimal fix, or share the DMA
description struct and doorbell/completion register offsets and
related so the community can?

Also, it would be good to hear if anyone with an X1E running a 7.0
kernel or newer with a 4K monitor *doesn't* see palette corruption
across DPMS sleep-wake, as this could indicate another possible
solution.

Thanks,
  Dan
-- 
Daniel J Blueman