09:33 <robmur01> CounterPillow: nah, from everything I've seen they're not using our interconnects. The CCI on multi-cluster SoCs with pre-DSU CPUs is merely used to bridge the CPU clusters to the main interconnect (according to a diagram in the RK3399 TRM, at least)

10:35 <CounterPillow> robmur01: thanks!

12:14 <Ermine> Seems like rockchip has its own framework for hardware video processing, MPP. Is it possible to somehow make VA-API drivers using information from MPP?

12:31 <CounterPillow> no

12:32 <CounterPillow> MPP is the downstream vendor kernel interface. Mainline has settled on v4l2-requests, though not all hardware has drivers for it yet (e.g. encoding isn't possible atm)

12:37 <Ermine> I mean, from mpp and rockchip kernel sources one could figure out how hardware works

12:41 <CounterPillow> Yes, that is what we are doing, in combination with reading the hardware TRMs, to write those v4l2-requests drivers

12:43 <Ermine> oh, that's great to hear

12:43 <Ermine> Can I join? Is there a public repo?

12:43 <CounterPillow> It is in the mainline Linux kernel, and mainline gstreamer.

12:53 <CounterPillow> For current mainline kernel status on RK3588, see https://col.la/rk3588status and for current mainline kernel status on RK3576, see https://col.la/rk3576status

12:53 <CounterPillow> If you're currently using some 6.1 kernel from an armbian image or something, it's likely a vendor kernel, which is not where any of that work is happening.

13:04 <Ermine> Well, I keep that table about rk3588 in mind, and so far encoders are in TODO status

13:04 <Ermine> seems like decoder driver is drivers/staging/media/rkvdec, what about encoding side of things?

13:06 <CounterPillow> remains to be developed, there are RFC patches on the mailing lists for some v4l2-requests encoders to prototype a uAPI that everyone is happy with.

13:06 <Ermine> Ah, got it. Thank you!

13:46 <Dex2x> I am curious, and I think there is something I don't understand with the SBC's, the Radxa rock 5B+ has plat support with raspbian, but the orangepi 5 ultra is community maintained, but it's the same chip? What makes them so different?

13:51 <Ermine> peripherals i would guess

13:58 <diederik> I believe the criteria is whether someone volunteered to be the maintainer for that board (I assume you meant armbian here)

13:59 <diederik> Another factor is (probably) whether the SBC maker is a 'partner': https://www.armbian.com/partners/

14:00 <Dex2x> yes sorry I meant armbian. The two boards seems very similar except for onboard wifi and the M.2

14:00 <Dex2x> But I think I will get the rock loader from raxda since that seems to be in english ?

14:04 <diederik> is 'rock loader' the MASKROM tool? If so (and you're on Debian), there's also rkdeveloptool package (but there are various tools for that)

14:06 <Dex2x> yeah rkdeveloptool

14:06 <diederik> (you'd need to add your user to the 'rkdeveloptool' group to use it as a normal user though)

14:13 <Dex2x> what about the mflash tool ?

15:57 <detlevc> diederik: This is taking a lot of time. mpv doesn't reproduce the issue, is there a libreelec image that I can use to reproduce this ?

16:01 <diederik> There's https://github.com/LibreELEC/LibreELEC.tv/pull/7864 ("Rockchip: add initial support for RK356x and RK3588") ... so (afaik) not one ready to be downloaded

16:04 <detlevc> So I'd need to build it locally ?

16:11 <diederik> I think it's better if warpme would detail *exactly* what he's using?

16:14 <diederik> My guess is that if you want to try LE, then yes you'd have to build it locally. But if you can't reproduce it with mpv, then I think there's a good chance you can't reproduce it with (a locally built) LE either

16:15 <diederik> AFAICT the patch set I use for ffmpeg(/mpv) is the same as what LE uses

16:22 <Dex2x> geez my opi5 is burning up, ssh login getting stuck

17:26 <Dex2x> hmmm I haven't figured out how to get the fan control working on the opi5 ultra

17:26 <detlevc> diederik: Ok, I'll wait for better repro instruction from warpme then

19:20 <warpme> @detlevc : to reproduce rkvdec3 h264....: i think instead boring you with my distros (minimyth2, miniarch) i think you may try with v4l2_request patches i'm using in mythtv/kodi where i see isssue. mythtv uses build-in ffmpeg but i have in my repo ffmpeg7.1 with exact v4l2 patches i'm using to patch build-in mythtv's ffmpeg which is used by kodi in my distro. May you pls try with: https://github.com/warpme/minimyth2/tree/master/script/lib/ffmpeg7.1/

19:20 <warpme> files Patching order should be by filename so should be ok by default... This is based on code used exactly by LibreELEC. I'm using in in mythtv and kodi and all works well (in sense 30+ boards i have...) It may happen i diverge but...i.... doubt as i'm trying to follow quite exactly any movements in v4l2_request movements...)

19:49 <mmind00> diederik: can I transplant your reviewed-by from v2 of the pinephone panel patch or do you want to take a separate look at v3?

19:53 <diederik> mmind00: you can transplant it. Separately, I suggested to Olivier to `s/DTS' //` from the Subject. He agreed, but forgot to actually do it when he sent v3

19:54 <diederik> https://lists.sr.ht/~diederik/pine64-discuss/%3CDAQIU1OKY8QE.1CTZEFX4W2S46@cknow.org%3E

20:01 <mmind00> diederik: thanks ... also dropped the DTS' thingy :-)

20:02 <diederik> :)

22:06 <mmind00> CounterPillow: see, you got your wish ;-)

22:08 <CounterPillow> mmind00: \o/

22:26 <mmind00> CounterPillow: if you see that "soon" dwc3 series passing by you that Neil mentioned in the previous revision of your series, please holler :-)

22:26 <CounterPillow> will do!

22:27 <CounterPillow> Also if it doesn't happen in the next few months and I still have time by then, then I will take things into my own hands I guess