Kernel Modules

If you have made it this far, you now face the next challenge: building IPU6 modules that are suitable for your own kernel from Intel's sources. Again, Hans de Goede has been extremely helpful with patches and many comments, which ultimately give you semi-finished to-go solutions for individual distributions. Ubuntu has all the patches required and available for the current drivers in its program as DKMS packages (again in the OEM Solutions Repository); you can use these packages to build the essential kernel module in the usual way.

If your distribution does not offer this solution, once again the only option is to download the sources from GitHub and complete the manual build process. Bitter pill: It is precisely because Intel puts so little effort into maintaining its IPU6 drivers that many IDs of chipsets for IPU6 cameras that are quite common in the wild are missing from the headers. For example, quite a few Dell models use IPU6 chips, which the driver theoretically supports but fails to identify due to ID changes.

Again, you might very well be left out in the cold and have no choice but to do it all yourself. This requires additional knowledge, of course; not only do you have to patch the kernel; you also have to develop the patch yourself. After all these setbacks, if you do get to the point where the driver actually loads, you still have a long path ahead of you.

Helper Construct

This is far from the end of the journey to the absurd for Ubuntu and Arch Linux users. Even if a fully patched kernel with all required libraries, firmware files, and correctly patched drivers is available, and the kernel successfully displays the new camera in dmesg, if you try to access it from Firefox or Chrome, for example, you will see only a black screen. The reason for this is that Intel has decided that the in-house IPU6 drivers do not need a compatibility interface for Video4Linux (V4L). Unfortunately, the V4L framework is almost exclusively used on Linux to integrate external video components such as webcams.

As if you hadn't done enough work, the next step is to install a relay daemon for V4L. What this does is, on the one hand, pick up the signal from the IPU6 chip, which is now hopefully working, and, on the other, pass it to a V4L pseudo device where the other programs can grab it in the usual way. This helper construct is reason enough for a moderately severe fit of rage, but getting over-excited will not help. If you want to use the integrated MIPI cam on your new current laptop, you have to tinker on.

But for all of this messing around in userspace to be fruitful, you first need yet another component. ipu6-camera-hal makes the IPU6 interface visible to the V4L relay daemon on the host's filesystem, and this, in turn, makes the interface usable. Again, Ubuntu and Arch Linux offer the software as a package via their repository paths, whereas Fedora and openSUSE users have to go through another round of tinkering.

Particularly grotesque: Patches for the V4L2 loopback pseudo-device, which ultimately allows conventional tools to access the camera, are circulating in bug reports for IPU6. The same is true for the relay daemon, which is actually a Ubuntu tool, but even there it will not interact with the remaining components out of the box. In its default configuration, the parameters in its systemd unit do not fit the bill; it launches but does not identify the IPU6 camera as a potential communication partner.

Just before the editorial deadline, the right packages with all the necessary patches to get an IPU6 up and running on a 10th-generation Lenovo X1 Carbon arrived in the OEM Solutions PPA [6] from Ubuntu that I mentioned earlier on. A look at the code in this repository could possibly help you rebuild the setup on another distribution.

On Shaky Legs

The fact that it was possible to use the camera to its full extent on Linux at some point in my test can ultimately only be viewed as a Pyrrhic victory. The entire construct stands on shaky legs. For example, you need to block automatic system updates for your home-built kernel in the package manager. Otherwise, the distribution will replace the work of art you so painstakingly cobbled together with the standard kernel the next time a vulnerability is fixed.

On the other hand, you don't want to be running an old kernel, especially on desktops and laptops. The risk of becoming a victim of an attack through an unfixed vulnerability increases significantly with each attack that becomes public. The fact that kernel guru Greg Kroah-Hartman has already given the thumbs down to the driver in its current form is not encouraging for the future. Intel would probably have to do an extensive code redesign to integrate the driver into the mainline kernel at some point. However, it seems unlikely that this will happen in the foreseeable future given the current state of the driver.