I reverted the offending commit in reform-debian-packages as a MR:
Once the pipeline is done, you will be able to add this to your sources.list and install updated mesa from that pipeline run:
deb [trusted=yes arch=arm64] https://source.mnt.re/reform/reform-debian-packages/-/jobs/7794/artifacts/raw/repo reform main
Thank to Lukas, above MR was merged and the resulting patched mesa packages with version 25.0.0-1+reform1 are now in the MNT repositories. Please try out if those packages fix your problem. Thank you!
I can confirm the update works. Issue resolved.
Thank you everybody for your help in fixing this! Especially big thanks to @deianara for bisecting mesa and finding the offending commit. This would’ve taken me much longer.
I reported the issue upstream here: panfrost mesa 25 regression: occasional flicker on BananaPI CM4 with Arm Mali-G52 on MNT Reform and MNT Pocket Reform (#12718) · Issues · Mesa / mesa · GitLab
I big thank you also to all the users of Debian unstable on the Reform. It is certainly very annoying to run into these kind of issues on a regular basis but on the up side, this means that the next stable release will not have this issue in it. So thank you!
I am now on 25.0.0-1+reform1 and haven’t noticed a single flicker. Thank you for all your work on this @josch! I wouldn’t have known about meson devenv without you, and thank you very much for filing bugs in the appropriate places.
Side note — my mesa builds only took about 40 minutes at worst, I wonder why we saw such big differences on the same CPU?
I had a lot of trouble reproducing this because the flickers were so seldom. I started out with just installing all the build dependencies and then running meson and ninja just as you did. But with that strategy I ran into situations were mesa 25 gave me no flicker at all and then there were flickers with mesa 24.3.4. That made no sense at all. I blamed the fact that I don’t really have an idea how software sources the bits it needs to render stuff to the screen and maybe it re-used the stuff I had installed in /usr even though I was inside meson devenv. And then there was the issue with rebooting where I sometimes stopped seeing flickers completely unless I rebooted. So I thought that either my software was using the bits from /usr or maybe it wasn’t mesa that was at fault but maybe something changed with the Debian configure flags or maybe the configure flags were supposed to change for some component but did not? So to rule all of that out I threw everything away, started from a vanilla system image and then used sbuild to rebuild the mesa Debian package. Since the system image was running from an SD card there was also no swap and building with more than 2 concurrent processes led to OOM issues. So a build took 2 hours because:
The last point also let me waste a lot of time because the Debian patch system uses patch and not git am which means:
And then it was not just a simple patch stack but two patch stacks: one to go back from 24.3.4 to the common merge base at 24.3-branchpoint which involves reverting ~300 commits and then another patch stack to go from 24.3-branchpoint to 25.0.0 which were the remaining ~3800 commits.
So, bisecting without git was not fun and not being able to see the flickers reliably was even less fun. Combine that with the A311D spending tons of time unapplying and then re-applying ~4000 patches and me fixing all the errors involving CRLF line endings and binary blobs in patches. Each bisection step took a bit more than 2 hours…
@deianara @Savasten @wakest There has been an update and I wanted to make you aware of it in case something breaks for you. While patching mesa works, we’d really like to avoid having to do that as building mesa takes a while and we are doing it for four architectures on the MNT gitlab CI. Personally, I’d also rather not build mesa regularly for the whole 2 years that Debian Trixie will be offered on reform.debian.net.
So today I pinged Neil Armstrong in the #panfrost IRC channel and Chris Healy replied with the suggestion that instead of patching mesa, we could also patch the kernel instead. Lukas prepared this MR, implementing that idea: a311d: disable afbc 32x8 support in display planes to work around sync glitches with latest mesa (!90) · Merge requests · Reform / reform-debian-packages · GitLab
I tested the result and it removed the flicker effect even when using the unpatched mesa straight from Debian unstable. The MR got thus merged into main and the MNT repositories are now serving the Linux kernel with this change.
So, if you want to try this out, upgrade to the latest kernel and install mesa from unstable. If you have not upgraded for a bit, it should be enough to upgrade mesa normally as the MNT repos are not serving a patched version of mesa anymore so apt will use the version from Debian unstable again.
Please shout in case anything breaks for you!
Thank you @josch I have removed the patched mesa build. The flickering is much better. I still get a random refresh glitch. This doesn’t bother me. It could be caused by other issues I have created.
Thank you for your continuing work on this! I’ve just upgraded and haven’t noticed the flickering, I’ll update here if that changes.
I recently upgraded the packages on my system (Pocket Reform i.MX8MP) and suddenly having extremely noticeable flickering issues. Should I try to downgrade mesa, or it is not necessary anymore? It seems I am on version 25.0.4-1.
Hi @blipblub – this topic is about flickering on a311d with panfrost. The imx8mplus uses etnaviv/vivante graphics, so if you see strong flickering, then it’s likely a different issue. Can you create a new topic about your issue together with the relevant output from reform-check? Thank you!