GenTL interface version mismatch: expected 1.1, got 0.0 (V4L2 driver)

The kernel driver loads, dmesg prints the camera's identity over I2C and a clean driver banner, and then the capture tool finds nothing: the log fills with warnings reading 'interface version mismatch: expected: 1.1, got: 0.0', and the only device on offer is an emulator. That is the standard failure of a MIPI CSI-2 camera bring-up that runs through a vendor GenTL producer on an embedded ARM board. This page decodes what the producer checks at open, shows how to read the driver's side of the handshake with v4l2-ctl, ranks the four causes from most to least likely with a test and a fix for each, and closes with the cases where a standard-transport camera is the better decision.

What 'expected 1.1, got 0.0' is actually telling you

A GenTL producer is the user-space library that implements the GenICam GenTL standard between your application and the camera transport. On an embedded board that transport is a kernel driver presenting V4L2 device nodes. At open, the producer walks the nodes, reaches the sensor subdevice, reads one vendor-defined read-only control that reports the driver's interface protocol version, and compares it with the protocol version the producer itself was compiled for. In this failure the expectation is 1.1.

'Got: 0.0' is not a version anyone shipped. It decodes to the integer 0, which is what the producer reports when its query returned nothing: the read failed somewhere between the producer's process and the driver, or came back empty. Treat the warning as a handshake failure code, not as a statement about the sensor.

dmesg has already told you what works. The module answered on the I2C bus and the driver registered the sensor subdevice, so power, the control bus and the probe are good. Had dmesg shown probe errors instead, you would be in different territory — the camera I2C communication failure diagnosis covers that case.

Read the driver's side first: decode the version control

One command puts the driver's half of the handshake on the bench. Query the subdevice, not the video node:

v4l2-ctl -d /dev/v4l-subdev0 --all

In the bring-up log decoded below, the vendor interface-version control shows up as type int, flags read-only, min=0, max=4294967295, step=1, with value=65537. A neighbouring register-access control answers 'error 5 getting ext_ctrl'. Both facts matter: the worked example uses the first, and Cause 2 uses the second.

Worked example: the 65537 a healthy driver reports while the producer still sees 0.0

Inputs. value=65537 on the interface-version control, read from /dev/v4l-subdev0 by v4l2-ctl on the running board. The producer's warning, expected: 1.1, got: 0.0, from the capture tool's log.

Rule. The interface version is packed into one unsigned 32-bit integer: major version in the upper 16 bits, minor version in the lower 16. The log itself proves the packing, because the producer's target 1.1 corresponds to the driver's 65537.

Arithmetic. 65537 = 0x00010001. major = 65537 ÷ 65536 = 1 (integer division). minor = 65537 − (1 × 65536) = 1. The driver reports 1.1. Encode the producer's expectation the same way: 1 × 65536 + 1 = 65537 — the identical number.

Result. The driver's control is readable at the subdevice and its value matches the producer's expected version exactly.

Decision. When the subdevice decodes to the producer's expectation — 1.1, encoded 65537 — the driver side is healthy and the failure sits in the producer's read path: work Causes 2 and 3. When the control reads 0, returns an error, or decodes to a different pair (1.0 encodes to 65536), the pair is mismatched and Cause 1 comes first.

Cause 1 — the driver and the producer are not a matched pair

The most common root cause is version skew: the kernel driver came from one release, often a board vendor's BSP image, and the producer library came from another. The vendor compiles the producer against one driver protocol and ships the matched driver in the same release; a mixed pair fails exactly this check.

Test. Read the driver banner in dmesg — v1.6.3 in the reference log — and the producer's version from its release notes. If you cannot trace both to one vendor release, you have found the cause. Check GENICAM_GENTL64_PATH as well: it should hold exactly one producer directory, because a second library on the path can be the one that loads.

Fix. Install the driver and the producer as the pair the vendor ships together: driver first, producer second, then reboot so the module re-probes under the new driver. Version pairing is a general rule in automation software, not a camera quirk; controller libraries and their compiled blocks fail the same way when versions drift, as in these PCS 7 driver block version mismatch errors. The producer-side version of the same disease — missing functions after a partial update — is covered in GenTL producer version compatibility: missing function errors.

Cause 2 — the producer's read through the video node fails

The producer does not open /dev/v4l-subdev0. It opens the capture node — /dev/video0 in this log — and reaches the sensor's controls through the media pipeline. If the graph is incomplete or the extended-control call fails on the way, the producer's read returns nothing and it logs 0.0 even though the subdevice reads cleanly.

The tell is in your own v4l2-ctl output: the version control reports its value while a neighbouring control answers 'error 5 getting ext_ctrl'. Error 5 is errno 5, EIO, an input/output error raised inside the driver's extended-control handler. A clean value on one control and EIO on another means the control plumbing is partially broken — and the producer depends on exactly that plumbing. That combination points here rather than to Cause 1.

