00:36 <DC-IRC> [Discord] <beohoff3174> I'm surprised you can get a display up cloning nyanmisaka's branch of mpp. I had to pull down the latest from Rockchip themselves as they were open /dev/dri/card0 until a recent branch switched to looking for /dev/dri/render128 (or whatever the numbering is)

00:36 <DC-IRC> [Discord] <beohoff3174> I'm surprised you can get a display up cloning nyanmisaka's branch of mpp. I had to pull down the latest from Rockchip themselves as they were opening /dev/dri/card0 until a recent branch switched to looking for /dev/dri/render128 (or whatever the numbering is)

00:37 <DC-IRC> [Discord] <beohoff3174> EGL, or at least my understanding of it with qt watned /dev/dri/card0 all to itself

02:06 <DC-IRC> [Discord] <monkablyat> guys we already used: /delete-node/ chosen; : hack already on rk3588 to hack around boot args's in rk35xx-linux.dtsi on vendor kernel , why don't we just remove arg's instead of adding delete node hack to every rk35xx DTS

02:08 <DC-IRC> [Discord] <monkablyat> the line we delete in every rk35xx DTS and hack around is basically only needed for Rockchip SDK Linux

02:21 <DC-IRC> [Discord] <monkablyat> guys we already used: /delete-node/ chosen; : hack already on rk3588 to hack around boot arg's in rk35xx-linux.dtsi on vendor kernel , why don't we just remove arg's instead of adding delete node hack to every rk35xx DTS

09:39 <DC-IRC> [Discord] <rpardini> Hmm, I've not run into that. Kodi GBM needs the display all for itself -- X11/Wayland should be shutdown for it to run.

10:11 <DC-IRC> [Discord] <nagatoronyan> Maybe it's worth making a "Dedicated applications Armbian image" for this on RK35xx? That way users can just flash the image and use it out of the box, like with LibreELEC.

10:22 <DC-IRC> [Discord] <rpardini> Yes. I'm slowly working in that direction. I'm first hacking at the `EXT=mesa-vpu` extension so we can get some mesa or panfork going in CLI (non-desktop) images. With that, one can simply deploy kodi-rockchip-gbm .deb and get a working Kodi. It's been working really well with rkr3 and Debian Trixie (which has recent-enough mesa upstream). Since I've done Debian "non-packaging" ( <clipped message>

10:22 <DC-IRC> [Discord] <rpardini> I build everything into `/usr/local` and then just ship that whole thing in a .deb) it's really more suited for development and/or immutable-ish images...

10:24 <DC-IRC> [Discord] <rpardini> rkmpp-wise it's working great -- 6.1-rkr3 has some green-ish artifacts when HDMI is running at 4k which doesn't happen with 5.10-rkr8, at least on my board.

10:28 <DC-IRC> [Discord] <rpardini> But really at a certain point I considered we could invest a bit into bringing the rkr kernel, your ffmpeg, and the 2 kodi patches into a LibreELEC fork, something like CoreELEC is for Amlogic's vendor kernel.

10:28 <DC-IRC> [Discord] <rpardini> chewitt would probably kill us, though.

11:15 <DC-IRC> [Discord] <nagatoronyan> LibreELEC is only focused on mainline stuff. Their packaging is quite different from Debian so I'm not sure if this is easy to do and maintain long term.

11:15 <DC-IRC> [Discord] <nagatoronyan> If you just fork to `LibreELEC-rockchip` or something similar I think it would be acceptable since there are custom images for Rockchip V4L2 in their forum.

13:08 <DC-IRC> [Discord] <beohoff3174> EGL, or at least my understanding of it with Qt, wanted /dev/dri/card0 all to itself

14:28 <DC-IRC> [Discord] <rpardini> Yeah. For now I'll focus on the Armbian + .deb thing, as that is more useful to me: I can get (mostly CPU-bound) Kubernetes workers that _also_ work as mediaplayers. 😉