Posts made by veye_xumm

@mparem
https://github.com/veyeimaging/rk35xx_orangepi/releases/tag/v1.2_mvcam_tablet_cm5
Please try this image file on cm5-tablet.

@barbanevosa
The issue occurs because the camera sensor outputs a resolution of 3088 × 2064, but the receiving side (V4L2 buffers) aligns each line to a stride of 3136 bytes for memory alignment. When OpenCV is used directly with cv2.CAP_V4L2, it applies the width setting (3088) both to the sensor and to the buffer interpretation. Since the actual buffer has padding (3136 vs. 3088), OpenCV misinterprets the data layout, which results in visible image artifacts (stripes).

We recommend using a GStreamer pipeline to handle the stride and alignment internally, so that OpenCV receives a clean image with the correct resolution.

@flaty 不客气。如果有后续的解决方案也欢迎告知我一下。

@flaty
DMA BUFF模式的支持，并不是相机驱动所决定的，而是rockchip的rkcif这个驱动决定的。 数据的传递顺序是：camera-->mipi rx--->rkcif。

我查阅了一些资料，显示5.10版本的rk3588的驱动好像是比较明确不支持DMA BUFF模式的。这也就限制了你camera到其他外设驱动的buffer零拷贝传递的能力。 不过如果你只是想零拷贝从camera驱动中拿到数据，进入算法的话，V4L2_MEMORY_MMAP模式应该就可以支持。

rkcif驱动在kernel6以上版本是否支持了DMA buffer模式，没有确切的说法。

@flaty 我的理解中，相机驱动并不涉及到BUFF模式的限制。实际上数据的收取和防止到内存是rk的mipi接收单元的驱动所决定的。
下面是网上插到的信息，希望能有帮助。

从你贴的代码来看，报错 Failed to queue buffer: Invalid argument（EINVAL）通常意味着结构体成员设置有问题，或者驱动不支持 DMABUF 模式。结合你写的代码，我帮你逐条排查一下：

---

1. v4l2_buffer 初始化问题

你这里写的是：

struct v4l2_buffer buf={0};
struct v4l2_plane planes[1]={0};

这是对的，但要注意 buf.length 必须和 planes 数组元素数量一致，并且 buf.m.planes 不能为空。

---

2. buf 关键字段设置

你代码里：

buf.index = 0;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
buf.memory = V4L2_MEMORY_DMABUF;
buf.length = 1;
buf.m.planes = planes;

• buf.type 用 V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 是对的（说明驱动是 multiplanar 类型）。
• buf.memory 设置成 DMABUF 正确。
• buf.index 不是 0 就行，它必须是你在 VIDIOC_REQBUFS 时分配的 buffer 数量里的一个合法索引。比如如果你 req.count = 4，那么只能用 0..3。

---

3. plane 字段设置

planes[0].m.fd = frame_buffers[i].dmabuf_fd;
planes[0].length = buffer_size;

问题可能出在这里：

• planes[0].m.fd：必须是 dma-buf 的有效 fd。
• planes[0].length：应该是该 plane 的大小，但 通常驱动并不依赖这个值。有些驱动要求设置 bytesused，即：

planes[0].bytesused = buffer_size;

如果 bytesused 没设，驱动可能直接返回 EINVAL。

---

4. 建议的正确写法

试着改成这样：

struct v4l2_buffer buf;
struct v4l2_plane planes[VIDEO_MAX_PLANES];  // 通常 >= 1
memset(&buf, 0, sizeof(buf));
memset(planes, 0, sizeof(planes));

buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
buf.memory = V4L2_MEMORY_DMABUF;
buf.index = i;                   // 循环里的 buffer 索引
buf.length = 1;                  // plane 数量
buf.m.planes = planes;

planes[0].m.fd = frame_buffers[i].dmabuf_fd;
planes[0].length = buffer_size;   // plane 总大小
planes[0].bytesused = buffer_size; // 必须加上

---

5. 确认驱动是否支持 DMABUF

不是所有 V4L2 驱动都支持 V4L2_MEMORY_DMABUF。你可以用下面的方法确认：

v4l2-ctl -d /dev/video0 --querycap

如果 ioctl 里不支持 DMABUF，就算代码写对了也会 EINVAL。
有些驱动只支持 MMAP，那就得用 V4L2_MEMORY_MMAP。

---

建议：先在 QBUF 前打印出 buf 和 planes[0] 的值，确认 index、fd、bytesused 都合理。

---

@flaty 建议您参考一下yavta的源码。git clone https://github.com/veyeimaging/yavta.git

@jhaijun 不好意思我们这个论坛是只针对我们公司自己产品的。 sony 机芯的话确实没有搞过。

@joe Sorry for overlooking the information in the earliest post. I think the board in the link below is suitable, as it is compatible with the official nVidia development board.
https://www.alibaba.com/product-detail/Nvidia-jetson-orin-nano-development-board_1600993126148.html?spm=a2747.product_manager.0.0.61e871d2RIVAmD

@flaty 不客气。

@mparem https://github.com/veyeimaging/rk35xx_orangepi/releases
please try the latest image or deb packages.

@flaty 这些报错都不用管。 我们的模组不需要这些供电。

@flaty
正常来说，你只要在这个文件的基础上做如下修改：
//open this line to enable v-by-one hs link
//#include "rk3588-roc-pc-vbyone-overlay.dtsi"
#include "rk3588-roc-pc-cam-veyecam2m.dtsi"
//#include "rk3588-roc-pc-cam-veyemvcam.dtsi"

@joe
Regarding the I2C issue with the J401 baseboard, we have previously resolved it, and the engineers at Seeed Studio have documented the solution on their wiki. Here are two links for your reference.

https://wiki.seeedstudio.com/Solution_for_the_Compatibility_Issue_between_reComputer_and_VEYE_Camera/

https://forum.veye.cc/topic/539/imx327s-with-recomputer-xavier-nano/10

@flaty 就是这个。

@flaty 可以的。

@flaty
参见代码的注释，你的内核缺少这个接口，需要注掉这个函数。

@flaty 驱动源码你直接用github最新的就行。

@flaty
您这个截图的镜像是MV和RAW系列的。
请参考这个链接中的镜像。
https://github.com/veyeimaging/rk35xx_firefly/releases/tag/v1.7

@mparem
Since I don't have the tablet board here, the following is just a suggested approach based on my guess. You can try commenting out the following two lines or modifying them as shown below:

clocks = <&ext_cam_ov5647_clk>;  
clock-names = "xvclk";  

@mparem said in OrangePi cm5-tablet RAW-MIPI-SC132M:

his is the decompiled dts, which I modified (set i2c address to 0x3b and changed compatibility to veye,mvcam), compiled, then moved back into /boot/dtb*/rockchip/rk3588s-orangepi-cm5-tablet.dtb (faster than recompiling with orangepi-build)

I haven't used this method before, and I didn't quite understand your source code.
Now it seems the issue might still be with the DTS. I suggest you try editing the DTS source code using conventional methods.