blue-debug opened a new pull request, #21472:
URL: https://github.com/apache/nuttx/pull/21472

   *Note: Please adhere to [Contributing 
Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).*
   
   ## Summary
   
   This PR gives the V4L2 structs in `<sys/videoio.h>` the binary layout of 
Linux's `videodev2.h`. virtio-media transports each ioctl payload as the raw 
memory of the corresponding Linux struct, so both sides need the same layout. 
The changes:
   
   - 16-bit fields widened to 32 bits as on Linux (format index and type, frame 
sizes, control ids and types, extended control counts); the trailing reserved 
members added; the structs Linux packs marked packed; `sizeof(struct 
v4l2_format)` and `sizeof(struct v4l2_streamparm)` as on Linux.
   - `v4l2_requestbuffers.capabilities` as on Linux; the NuttX-specific `mode` 
moves into a reserved byte.
   - `buf_type` of `v4l2_frmsizeenum` / `v4l2_frmivalenum` and `ctrl_class` of 
`v4l2_queryctrl` / `v4l2_query_ext_ctrl` / `v4l2_querymenu` removed, as on 
Linux (`v4l2_ext_controls` keeps its `ctrl_class`, as Linux does); `raw_data` 
of `v4l2_streamparm` moved into the `parm` union.
   - v4l2_cap.c follows the removed `ctrl_class` field, and reads control 
values into a local because `v4l2_ext_control` is now packed.
   
   This PR and #21471 (V4L2 capture fixes) are independent: they apply to 
master in either order.
   
   Depends-On: https://github.com/apache/nuttx-apps/pull/3976
   
   ## Impact
   
   Affects: `<sys/videoio.h>` and its users: the V4L2 capture driver, and 
examples/uvc_cam and system/nxcamera in apache/nuttx-apps.
   
   Behavior: no change at run time; the ioctl numbers and the control id values 
stay the same.
   
   Compatibility: the structs change size and layout, so applications and 
drivers that use them must be rebuilt. Code that sets `buf_type` or 
`ctrl_class` drops it, as on Linux; code that uses `raw_data` of 
`v4l2_streamparm` uses `parm.raw_data`; control ids are stored in `uint32_t`. 
apache/nuttx-apps#3976 does this for examples/uvc_cam and system/nxcamera; it 
builds with both layouts and goes in first. No in-tree driver uses the removed 
fields.
   
   ## Testing
   
   Layout: `gdb` `ptype /o` on objects built from `<sys/videoio.h>` and from 
Linux mainline `include/uapi/linux/videodev2.h` (x86_64, sim) compares the 42 
structs that both headers define. On master 18 of them differ in size or member 
offsets. With this PR 41 match in size and in the offsets of all common 
members; the exception is `v4l2_requestbuffers`, which has the same size and 
keeps the NuttX-specific `mode` in the first of Linux's three reserved bytes.
   
   Build: plain sim:nxcamera with `-Werror`, as CI builds it, passes with 
apache/nuttx-apps#3976; with apache/nuttx-apps master alone it fails with three 
`incompatible-pointer-types` errors in nxcamera_main.c, and examples/uvc_cam 
fails on `buf_type`. The commit builds with every V4L2 option enabled, with no 
new warnings, and checkpatch passes. The video drivers sim does not build 
(gc0308, isx012, isx019, goldfish_camera, ov2640, ...) give the same 
`-fsyntax-only` result with the old and the new header.
   
   Runtime: sim:nxcamera with apache/nuttx-apps#3976, NSH. As in #21448, 
nxcamera captures 10 frames from a v4l2loopback device and nxcodec decodes a 
320x240 H.264 stream on the sim OpenH264 decoder.
   
   Logs (excerpt):
   
   ```
   nsh> uname -a
   NuttX 13.1.0 98ffb8ac484 Nov  5 2026 10:07:44 sim sim
   nsh> mount -t hostfs -o fs=/tmp/v4l2-test/capture /host
   nsh> nxcamera
   nxcamera> input /dev/video0
   nxcamera> output /host/frames.yuv 10
   nxcamera> stream 640 480 30 YU12
   nxcamera> q
   nsh> ls -l /host
   /host:
    -rw-r--r--     4608000 2026-11-05 02:07 frames.yuv
   ...
   nsh> mount -t hostfs -o fs=/tmp/v4l2-test/nxcodec /host
   nsh> cd /host
   nsh> nxcodec -d /dev/video1 -s 320x240 -f H264 -i t.h264 -f YU12 -o o.yuv
   nxcodec device name: /dev/video1
   nxcodec size: 320x240
   nxcodec is single-planar
   nxcodec init DONE.
   nxcodec started.
   ...
   ```
   
   Result: PASS. The 10 captured frames are byte-identical to FFmpeg's 
smptebars frame and the 59 decoded frames to FFmpeg's decode of the stream, as 
on master.
   
   Additional platform coverage:
   
   - BES platform (Cortex-M55): Vela's camera stack runs with this 
`<sys/videoio.h>` layout.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to