Test. List which driver owns which node with v4l2-ctl --list-devices. Print the pipeline with media-ctl -p -d /dev/media0 and confirm the sensor subdevice links through the CSI receiver to the capture node the producer opens. Then attempt a short capture below the producer, v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=10, to see whether frames flow at all. Frames that never arrive point down the data path; the sensor detected but streaming fails walkthrough covers power, clocks and the device tree for that case. Controls that silently keep their default values share this root, which the V4L2 controls ignored by a sensor driver article shows from the user side.

Fix. Complete the endpoint and link definitions in the device tree so the sensor chains through the receiver into the capture node, rebuild, reboot, and confirm the interface-version control now reads from the node the producer opens.

Cause 3 — the sensor is bound to the wrong driver variant

Camera vendors ship more than one kernel driver for the same module family: one for SoCs whose media pipeline integrates an ISP, one for SoCs that take the sensor's data directly. If the device tree's compatible string points the module at the variant that does not match your SoC, the probe still succeeds — dmesg prints the banner and registers the subdevice — but the control and data behaviour is not what the producer's protocol assumes.

Test. Check which compatible string the camera node carries and which driver claimed it; dmesg's registered-subdevice line names the driver. Compare that with the driver variant your SoC family requires. The wrong sensor driver diagnosis walks the dmesg reading.

Fix. Change the compatible string to the variant that matches your SoC's media pipeline, rebuild the device tree and reboot. The banner should then name the driver you intended.

Cause 4 — the camera variant needs an ISP the board lacks

The same sensor family often exists in two hardware variants: one outputs raw data for the SoC's integrated ISP to process, the other processes on-module and emits a stream an ISP-free SoC accepts. Fit the ISP-dependent variant to a board without that ISP and everything up to the handshake looks alive — I2C probe, banner, registered subdevice — while the video path never completes, and the handshake fails with it.

Test. Read the variant marking on the module and match it against the vendor's support table for your SoC before debugging anything else. This is a hardware property, so no device-tree edit bridges it. What raw sensor output means when no ISP is present is explained in CSI camera with no ISP.

Fix. Fit the on-module-processing variant of the camera, or move to a SoC that integrates the ISP.

Fix it in this order

1. Query the subdevice: v4l2-ctl -d /dev/v4l-subdev0 --all, and decode the interface-version control with the formula above. A clean 65537 sends you to steps 2 and 3; a 0, an error or another value sends you to step 4.
2. Scan the same output for 'error 5 getting ext_ctrl'. Restore the extended-control path first — a producer reads controls as extended controls, so EIO here is the 0.0 in the making.
3. Print the media graph with media-ctl -p and confirm sensor → CSI receiver → capture node, ending at the node the producer opens.
4. Match the driver banner version and the producer version to one vendor release, and point GENICAM_GENTL64_PATH at that producer's directory alone.
5. Confirm the compatible string binds the driver variant your SoC family needs.
6. Confirm the camera hardware variant matches the SoC's ISP capability.
7. Run the producer again. The warning gone and the camera enumerated means the handshake passes; frames flowing means the data path passes too.

When to leave the MIPI route

MIPI buys the smallest camera head, the lowest power and the highest bandwidth per watt; its price is a kernel driver you must port, pair and keep matched. When the handshake resists after all four causes, the fastest route to a shipping machine is a camera on a standard transport: a GigE area scan camera is discovered by the producer over the network with no device tree and no kernel patches, and a board-level camera on USB3 does the same inside the cabinet.

The LS-BCM-0003 is a 3.1 MP USB3 board-level camera with a 1/1.8" global-shutter sensor rated at 120 fps, the fit for a compact head doing close, fast checks. The LS-BCM-0020 is a 6.3 MP GigE module with an 18 fps rolling-shutter sensor on a CS-mount, the fit for static scenes at the end of a network run.

For a conventionally mounted camera at the end of a longer run, the MV-CU020-90GC is a 2.5 MP color GigE camera with a 1/1.7" global-shutter sensor on a C-mount — the shape machine-vision software expects to find with no driver work at all.

Decide by distance and mount first, resolution second: inside one cabinet, USB3; across a cell or a building, GigE; and match the mount to the lens range you already standardize on, C-mount or CS-mount. The camera finder filters by interface, mount, shutter and resolution, so the substitution takes one pass.

Keep the pair pinned

Ship the versions, not just the image. Record the driver version and the producer version in the build you deploy and print both at boot, so a field swap cannot silently mix a pair. Keep exactly one producer directory in GENICAM_GENTL64_PATH. Treat the handshake as a self-test: an application that opens the device through the producer, reads the interface-version control and fails loudly on anything but 65537 turns a silent 0.0 into a flagged fault at power-up.

If the standard-transport route fits your machine better, configure camera and capture side together from the camera step of the system configurator. The rest of the embedded bring-up playbook — probes, overlays, streaming failures — is gathered on the systems topic page.