Dear Maintainer,

I've installed a RPi 400 system using a regular build of Debian Installer
(bookworm RC2), and have begun using the official RPi firmware (as distributed
in the 'raspi-firmware' bookworm package - including bootcode.bin) to start the
the kernel.

During an X-based LXDE session, I see visual 'speckling' (static-like noise
that blits across the lower half-or-so of the display, mostly with dark
greenish and dark bluish pixels) when moving the mouse pointer.


NOTE: There are _two_ micro-HDMI ports on the RPi 400.  This problem only
occurs when the HDMI cable is connected to the port closest to the keyboard
indicator lights (capslock, numlock).  The problem _does not_ occur when the
HDMI cable is connected to the port closest to the USB-C power supply port.


Repro details:

Moving the pointer through particular areas of the display seem to cause the
flickering/speckling more repeatably.  The lower 40-or-so pixels of the screen
in particular (where the LXDE menubar appears by defaul) seems to be a boundary
that causes the problem fairly reliably.

Note that when pointer/cursor movement _stops_, the visual corruption also
stops occurring.  In other words: the condition appears on-screen temporarily
during the mouse pointer movement.


Additional details:

  * The system is running Debian kernel 6.1.0-8 from linux-image-arm64
    6.1.25-1

  * The problem is also replicable using the latest '*.{elf,dat,bin}' files
    from the upstream raspberrypi/firmware version 1.20230405 release.

  * The devicetree 'compatible' entry for the gpu is:

  $ cat /proc/device-tree/gpu/compatible
  brcm,bcm2711-vc5

  * The vc4 video driver appears to initialize fine according to dmesg (I don't
    see any errors).

  * The vc4 driver is in use as a framebuffer device, I think.

  $ dmesg --notime | grep -i vc4 | tail -n 2
  [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
  vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

  * I've attempted to use the 'config_hdmi_boost'[1] setting from the upstream
    firmware to resolve the problem, since it mentions speckling (in fact, it's
    where I learned the term 'speckling') specifically, but this has not had
    any effect.  The documentation there does mention that the option is
    ignored on RPi4, and it seems possible that that may also apply to RPi400.

  * Reducing the resolution of the desktop does not reduce or eliminate the
    speckling.


Thank you for any help / suggestions,
James

[1] - https://www.raspberrypi.com/documentation/computers/config_txt.html#config_hdmi_boost

The RPi team suggested that this is likely to be a Linux kernel issue, and I've
tested an updated v6.1.21 kernel build of theirs (including the likely fix[1])
that does resolve the problem.

[1] - https://github.com/raspberrypi/linux/commit/013f247b89b6fa55724cb73a820cadcae745d1ee

Control: reassign -1 src:linux 6.1.25-1
Control: tag -1 upstream
Control: forwarded -1 https://lore.kernel.org/all/20230127-rpi-cursor-corruption-v2-1-1f97bd00df01@cerno.tech/

It seems it was proposed upstream, but hasn't had any response thus far.

Hi Diederik, Maxime,
minor adjustments to rebase against Debian's 6.12.22-1 kernel -- on an
rpi400 machine locally.

From testing two side-by-side kernel builds, one with the patch
applied, and one without it, I can attest that the patch does indeed
resolve the reported cursor/video speckling problem when using the
mini-HDMI port most-distant from the USB-C power port.

Note: the only modification required to rebase the patch was to
replace a conditional check for 'vc4->is_vc5' with 'vc4->gen ==
VC4_GEN_5' in a couple of the lines modified by the patch.  I've also
updated the line numbers to (hopefully) allow the patch to apply
cleanly without any fuzziness.

Thank you very much Maxime for providing the patch; please also find
my rebased version of it attached to this message.

Regards,
James

Hi all,
[...]

Looking at the previous posting of this patch upstream, it was not clear
to me why the patch wasn't applied.  Maxime, do you know what happened?

Would it be worth submitting James's updated patch as a v3?

Ben.

Hi,

If I remember well, my series was considered a workaround to a bug
triggered by an obsolete mechanism in the kernel.

So it was advocated that we should get rid of that mechanism instead,
and thus this series would be made irrelevant. However, removing that
mechanism triggered a few regressions in some drivers, so it never went
through, and my series was forgotten about.

It's been in limbo ever since.

Maxime

Thanks, Maxime.

Is that potential cleanup related to the legacy cursor update
mechanism?  The reason I ask: I found a LKML thread from Feb 2023
about that, and it mentions some MSM (Adreno?) regressions.

(I'm not hyperlinking to it yet though, in case I'm on the wrong track)

James

Yes, it is
https://lore.kernel.org/dri-devel/20220331152021.2671937-1-daniel.vetter@ffwll.ch/#t

I've ping'd the msm maintainers after sending that mail, I'll try again
once the holiday season is over.

Maxime