usual user

Official development for inclusion in upstream are carried out by working on the project's main branch. That's exactly what this pull request branch does by tracking the project's master tree. Applying commits to anything else is backporting. Backporting is possible, but you will have to deal with the consequences yourself that arise from your outdated versions lacking the functions required for your backport, and you may need to backport those as well. Since this project is a user program and not a framework with libraries that other programs depend on, it is solely the user who has to deal with it as a dependency in its use. At first, I also tried to use the sources of the current release version as a base, but since the commits couldn't be applied without errors, I simply built the current master branch. For the FFMPEG framework, this is already a whole different ballgame. There are many programs, which mpv is just one, that depend on the libraries and need to be rebuilt accordingly in case of an upgrade. Since my chosen distribution recently released ffmpeg 8.0 and thus made all dependent programs available accordingly, I just had to rebuild the ffmpeg package with the v4l2request support commits and put that in place. And since the commits could be applied to the current release sources without any errors, I didn't even need to switch to the master branch.

Just out of curiosity, why are you trying to backport the v4l2request support? Why not build the pull request tree directly: git clone --branch v4l2request https://github.com/philipl/mpv.git mpv-player-v4l2request

The 6.18.0-rc5 kernel doesn't require any patches, just have to been build with DRM_ACCEL_ROCKET.

Just for posterity. fluster-run-odroid-m2-summary

I have that line also: [ 0.496136] rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to enable supply: -517 [ 0.938478] rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to create device link (0x180) with supplier 2-0042 for /power-management@fd8d8000/power-controller/power-domain@8 [ 1.224290] rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to enable supply: -517 [ 1.237338] rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to create device link (0x180) with supplier 2-0042 for /power-management@fd8d8000/power-controller/power-domain@8 [ 1.294276] rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to create device link (0x180) with supplier spi2.0 for /power-management@fd8d8000/power-controller/power-domain@12 [ 17.384495] rockchip-pm-domain fd8d8000.power-management:power-controller: sync_state() pending due to fdba4000.video-codec [ 17.385477] rockchip-pm-domain fd8d8000.power-management:power-controller: sync_state() pending due to fdba8000.video-codec [ 17.386457] rockchip-pm-domain fd8d8000.power-management:power-controller: sync_state() pending due to fdbac000.video-codec [ 17.387427] rockchip-pm-domain fd8d8000.power-management:power-controller: sync_state() pending due to fdc40100.video-codec But VPU seems to be working anyway:

If wired correctly, dmesg reveals the following: [ 5.967316] [drm] Initialized rocket 0.0.0 for rknn on minor 0 [ 5.975499] rocket fdab0000.npu: Rockchip NPU core 0 version: 1179210309 [ 5.978652] rocket fdac0000.npu: Rockchip NPU core 1 version: 1179210309 [ 5.985602] rocket fdad0000.npu: Rockchip NPU core 2 version: 1179210309 And when mesa is built with the rocket driver enabled, it can be used via teflon.

FWIW, HEVC support is queued for 6.19. With WIP patches on top, rkvdec2 is also available to me. With the gstreamer framework, this works for me out-of-the-box, as the necessary support has been available in mainline for quite some time. See video-pipeline.pdffor reference. I have already rebuilt the Huffman package with the patches mentioned above, but currently the developers of the distribution of my choice are busy rebuilding all packages that depend on it. As soon as the Huffman package is rolled out, I will start to see how HEVC performs with the FFMPEG framework.

Drop it in a Spoiler:

And since it contains no firmware payload output, no one can tell what you are running.

My rk3588 devices are e.g. exposing this: v4l2-compliance-odroid-m2.txt And here is the visualization of a video pipeline: video-pipeline.pdf Watch out for the v4l2slh265dec component.

https://lore.kernel.org/linux-media/Z4e9wNxZjvnytXlL@pengutronix.de/

The mainline kernel has currently a shortcoming in USB-TYPEC support. FUKAUMI Naoki demonstrated a workaround for other devices that also works for the ODROID-M2.

Out of curiosity, does it work if you drop my firmware build in place? dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-device-to-be-used} u-boot-meson.bin.tgz

A phandle is a magical number assigned during DTB assembly, whose value is irrelevant as long as it references the same node with the phandle property. The magic value can change when the structure changes because it is assigned arbitrarily; for example, by inserting an additional node.

In an XWindow environment, these are realistically expected numbers. In a Wayland environment, this is somewhat better; see glmark2-wayland-odroid-m1.log as a reference. But it is in no way comparable to a Mali G610; see glmark2-wayland-odroid-m2.log as a reference. Use WebGL Report to be sure.