V4L2: Couldn't map video buffer: Code=22

[kekyo]

V4L2: Couldn't map video buffer: Code=22

[sappho192]

I have looked at the source of FlashCap, but that doesn't bring me closer to understand what the error code 22 is about.

I think the error code 22 is came from Linux native error code. Link

Maybe I/O argument for /dev/video has been changed since Raspbian 11...?

[dkjonas]

Following up on this, just in case others experience the same issue.

The problem is that the kernel on Raspberry Pi4 may be 64 bit, even if user space is 32 bit (see raspberrypi/firmware#1795). Because of this uname will return aarch64 and the 64 bit Interop is used. This makes the mmap call fail.

To get it running on my system, I changed the code in NativeMethods_V4L2.cs to use armv7l Interop for the aarch64 case.

This of course not a general solution, but I have no idea of how to create a better architecture selection.

[kekyo]

I can't look it up on RPi right now, but what about sappho's point that /dev/video may not exist?

[sappho192]

I've searched some [similar] [issues], maybe V4L2 related code needs to be updated.
But it's odd because Raspbian 11 was released two years ago, and FlashCap was released last year.

Source of simple problem that throws the above exception:

I suggest getting a stack trace (toward Linux system calls) with this code may help discover the problem.

[dkjonas]

but what about sappho's point that /dev/video may not exist?

Device exits and I can open it with a native linux program (guvcview).
Also, if FlashCap couldn't open the device, then I think it would fail earlier. It does some ioctl on the fd, before the failing mmap.

I suggest getting a stack trace (toward Linux system calls) with this code may help discover the problem.

I'm not sure how to do this.

[kekyo]

Oh, understood... This difference could also be in Win32 WoW. (Fortunately in Win32 we didn't have to interact directly with the native interface, so the problem didn't occur.)

It might be a good idea to additionally check IntPtr.Size to choose between using aarch64 or armv7l (maybe we should do the same for x86_64).

[kekyo]

Fixed and will release on next version.