09:00 <kusma> mntirc: I'm really confused why this doesn't work on a311d for you. It works fine on my VIM3, which has the same display controller. Are you using some special setup of display planes etc?

09:01 <kusma> It could be that the display controller reports supporting this for all planes, but in reality only supporting it on some or something like that.

09:01 <kusma> I'm just running "plain" Weston on Debian on that board, BTW.

11:02 <bbrezillon> stepri01: if you push things to drm-misc-next, can you also take alarumbe's series?

12:17 <mntirc> kusma: here's how it looks like for 1 user, like the display is cutting out randomly. https://i.imgur.com/iSB84Ez.mp4 it happens on both sway and gnome on two different machine types (pocket and classic reform), the common denominator is both use DSI output.

12:18 <kusma> Heh, OK. DSI is a quite big difference from what I have here, yeah.

12:18 <mntirc> one more datapoint is that it doesn't seem to happen on rk3566 (which also has a g-52?) https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg2023313.html

12:18 <daniels> yeah, rockchip has their own display controller that has nothing to do with aml's

12:19 <kusma> It would be interesting to see if it happens with HDMI output.

12:19 <mntirc> kusma: good point, we can try that

12:19 <kusma> mntirc: Yeah, so this is almost certainly a problem with the meson display driver in the kernel, just triggered by Mesa by us enabling a previously unsupported mode.

12:20 <mntirc> kusma: ah, so this AFBC patch affects scanout? i need to catch up on the effects of it

12:20 <kusma> You really want to use 32x8 for scanout if you can, because that has better caching behavior, which should lead to both better performance and power consumption.

12:21 <kusma> mntirc: Well, Panfrost started advertising support for more DRM modifiers...

12:21 <mntirc> narmstrong: any ideas about this maybe ^ ?

12:21 <kusma> That means the display driver and Mesa will negotiate a diffrerent preferred mode.

12:21 <mntirc> narmstrong: mesa AFBC negatively impacting DSI scanout on a311d?

12:22 <mntirc> kusma: understood, thanks

12:22 <kusma> But in this case, it seems the display might have some issues handling the output.

12:22 <mntirc> kusma: hmm, it's independent on display model (and in classic this goes via TI dsi->eDP bridge)

12:22 <mntirc> so maybe something internal in a311d?

12:23 <kusma> Sorry, I meant the display-out

12:23 <mntirc> gotcha

12:23 <kusma> I honestly don't know enough about DSI etc to know if AFBC could even be carried over the wire all the way to the display there.

12:24 <daniels> looking at drivers/gpu/drm/meson/meson_venc.c, I wonder if the timings need to be adjusted to push more FIFO at 32x8 tiling?

12:24 <daniels> no AFBC isn't carried over the wire

12:37 <mntirc> ok, we can look into that and will keep the mesa revert patch in the meantime

12:39 <kusma> Yeah, keeping that revert that isn't going to make things worse than they were in 24.3 for you. But once it can reliably work for you, you probably want to switch on 32x8 support again.

13:18 <narmstrong> mntirc: so, the way afbc has been integrated into A311D, means yes it can miss a vsync on load

13:19 <narmstrong> but, otherwise it's the same

13:19 <narmstrong> AFBC has been integrated and validated with the ARM mali blob, so I'm pretty sure it works fine :-)

13:26 <mntirc> narmstrong: aha, thanks for confirming! so we need to tweak something about vsync or do you have any other hunches?

13:29 <kusma> Miss a vsync isn't the same as blacking out the display entirely for a frame, though?

13:49 <josch> hi, i have been reading the discussion re a311d flickers in the logs and just came by to say that i do see occasional (about twice per minute) flickers with hdmi

13:50 <josch> no idea if this supports the current hypothesis of the cause of the error or if it's a totally different thing

13:50 <josch> but reverting the AFBC commit also seems to have fixed it

13:53 <narmstrong> It should not black out, neither flicker, it should at worse duplicate a frame, if you encounter flickering it means you're either hitting a bandwidth issue or some HDMI signal issues, it may be caused by AFBC because it does much more DDR access

14:06 <stepri01> bbrezillon: sure I can push Adrián's series too. Could you give you're R-b on https://lore.kernel.org/all/20250213161248.1642392-1-steven.price@arm.com/ ?

14:07 <bbrezillon> done

14:08 <stepri01> bbrezillon: Thanks!

14:11 <daniels> narmstrong: it looks like 16x16 AFBC is fine, but 32x8 AFBC is not - does the DDK use 32x8?

14:11 <daniels> also AFBC should really be doing _less_ DRAM access rather than more ...

14:23 <narmstrong> not sure if I ever tested 32x8

14:24 <narmstrong> I don't think the mali blob delivered by Amlogic supported 32x8

14:24 <narmstrong> let me check

14:24 <mntirc> narmstrong: it's not hdmi but DSI

14:24 <mntirc> (actually we still need to confirm HDMI but according to kusma it doesn't show on vim3 on hdmi)

14:29 <narmstrong> hmm

14:33 <narmstrong> daniels: I have "/* RGB565 doesn't support SPLIT mode when WIDEBLK is used */" in a comment https://gitlab.baylibre.com/baylibre/amlogic/atv/aosp/device/amlogic/yukawa/-/commit/1cc1312f2c4777e8a896b71f7f1f4e9257b3780c

14:33 <narmstrong> I remember having issues with RGB565 + SPLIT + WIDEBLK

14:50 <daniels> it shouldn't be in 16bpp tho

17:38 <josch> mntirc, narmstrong: with pocket reform it's dsi but i observe the flicker effect as well on hdmi with a311d and reform motherboard. The flicker goes away after reverting the AFBC commit. I took a bad video of the flicker effect on my tv here: https://mister-muffin.de/reform/a311d-hdmi-flicker.mov

17:38 <josch> i noticed that when i increase the video size, then it flickers more often

17:39 <josch> the whole screen goes black for a fraction of a second

17:40 <josch> which is the same effect that can be seen in deianara's video (just more frequent there)

17:40 <narmstrong> josch: I see, seems we're hitting bandwidth issues, could you try removing "AFBC_FORMAT_MOD_SPLIT" in the AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 modifiers of src/panfrost/lib/pan_layout.c in https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/85/diffs

17:45 <josch> narmstrong: like this? https://paste.debian.net/hidden/0ce51c87/

17:46 <narmstrong> yep

17:46 <josch> thank you, will do! :)

19:11 <josch> narmstrong: with above patch, this happens: https://mister-muffin.de/p/jsg_.jpg

19:11 <narmstrong> That doesn’t look good at all!

19:11 <josch> but it's definitely more pretty than what i had before! :D