07:39 <warpme> guys: since many months i see most recent mainlining rk3588 kernel (collabora tree; armbian patches) are offering working hdmi on rk3588 but in the same time other rk socs (3399, 3566, 3568) becomes broken (usually trap at boot in dw_hdmi_rockchip_mode_valid call). Is this just me....or this is known state of things?

08:11 <mmind00> warpme: it always will depend on people testing and also sending patches with fixes ... especially things like hdmi are highly dependent on the display(-mode) used, so even not everybody will see the same faults

08:11 <mmind00> warpme: at least doing a git bisect between last-working and nonworking will help a lot, as it identifies the commit causing a regression

09:06 <warpme> mmind00 : i spent some time trying to get it working by playing with Cristian Ciocaltea (collabora) 3588 dw_hdmi-rockchip code - but i'm too weak with dw kernel code knowledge to get singe dw_hdmi-rockchip working on 3399/3566/3568/3588. 356x hdmi breakage is by single commit: https://github.com/armbian/build/blob/main/patch/kernel/rockchip-rk3588-edge/0137-drm-bridge-synopsys-Add-initial-support-for-DW-HDMI-.patch So currently

09:06 <warpme> i'm facing binary situation: no this patch = all ok except 3588; with this path: only 3588 hdmi works. As my goal is: one kernel for all 13+ SoCs, 3588 is still out of game for me (since years; so pita....)

09:17 <qschulz> warpme: from the URL, this seems to be an armbian kernel, have you tried upstream directly instead? v6.9 for example

09:21 <mmind00> warpme: also the rk3588 hdmi work is still hugely "work-in-progress" ... when you look at Cristian's collabora tree you see huge changes being made

09:22 <mmind00> so he's still figuring out how everything goes together so that both the new and old hdmi-variants work

09:23 <mmind00> qschulz: upstream has no rk3588 hdmi support yet ;-)

09:26 <diederik> I can't find the patch right now, but it mentioned it made it work on LVDS ... and I only later found out the significance of that line ;)

09:36 <warpme> mmind00 : "rk3588 hdmi work is still hugely "work-in-progress" - yeah. This is also my conclussion :-( So we need wait (hope not another year). Ough....

09:38 <warpme> btw: this looks interesting: https://gitlab.collabora.com/cristicc/linux-next/-/commits/rk3588-bridge need to try....

14:53 <warpme> mmind00 : FYI Just tested https://gitlab.collabora.com/cristicc/linux-next/-/commits/rk3588-bridge on 3588 and 3399. both have hdmi working! Finally!. Now only need to test 2835/2711/2712/h6/h313/h616/h618/3328/3566/3568 :-)

17:02 <sre> FWIW Cristian has a Rock 3B to test if his changes regress RK3568 support and hopes to send out a series for basic RK3588 HDMI support in the near future; hopefully in time for 6.11.

17:17 <sre> correction: he has a Rock 3A / RK3566 for regression testing.

17:20 <sre> ah he got confused and it actually is RK3568. Probably time to call it a day :D

21:34 <urja> Are we interested in the hardware H.264 decoding looking like it's... glitching in time (=showing frames in the wrong order, not sure how to explain) with some files?

21:46 <urja> That is, i built https://github.com/kwiboo/FFmpeg as the system ffmpeg, rebuilt mpv, added hwdec=drm to mpv.conf, and get https://urja.dev/glitchyaf.mp4 stuff like this with some videos

21:47 <urja> (If you recognize the intro, no you didnt :P)

21:53 <diederik> Did you add the kernel patches that go with those ffmpeg patches? Probably also useful to specify which device SoC you're using

21:57 <urja> RK3288 with the mainline hantro-vpu driver (it's running 6.6.30)

21:59 <urja> and yeah sorry you wouldnt remember a question from two weeks ago (where I asked if i can haz h.264 decode on RK3288), thank you valpackett for the reply btw <3

22:01 <urja> (and yeah, i'm less interested in integrating that to firefox if the result would be "some videos will randomly be really glitchy")

22:03 <urja> Interestingly, ChromeOS (just the "Gallery" video player) on the same hardware plays that specific video just fine, but glitches real bad on some other videos (which play ... better, still slightly glitchy... on this setup)

22:05 <urja> But yeah, if the result is "some videos play like _that_" i'm not as interested in integrating this to firefox as i was before lol

22:07 <urja> (Still... it'd be neat, would free up resources to run the twitch chat and other javeascript... which yeah seems to be about as heavy as the video decode and playback, it seems :P)

22:51 <valpackett> well, all the issues like that should be debugged :)

22:56 <valpackett> I wonder if this ancient rk3066 i'm playing with has the same vpu and isp blocks as the newer ones…

23:23 <valpackett> oh the isp is different but there is a mainline driver submission for it!! https://lkml.org/lkml/2023/11/16/262

23:27 <valpackett> well, https://patchwork.kernel.org/project/linux-media/cover/cover.1700132457.git.mehdi.djait@bootlin.com/ for a newer version

23:57 <valpackett> oh we already have rk3066-vpu even, cool