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 <[email protected]> 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. > > 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. > > I found the extracted Windows DSDT \_SB.PEP0.G0MD F-state EXIT block > enables disp_cc_mdss_rscc_ahb_clk and disp_cc_mdss_rscc_vsync_clk; > could this relate? RSCC being the RPMh bridge subblock. Also, could > any of the *1_CLK or MDSS_INT2_GDSC entries in dispcc-x1e80100.c lack > setup? RSCC should not affect these blocks. -- With best wishes Dmitry
