Your system information

• Steam client version: 1784588115
• Distribution: Armada OS deployment 20260714.ec4bf0c (Fedora Linux 44, native ARM64 Steam)
• Device: AYN Odin 2 Portal / Qualcomm SM8550 / Adreno 740
• Kernel: 7.0.11 (qcom_iris, /dev/video0 = qcom-iris-decoder)
• Mesa: 26.1.4-1.fc44.armada
• Opted into Steam client beta?: Yes, steamdeck_publicbeta
• Have you checked for system updates?: Yes
• Native streaming binary: ~/.local/share/Steam/steamrtarm64/streaming_client, aarch64 build ID 34ded2b9ba517b1313bd40a0a5e60513f8e6bb7c
• Streaming host: CachyOS x86_64, AMD Radeon RX 9070-series

I understand the native ARM64 Steam client is not formally released. This report concerns its Valve-supplied native steamrtarm64/streaming_client, specifically the CV4L2Accel path.

Please describe your issue in as much detail as possible

Remote Play connects and audio/input work, but video is solid green and Steam reports slow decoding. The host successfully encodes and forwards frames. The client repeatedly logs:

CLIENT: CV4L2Accel -> F Couldn't queue capture buffer ... Invalid argument
CV4L2Accel: Resetting because decoded frame ID has failed
k_EStreamFrameResultDroppedReset

A syscall trace (strace -ff -yy -v -s 512 -e trace=ioctl) localizes the first failure before that reported capture-buffer EINVAL:

1. Iris reports V4L2_CAP_VIDEO_M2M_MPLANE.
2. Steam configures H.264 OUTPUT at 1280x720 using MMAP and NV12 CAPTURE at 1280x736 using DMABUF.
3. Both VIDIOC_STREAMON calls succeed.
4. All initial 16 DMABUF CAPTURE QBUFs succeed.
5. Every compressed H.264 OUTPUT QBUF has bytesused=0 (1,713/1,713 in a 15-second trace).
6. Iris returns CAPTURE index 0 with V4L2_BUF_FLAG_ERROR|V4L2_BUF_FLAG_LAST and zero bytes.
7. Steam resets the queues and then submits a zero-initialized CAPTURE QBUF (type and index only), producing the secondary EINVAL shown in streaming_log.txt.

Representative trace excerpt:

ioctl(37</dev/video0>, VIDIOC_QBUF, {type=VIDEO_OUTPUT_MPLANE, index=0, memory=MMAP, length=1, bytesused=0, flags=...KEYFRAME...}) = 0
ioctl(37</dev/video0>, VIDIOC_DQBUF, {type=VIDEO_CAPTURE_MPLANE, index=0, memory=DMABUF, length=1, bytesused=0, flags=ERROR|LAST|...}) = 0
ioctl(37</dev/video0>, VIDIOC_QBUF, {type=VIDEO_CAPTURE_MPLANE, index=0}) = -1 EINVAL (Invalid argument)

ARM64 disassembly around the embedded diagnostic string CV4L2Accel::BSubmitFrame()->SUBMIT queueout[%d] shows that BSubmitFrame() obtains the packet pointer and length through its input object, calls memcpy() with that length, stores the same length in v4l2_plane.bytesused, and then calls VIDIOC_QBUF. The supplied length is already zero, so no compressed payload is copied or submitted. The kernel cannot decode or reconstruct data it never receives. The binary embeds the source path /data/src/streaming/client/v4l2accel.cpp.

The later capture QBUF EINVAL is therefore a reset-loop symptom rather than the root cause.

Test matrix

• H.264 only (HEVC and AV1 disabled): still green.
• Steam hardware decoding disabled in UI: still green; Steam continues using CV4L2Accel.
• Desktop Mode rather than Gamescope/Game Mode: still green.
• Temporarily making /dev/video0 inaccessible: V4L2 errors disappear, but no working software fallback is selected; all frames become k_EStreamFrameResultDroppedDecodeCorrupt and DecoderDescriptionID is empty. Device permissions were immediately restored.

Expected behavior

• CV4L2Accel should submit the actual compressed packet length/payload to the V4L2 OUTPUT queue.
• Disabling hardware decoding should avoid CV4L2Accel and select a working software decoder.

Steps for reproducing this issue

1. Run the native ARM64 Steam client on an AYN Odin 2 Portal with the Qualcomm Iris stateful V4L2 decoder.
2. Connect with Remote Play to a Steam host.
3. Start any stream, including Desktop Mode.
4. Observe green video and slow-decoding warning.
5. Trace streaming_client ioctls and observe every H.264 OUTPUT QBUF using bytesused=0.

Related downstream investigation: https://github.com/virtudude/armada/issues/138

AYN also publishes its mainline-oriented device kernel at https://github.com/AYNTechnologies/linux and lists video codec acceleration as working. That is consistent with the driver setup succeeding here; I found no AYN-specific Steam/V4L2 userspace fix.