Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
On Mon, Aug 25, 2025 at 05:11:24PM +, James Addison wrote: > Thanks, Maxime. > > On Mon, 28 Jul 2025 at 09:47, Maxime Ripard wrote: > > > > Hi, > > > > On Sat, Jul 12, 2025 at 06:32:53PM +0200, Ben Hutchings wrote: > > [...] > > > [...] > > > > > > 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? > > > > 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. > > 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) Yes, it is https://lore.kernel.org/dri-devel/[email protected]/#t I've ping'd the msm maintainers after sending that mail, I'll try again once the holiday season is over. Maxime signature.asc Description: PGP signature
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Thanks, Maxime. On Mon, 28 Jul 2025 at 09:47, Maxime Ripard wrote: > > Hi, > > On Sat, Jul 12, 2025 at 06:32:53PM +0200, Ben Hutchings wrote: > [...] > > [...] > > > > 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? > > 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. 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
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Hi, On Sat, Jul 12, 2025 at 06:32:53PM +0200, Ben Hutchings wrote: > Hi all, > > On Tue, 2025-04-29 at 10:40 +, James Addison wrote: > > Control: tags -1 patch > > > > Hi Diederik, Maxime, > > > > On Wed, 10 May 2023 19:20:45 +0200, Diederik wrote: > > > Control: forwarded -1 > > > https://lore.kernel.org/all/[email protected]/ > > > > I've found the time to test Maxime's vc4 dlist deferral patch -- with > > 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. > [...] > > 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? 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 signature.asc Description: PGP signature
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Hi all, On Tue, 2025-04-29 at 10:40 +, James Addison wrote: > Control: tags -1 patch > > Hi Diederik, Maxime, > > On Wed, 10 May 2023 19:20:45 +0200, Diederik wrote: > > Control: forwarded -1 > > https://lore.kernel.org/all/[email protected]/ > > I've found the time to test Maxime's vc4 dlist deferral patch -- with > 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. [...] 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. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Control: tags -1 patch Hi Diederik, Maxime, On Wed, 10 May 2023 19:20:45 +0200, Diederik wrote: > Control: forwarded -1 > https://lore.kernel.org/all/[email protected]/ I've found the time to test Maxime's vc4 dlist deferral patch -- with 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 Origin: https://lore.kernel.org/all/[email protected]/ Author: Maxime Ripard Acked-by: James Addison Bug-Debian: https://bugs.debian.org/1035878 Last-Update: 2025-04-29 Description: drm/vc4: hvs: Defer dlist slots deallocation During normal operations, the cursor position update is done through an asynchronous plane update, which on the vc4 driver basically just modifies the right dlist word to move the plane to the new coordinates. . However, when we have the overscan margins setup, we fall back to a regular commit when we are next to the edges. And since that commit happens to be on a cursor plane, it's considered a legacy cursor update by KMS. . The main difference it makes is that it won't wait for its completion (ie, next vblank) before returning. This means if we have multiple commits happening in rapid succession, we can have several of them happening before the next vblank. . In parallel, our dlist allocation is tied to a CRTC state, and each time we do a commit we end up with a new CRTC state, with the previous one being freed. This means that we free our previous dlist entry (but don't clear it though) every time a new one is being committed. . Now, if we were to have two commits happening before the next vblank, we could end up freeing reusing the same dlist entries before the next vblank. . Indeed, we would start from an initial state taking, for example, the dlist entries 10 to 20, then start a commit taking the entries 20 to 30 and setting the dlist pointer to 20, and freeing the dlist entries 10 to 20. However, since we haven't reach vblank yet, the HVS is still using the entries 10 to 20. . If we were to make a new commit now, chances are the allocator are going to give the 10 to 20 entries back, and we would change their content to match the new state. If vblank hasn't happened yet, we just corrupted the active dlist entries. . A first attempt to solve this was made by creating an intermediate dlist buffer to store the current (ie, as of the last commit) dlist content, that we would update each time the HVS is done with a frame. However, if the interrupt handler missed the vblank window, we would end up copying our intermediate dlist to the hardware one during the composition, essentially creating the same issue. . Since making sure that our interrupt handler runs within a fixed, constrained, time window would require to make Linux a real-time kernel, this seems a bit out of scope. . Instead, we can work around our original issue by keeping the dlist slots allocation longer. That way, we won't reuse a dlist slot while it's still in flight. In order to achieve this, instead of freeing the dlist slot when its associated CRTC state is destroyed, we'll queue it in a list. . A naive implementation would free the buffers in that queue when we get our end of frame interrupt. However, there's still a race since, just like in the shadow dlist case, we don't control when the handler for that interrupt is going to run. Thus, we can end up with a commit adding an old dlist allocation to our queue during the window between our actual interrupt and when our handler will run. And since that buffer is still being used for the composition of the current frame, we can't free it right away, exposing us to the original bug. . Fortunately for us, the hardware provides a frame counter that is increased each time the first line of a frame is being generated. Associating the frame counter the image is supposed to go away to the allocation, and then only deallocate buffers that have a counter below or equal to the one we see when the deallocation code should prevent the above race from occuring. --- drivers/gpu/drm/vc4/vc4_crtc.c | 10 +- drivers/gpu/drm/vc4/vc4_drv.h | 15 ++- drivers/gpu/drm/vc4/vc4_hvs.c | 208 ++--
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Control: reassign -1 src:linux 6.1.25-1 Control: tag -1 upstream Control: forwarded -1 https://lore.kernel.org/all/[email protected]/ On Wednesday, 10 May 2023 19:04:55 CEST James Addison wrote: > Followup-For: Bug #1035878 > Control: reassign -1 linux-image-6.1.0-8-arm64 > > 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/013f247b89b6fa55724cb73a820cadc > ae745d1ee It seems it was proposed upstream, but hasn't had any response thus far. signature.asc Description: This is a digitally signed message part.
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Followup-For: Bug #1035878 Control: reassign -1 linux-image-6.1.0-8-arm64 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
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Followup-For: Bug #1035878 Control: forwarded -1 https://github.com/raspberrypi/linux/issues/5462
Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement
Package: raspi-firmware
Severity: normal
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
