Two days ago a solo developer posted images of a crisp ultra-wide camera feed running on postmarketOS atop a Fairphone 6. The phone, barely a year old, already carries mainline kernel patches submitted the same day it launched. Yet the path from those patches to a working sensor reveals how much work remains before Linux phones escape the experimental category.
Fairphone built its brand on repairability and longevity. The model 6 carries a five-year warranty, modular parts and a promise of extended software support. It runs on a Qualcomm Snapdragon 7s Gen 3, offers 8GB of RAM, up to 512GB of storage expandable by microSD and a 6.3-inch 120Hz OLED panel. Pricing starts around €599. The company also ships source code and binary blobs openly, a stance that caught the eye of kernel developers.
Phoronix reported on June 25, 2025, that 14 patches landed on the Linux kernel mailing list the morning of the announcement. Luca Weiss, a frequent contributor to Qualcomm upstream efforts, drove much of the DeviceTree work for the SM7635 SoC and the Fairphone 6 board. Those patches enabled basic boot and peripheral support. Cameras stayed out of scope.
One independent researcher decided that omission was unacceptable. Writing at nondescriptpointer.com on July 21, 2026, the author detailed an experimental port that brings the phone’s 13-megapixel OmniVision OV13B10 ultra-wide sensor online under mainline Linux. The post carries no byline but describes heavy use of large language models to accelerate driver work. The result? GNOME Snapshot displays a usable feed. QR codes scan. The other two cameras remain dark.
The hardware setup sounds simple on paper. Three rear and front modules sit inside the Fairphone 6. Sony IMX896 handles the main 50-megapixel shot. Samsung S5KKD1 manages selfies. OmniVision’s OV13B10 covers the wide angle. Only the OV13B10 enjoys a mainline driver. The others require proprietary Qualcomm CAMX code that the open-source qcom-camss driver cannot replace yet.
Data flows through a classic Qualcomm pipeline. Image sensor talks over I2C. MIPI CSI-2 lanes carry raw pixels to a CSIPHY block that decodes them. CSID demuxes the stream. The TFE665 ISP writes frames to memory via DMA. Supporting clocks, power domains, a dedicated camera I2C controller and voltage rails complete the picture. Downstream kernels hide this complexity inside thousands of lines of closed code. Mainline demands every link be described explicitly.
The developer started by auditing what already existed. PostmarketOS maintained a mainline-based kernel fork for the milos platform, the internal name for SM7635. Clock controllers for the camera subsystem and the CCI I2C bus were present. Register maps showed the TFE665 ISP shared DNA with the supported TFE530. CSID and CSIPHY revisions matched known families with only offset and tuning differences. Porting looked feasible.
First came the capture subsystem. A new camss-vfe-665.c file mirrored the existing TFE driver but adjusted base addresses. The write bus had moved. CSIPHY v2.2.1 needed fresh lane tables transcribed from vendor headers. Device-tree nodes declared four CSIPHYs, three CSIDs, three TFEs, their interrupts, interconnects and power rails. A previously undocumented CAM_CC_SOC_AHB_CLK proved essential. Without it register reads returned zero and resets timed out. Once enabled the ISP reported version 0x30000000 and frames started to move.
Sensor bring-up hit its own snags. The OV13B10 driver existed only for ACPI-based x86 laptops. An OpenFirmware compatible string let it probe on ARM. Device-tree described the I2C address, 19.2 MHz MCLK, reset GPIO and power sequencing. Lane numbering tripped the first bug. Vendor trees used one-based indexing. Mainline expects zero-based. Wrong values left the PHY unable to lock. Correcting that produced frames. They were all black.
Logs showed a “Bad config violation” on every buffer done interrupt. Downstream code revealed the cause. TFE665 ships with a 128-bit RDI bus while the older TFE530 used 64 bits. The packer format register needed a different constant. Changing one value from 0xa to 0x0 transformed solid black into a perfect color-bar test pattern. Real scenes followed. The full capture chain now worked.
Raw Bayer data satisfied a quick QR scanning script. Daily use demanded more. Libcamera 0.7.2 already contained a generic pipeline handler that recognized the new qcom-camss graph. Its software ISP, accelerated by the Adreno GPU through EGL, delivered 30 frames per second and clean RGB output to GStreamer and PipeWire. Applications saw the camera as an ordinary V4L2 device.
Auto-exposure refused to cooperate. Images swung between underexposed and blown out. The library complained it lacked a sensor helper for OV13B10. A 20-line patch added the missing class. The sensor’s gain register maps linearly with 0x80 representing unity. That matched other OmniVision parts already supported. Convergence improved immediately though some overexposure persists in high contrast scenes.
Focus required extra steps. The ultra-wide lens uses a voice-coil motor driven by what appears to be an Awinic AW86017. Probing revealed a device at I2C address 0x0c speaking the DW9714 protocol. The existing dw9714 driver controlled it without modification. Libcamera lacks a software autofocus algorithm so the developer fixed the lens at a distance optimized for documents and QR codes using a udev rule. The physical mechanism works. Future updates could expose dynamic control.
Orientation and resolution quirks needed attention. The sensor mounts rotated relative to the phone’s portrait mode. Device-tree properties corrected preview rotation. Binned modes advertised by the sensor driver produced sheared, garbled output on this particular ISP path. The author disabled the offending modes so libcamera selects only full-resolution streams that render cleanly. Preview quality suffers slightly without scaling but stability wins.
Forum conversations reflect tempered expectations. On the official Fairphone community forum users note that ports for earlier models took one to two years to reach daily-driver status. Ubuntu Touch lists no estimated arrival for the Fairphone 6. One contributor observed that Marius is working on it but offered no release date. A separate Sailfish OS thread from February 2026 reports community porting efforts nearing first release yet still far from official backing.
PostmarketOS already boots the phone. Mobile data remains absent. The camera work described above represents one of the final major blockers for basic functionality. Audio output still needs similar attention. Once both land the device could serve as a credible daily driver for users willing to accept some rough edges.
The achievement stands out for its solitary nature. Fairphone supplied the hardware documentation and kernel patches that made the effort realistic. The developer supplied the perseverance and clever debugging that turned theory into images. Large language models apparently filled gaps in register knowledge and boilerplate. The post credits them explicitly while stressing that human oversight remained essential.
Industry watchers see broader implications. Qualcomm’s upstream contributions have grown but camera pipelines stay among the most stubborn holdouts. Each new SoC still requires significant reverse engineering or vendor cooperation. Fairphone’s willingness to publish source and encourage alternative OSes sets it apart from most Android OEMs. Whether that stance survives commercial pressures will determine if the model 6 becomes a milestone or a one-off.
Meanwhile the researcher continues tweaking. Overexposure needs refinement. Additional sensors could follow if drivers appear. The phone’s long support window gives the open-source community time to close the remaining gaps. For now users can scan codes and take wide-angle shots on pure mainline software. That counts as progress worth watching.
WebProNews is an iEntry Publication