A Link Without Conversion

The usual answer to distance is encapsulation. Take the video, place it inside another protocol — automotive SerDes, an Ethernet-based link — send that, and extract it again at the far end. It works, and those links are designed for distances beyond what a direct link is meant to cover. Encapsulation also has a cost, and the cost is structural: for coax SerDes, circuitry at both ends to protect a signal that now shares its conductors with power; for any of them, a control path that has to be tunneled because it no longer has wires of its own, and configuration in more than one device that has to be brought into agreement before a single frame moves.

The other answer is to leave the signal alone and build a front end that can receive it as it is, farther away. Same conductors, same protocol, same addressing — just farther. There is no encapsulation step, so there is no extraction step. The control channel stays physically continuous from the host to the sensor, which means the host reaches the sensor at its own I²C address and the camera's device driver stack does not change.

Latency is the propagation delay of the cable plus a fixed device delay, because no protocol layer buffers and re-emits the stream at either end. The image stays uncompressed in both directions — sensor RAW toward the processor, full RGB toward a panel. And the device count does not grow the way it does with an added protocol layer, because nothing has to be added at either end to protect a combined signal.

This is not the right answer everywhere. Automotive SerDes and Ethernet-based links are designed for distances beyond what a direct link is meant to cover, and where a signal has to travel the length of a vehicle, that is exactly what they are for. A direct link is for the distance between a camera and the processor that reads it — which is most of what drones, robots, edge AI devices, and open-source hardware platforms actually need, and the range for which MIPI was not specified.