Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #87125 > unrolled thread

Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement James Addison <jay@jp-hosting.net> - 2025-04-29 12:50 +0200
    Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement Ben Hutchings <ben@decadent.org.uk> - 2025-07-12 18:40 +0200
      Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement Maxime Ripard <mripard@kernel.org> - 2025-07-28 12:00 +0200
        Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement James Addison <jay@jp-hosting.net> - 2025-08-25 19:20 +0200
          Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement Maxime Ripard <mripard@kernel.org> - 2025-08-27 12:10 +0200

#87125 — Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement

[Multipart message — attachments visible in raw view] — view raw

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/20230127-rpi-cursor-corruption-v2-1-1f97bd00df01@cerno.tech/

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

[toc] | [next] | [standalone]

#88382

[Multipart message — attachments visible in raw view] — view raw

Hi all,

On Tue, 2025-04-29 at 10:40 +0000, 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/20230127-rpi-cursor-corruption-v2-1-1f97bd00df01@cerno.tech/
> 
> 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

[toc] | [prev] | [next] | [standalone]

#88574

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Sat, Jul 12, 2025 at 06:32:53PM +0200, Ben Hutchings wrote:
> Hi all,
> 
> On Tue, 2025-04-29 at 10:40 +0000, 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/20230127-rpi-cursor-corruption-v2-1-1f97bd00df01@cerno.tech/
> > 
> > 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

[toc] | [prev] | [next] | [standalone]

#88980

Thanks, Maxime.

On Mon, 28 Jul 2025 at 09:47, Maxime Ripard <mripard@kernel.org> 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

[toc] | [prev] | [next] | [standalone]

#89000

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 25, 2025 at 05:11:24PM +0000, James Addison wrote:
> Thanks, Maxime.
> 
> On Mon, 28 Jul 2025 at 09:47, Maxime Ripard <mripard@kernel.org> 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/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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web