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

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On Sun, 12 Jul 2026 at 15:47, Daniel J Blueman <daniel@quora.org> wrote:
>
> On Sun, 12 Jul 2026 at 19:56, Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Sun, Jun 14, 2026 at 06:27:50PM +0800, Daniel J Blueman 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.
> >
> > Could you please check if increasing reg_bus_bw in msm_mdss.c would fix
> > the issue? It's not a proper fix yet, but it might help me to understand
> > the issue.
>
> Adjusting like so [1] didn't resolve the issue, however it was worth
> ruling out. Perhaps you could check with the Windows driver team why
> the DMA descriptor approach was used for LUT setup?

Thanks for the test.

SDE driver also uses LUT DMA, it's just another piece of code that has
not been ported from the downstream.


-- 
With best wishes
Dmitry