Fairphone 6 wide camera experimental Linux support

7/23/2026 at 9:54:37 AM

It's a pity those IMX and ISOCELL sensor chips are unobtainable from Digikey.

Anyone with experience buying them in smaller quantities?

by amelius

7/23/2026 at 10:39:38 AM

They aren't intended to be available frankly. You either buy them as camera modules, smartphone type or IP camera type, or don't at all.

A part of it is just how involved the manufacturing of those camera modules is. The sensor chips ships as bare silicon dies. They're precisely placed, glued and wire bonded to the substrate PCB, then adorned with a focus/OIS voice coil frame and a lens assembly. Absolutely nothing about this process is hobbyist friendly.

The other part is that corporations are incredibly stupid about how "valuable" their precious proprietary data is, and would rather jump into a volcano than give a sensor datasheet to someone who doesn't look like they have at least 20 lawyers employed and can take a MOQ of 100000 units. And how would one use a sensor without a datasheet, or a bring-up register sequence, or anything at all?

Vendor buying agreements and NDAs often prevent hobbyist-grade sensor boards from even existing. Especially for cutting edge high performance sensors, like the ones found in flagship smartphones.

by ACCount37

7/23/2026 at 12:36:34 PM

Ok, how would you buy them if you were a small company making e.g. scientific instruments?

by amelius

7/23/2026 at 12:50:05 PM

You wouldn't!

You'd buy instead an "industrial/automation/automotive" sensor - one that has a fraction of the raw resolution, but maybe spots some other perks. Like a global shutter with no rolling shutter distortions, a "no RGGB Bayer" option that lets you set up your own filters and pick what wavelengths you care about, a package that's amenable to low volume manufacturing, longevity guarantees, availability in quantities of tens instead of tens of thousands, or actual documentation that you can get without 3-6 months of salesman and lawyer negotiations.

Or you'd buy a ready-made "scientific instrument" camera from someone else. Which probably has another "industrial" sensor - maybe worse, maybe better than one you could get directly, depending on how up to date the catalog is and how good of a working relationship does the instrument company have with the sensor vendors. And a price tag in 4-5 digits range. Then you would integrate that thing as a subsystem into whatever science hardware you wanted to make.

But if you truly want the "flagship smartphone" mix of small sensor size, low cost and high resolution? There are no good options! Clearly, the tech just hasn't advanced far enough for that!

by ACCount37

7/23/2026 at 3:01:36 PM

Then how do you explain that Digikey still sells many camera sensors.

For example this one:

https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus...

by amelius

7/23/2026 at 6:29:53 PM

Have you even looked at this datasheet? This is one of those "industrial" sensors I was talking about.

It's not CMOS. It doesn't even have a digital interface. It has basically nothing in common with the kind of image sensors you'd find in a flagship smartphone, like Samsung ISOCELL. It's a very specialized device made for a very short list of uses, none of which are in consumer electronics.

Most sensors you'll see there are similar. Not all of them are as hideously exotic as the one you linked, but very few of them are the SKUs you'd find in a smartphone. The closest thing to a smartphone camera sensor would probably be STMicroelectronics VD56G3, which is similar to VD56G0 that Apple uses in iPhone FaceID. And even that is a specialized structured light NIR piece.

by ACCount37

7/23/2026 at 7:03:33 PM

Ok, I'm still curious who the audience is of websites like:

https://semiconductor.samsung.com/image-sensor/

by amelius

7/23/2026 at 7:56:19 PM

Probably just the tech press and the rare industry clients who aren't already in touch through other channels. They sure aren't selling to hobbyists.

The contact data is real, but you'd have to at least look like a decent sized company to get anywhere with it.

by ACCount37

7/24/2026 at 7:08:41 AM

Well, it is all very disappointing. This is what integrating supply chains brings us, I guess.

by amelius

7/23/2026 at 10:32:07 AM

There are some vendors that have a good variety of IMX sensors boards. Usually labelled Board Level MIPI camera, some with usable v4l drivers.

by immmmmm

7/23/2026 at 1:40:49 AM

have fairphone looked into supporting GrapheneOS? what exactly is missing there other than "it's not Pixel"?

by NooneAtAll3

7/23/2026 at 5:09:10 AM

It would take extensive work to achieve the hardware requirements and the capability for an OEM that isn't able to develop their own chips with Memory tagging enforcement (mte) which the Snapdragon 8 Elite used in the upcoming Motorola phones will have. It won't be cheap and it won't be easy.

Google has set the bar high with their security features.

by Cider9986

7/23/2026 at 1:45:51 AM

The hardware doesn't support the relevant security features GrapheneOS requires.

https://grapheneos.org/faq#future-devices

by Telaneo

7/23/2026 at 1:47:08 AM

[flagged]

by NooneAtAll3

7/23/2026 at 2:46:48 AM

That's a pretty concrete list so it's unclear to me what you mean. They're also going to support some of the upcoming Motorola phones so it's not just pixels.

I think the short answer of what they'd need to do in a practical way is to release a phone that uses one of the latest Qualcomm processors (those have the required hardware security features), make sure they have at least 5 years of driver support and commit to keeping the phone up to date, allow for relocking the bootloater (they might already do that). And I think that's basically it, the Graphene project would be able to take things from there.

Realistically given that they tend to source older/weaker processors for reasons related to their goals it's unlikely they would source a processor with the required security features for their next model, but that's just a guess.

by svpk

7/26/2026 at 5:09:44 PM

We say 5 years in the requirements but we want 7 and are starting to expect it. Pixels have provided 7 years since the Pixel 8. Qualcomm provides 8 years of support for new platforms and non-Pixel OEMs are using it to begin claiming to provide 7 years of support. However, we need the updates delivered on time and not becoming less frequent over time. For example, Samsung moving to quarterly updates for older devices isn't what we expect.

by grapheneos

7/23/2026 at 1:50:20 AM

Fairphone hasn't talked about GrapheneOS at all, instead opting to be in bed with Murena and /e/os, so I doubt they've even bothered to read the list of hardware requirements. They didn't bother with the Fairphone 6, which was released barely a year ago.

by Telaneo

7/23/2026 at 4:06:42 AM

[flagged]

by warrantisall

7/23/2026 at 6:21:52 AM

Fairphone 6 does not fulfill the hardware requirements (secure enclave, MTE, etc.), nor software requirements (monthly firmware updates, etc.). So there is nothing that GrapheneOS can do at this point. The ball is in Fairphone's court if they want this, but Fairphone seems more interested to cooperate with /e/OS, whose CEO proclaims security hardening is for pedophiles and spies (thereby fueling the narratives that support chat control and such nonsense).

One of the underlying reasons is probably that the Fairphone hardware and software is developed/maintained by a Chinese ODM (T2Mobile), so the question is if Fairphone even has the know-how to make such a phone. Heck, they have failed to fix bugs that have been plaguing people for months (e.g. regular dropping of all connections when using IPv6 on certain routers).

Motorola is going to make devices that fulfill the requirements and GrapheneOS is cooperating with them.

by microtonal

7/23/2026 at 12:03:02 PM

At this point in time any open source phone is a great improvement. Theoretically, we can add the security features ourselves.

by inigyou

7/26/2026 at 4:59:58 PM

It's not an open source phone. It's closed source hardware with closed source firmware. The closed source userspace drivers/services could be rewritten but the hardware and firmware isn't in the same situation.

Hardware and firmware level protections can't be added by software.

Software features based on hardware security features also can't simply be added without those. Translating code to add a software equivalent to MTE could theoretically be done but would make the code require several times more CPU cycles and several times more memory. You would need far higher performance hardware and a bigger battery for that to be practical. MTE is what GrapheneOS uses rather than that.

by grapheneos

7/23/2026 at 4:36:01 PM

Depends what you mean by open source phone, do you mean open hardware? If not, you cannot retroactively add MTE or a secure enclave. Even if it was open hardware, it is kinda hard to do small production runs.

by microtonal

7/23/2026 at 6:46:52 PM

Graphene demands one, but you don't have to.

by inigyou

7/23/2026 at 8:43:07 PM

Sure, but then you have to run a different OS. That's completely fine of course, between Graphene, Sailfish, etc. there is a lot of interesting stuff happening.

by microtonal

7/24/2026 at 2:43:58 AM

The most important part of Graphene for most users isn't the super security - it's that it fights for the user, not for some corporation.

by inigyou

7/26/2026 at 4:58:44 PM

GrapheneOS is a privacy project making major privacy improvements. Privacy depends on security so that's why it improves that too.

by grapheneos

7/24/2026 at 6:16:31 AM

Yeah, but I thing the best security is very important to the GrapheneOS developers, so I don't think they will ever compromise on MTE (except pre-Pixel 8) and a secure enclave. Of course, someone could fork GrapheneOS to support phones that don't fulfill the requirement. Also, I think fighting for the user is also true for e.g. LineageOS. As far as I know they are also a non-profit.

by microtonal

7/25/2026 at 11:35:27 AM

It is. But you can get almost all of the benefits on hardware without that. Someone has to port it, though - Graphene won't. Yes, it's also true for LineageOS and you can use that too.

by inigyou

7/26/2026 at 4:57:57 PM

No, you can't obtain almost all of the benefits of GrapheneOS on other hardware. Many of the benefits depend on having current privacy and security patches along with hardware-based security features.

by grapheneos

7/23/2026 at 10:33:46 AM

[flagged]

by stymaar

7/23/2026 at 11:36:33 AM

You conveniently picked a different quote. From the horse's mouth:

"Par contre, on a pas une approche "sécurité durcie", on développe pas un téléphone pour les pédo(bip) pour qu'ils puissent échapper à la justice."

"However, we do not have a "hardened security" approach, we are not developing a phone for pedophiles so that they can escape justice."

Also see: https://infosec.exchange/@Xtreix/116356764298456420

by microtonal

7/23/2026 at 11:56:18 AM

It's pretty insulting to be called a pedophile for wanting privacy from bad actors.

by UnreachableCode

7/23/2026 at 12:16:15 PM

The “only for pedo and spies” quote is still wrong no matter how you twist it, as illustrated above.

by stymaar

7/23/2026 at 12:42:16 PM

I have no idea what you are talking about. Let's end it here. People can look up the source material and make their own judgment.

by microtonal

7/23/2026 at 12:58:26 PM

When someone says “features that are clearly valuable for executives and others” you can't claim he said it's “just for pedo and spies”, even he also said it'd also be useful for pedo and spies.

That's just plain bad faith.

by stymaar

7/23/2026 at 4:41:39 PM

The quote Par contre, on a pas une approche "sécurité durcie", on développe pas un téléphone pour les pédo(bip) pour qu'ils puissent échapper à la justice. is literally in the linked video. I encourage everyone who does not speak French to put it in their favorite translator. He literally says However, we do not have a hardened security approach, we are not developing a phone for pedophiles so that they can escape justice.

It is very clear what he is implying here, namely what I said in my original message.

He has repeatedly done so in various publications. E.g.:

https://www.clubic.com/actualite-604786-murena-e-os-intervie...

Mais surtout, il ne faut pas se tromper de combat : /e/OS permet à ses utilisateurs d’échapper à la collecte massive de données personnelles qui s’opère dans les smartphones du marché, pas d’aider les pédocriminels à passer sous les radars de la justice.

Translation:

But above all, we must not fight the wrong battle: /e/OS allows its users to escape the massive collection of personal data that takes place in smartphones on the market, not to help pedophiles to slip under the radar of justice.

He repeatedly implicaties that only sex offenders need a security-hardened phone.

If we wasn't trying to throw a shade at GrapheneOS and other more secure systems, why does he continuously associate device security with pedophiles?

by microtonal

7/23/2026 at 8:09:55 PM

> He repeatedly implicaties that only sex offenders need a security-hardened phone.

On he doesn't! You trying to read implicit things when there's an explicit rebuttal of your interpretation just a few seconds later in littetaly the same extract!

You can be upset that he talks about pedophiles at all, but you can't claim he said it's ONLY for pedo when he said right after that it's REALLY USEFUL FOR EXECUTIVES.

Listen, I, unlike you who seem deeply invested in GrapheneOS's crusade against this dude, have zero skin in this game, I didn't know this guy before a few hours ago when I stumbled on this thread. But here you're literally making things up from a short video that literally says the opposite of what you're arguing against, and it's painful to watch.

The whole point of his argument is “we're not addressing the most security sensitive segment”. And while I can understand that you don't like that he talks about pedophiles at all, I'm pretty sure talking about “our phone isn't for pedophiles” is mostly to avoid adverse customers reaction against how they “aren't criminal and don't need a device to go to the darknet”.

by stymaar

7/23/2026 at 8:41:20 PM

Can we please not resort to personal attacks? For the record, I am not deeply invested in the project, nor in any way related to the project.

As for the rest of your comment, thank you for giving your point of view. Although I don't agree, I appreciate that you took the time to explain how you came to your position.

Cheers.

by microtonal

7/23/2026 at 11:05:45 PM

Why are you complaining about personal attacks when you began with an attack on a person by misinterpreting what they said and accusing them of things they didn't claim?

by izacus

7/24/2026 at 6:05:33 AM

The grandparent assumed and stated things about me that are not true. I have quoted things that the CEO of the given company actually said and I think a lot of people will come to the same conclusion. If he repeatedly brings up pedophiles in the same context as security hardening, then it at the very least it is very suggestive. Why mention pedophiles at all?

Everybody needs a security-hardened phone. Apple has been hardening iPhone for almost 20 years. Google has hardened Pixel from the start. This isn't specifically about GrapheneOS. Everybody should be worried, this is the kind of narrative is what drives Chat Control, etc. Security hardening (in reality) protects us against malicious apps, attackers, (to some extend) against privacy-invading apps, etc.

So, I ask you: what is the point of raising pedophiles in more than one interview when talking about security hardening?

By the way, I don't expect an answer. It's a rhetorical question. This discussion has been beaten to death. I think at this point we have to agree to disagree.

by microtonal

7/23/2026 at 11:10:00 AM

[flagged]

by bornfreddy

7/23/2026 at 5:04:52 AM

>GrapheneOS smearing Fairphone as not secure in 3..2..1..

GrapheneOS would love to support more devices, that "smearing" is explaining that a company doesn't make secure devices, which is completely correct criticism.

Fairphone for various reasons is not able to or willing to achieve the hardware requirements. It's not easy to create some of the worlds most secure devices.

by Cider9986

7/23/2026 at 9:35:41 AM

They've given concrete reasons to not work with them. If Fairphone made devices that fulfilled the requirements, then there wouldn't be any issue.

by Telaneo

7/23/2026 at 6:50:09 AM

[dead]

by surcap526

7/23/2026 at 7:58:14 AM

A team of people patching and releasing firmware and hardware drivers to the public on a monthly basis.

by izacus

7/26/2026 at 5:08:23 PM

It would need to provide that for around 7 years. It would need to avoid getting increasingly delayed over time. It would also need to provide the hardware-based security features required by GrapheneOS. That includes a proper secure element with the features we need and fully functional hardware memory tagging usable for all of the kernel and userspace. Motorola Mobility is working on providing what we need for next generation devices. Fairphone repeatedly expressed disinterest and is partnered with a company taking AOSP in the opposite direction from us for privacy and security. Fairphone replaced their own OS with that and it was a major downgrade moving them further away from possibly ever providing what we need.

by grapheneos

7/23/2026 at 3:25:03 AM

[flagged]

by warrantisall

7/23/2026 at 6:13:45 AM

I don't have anything to do with GrapheneOS (only using it on a phone), but the security of Fairphone is not great, like many other Android phones it does not have a separate secure enclave to store secrets, but instead relies on a TrustZone-based TEE, which is often vulnerable to side-channel attacks (e.g. see the recent attack where a lot of MediaTek phones could be decrypted in seconds, even in BFU). Note: iPhone has had a secure enclave since iPhone 5s (2013), Pixel since 3 (Titan M, 2018), and Samsung flagships since S21 (I think? Knox Vault, 2021).

They also do firmware updates very irregularly even though Qualcomm does monthly bulletins and Fairphone's firmware is known to be full of CVEs. They also have a bad history of updating Linux kernels, e.g. Fairphone 4 is on an ancient Linux kernel. Fairphones also miss modern security mitigation techniques like MTE.

To be fair, this applies to many Android phones outside Google Pixel and Samsung flagships.

Aside from that, repairability is nice, but the most common early failures on the Fairphone 6 seem to be broken volume buttons, for which Fairphone does not offer a replacement and an issue where the logic board dies during charging, which is also not user-replaceable.

---

Ps. perhaps you could use substantive arguments the next time? E.g. which points of the GrapheneOS lists of requirements do you think are irrelevant and why are they irrelevant?

by microtonal

7/23/2026 at 8:00:13 AM

They're also pretty behind on major OS updates and even bug fixes last I've checked. The software story was very disappointing when I wanted to get one.

by izacus

7/23/2026 at 4:59:12 PM

Yep. I was interested in more sovereignty and degoogling to some extend. So I got a Fairphone 6 with /e/OS. It was only until I dug a bit deeper into the OS image and the microG source code that I found worrying things:

- Old kernel versions with many known CVEs (applies to both stock an /e/OS).

- Old firmware bundles with many known CVEs (applies to both stock an /e/OS).

- Old major Android version, so missing fixes for vulnerabilities not marked high/critical (applies to both stock an /e/OS).

- Chinese firmware blobs, TCL image processing firmware (applies to both stock an /e/OS).

- When using the App Lounge, F-Droid installs go through a proxy (CleanAPK), that Murena does not want to reveal the purpose or owner of. Given Android's trust on first use policy, this could be used to intercept installs and install malicious packages. (/e/OS)

- Runs microG privileged. When an app does Google Play Integrity checks, Google's obfuscated DroidGuard blobs run privileged (/e/OS).

- Runs many Google apps (e.g. Google Maps) with higher privileges (/e/OS).

by microtonal

7/23/2026 at 8:16:47 AM

How do they intend to comply with the European CRA act then?

by warrantisall

7/23/2026 at 9:10:19 AM

That is a question I cannot answer - and CRA is pretty new, so we'll see if anything changes.

by izacus

7/23/2026 at 6:40:51 AM

Different priorities. GrapheneOS prioritizes very strong security (inside a very specific model that includes treating the user as an attack vector to be protected against). Fairphone prioritizes repairable hardware (and actually makes their own hardware). On a finite budget (of both money and time and people), prioritizing either one of these will undermine the other.

by yjftsjthsd-h

7/26/2026 at 4:55:20 PM

No, GrapheneOS is a privacy project. Privacy depends on security which is the only reason we work on security too. /e/ and Fairphone both have much worse privacy than the standard Android Open Source Project on decent hardware. They go in the opposite direction from AOSP which GrapheneOS does for privacy.

Privacy depends on fixing widely abused privacy weaknesses by patching privacy vulnerabilities and shipping major privacy improvements. /e/ is missing many standard Android privacy patches and protections. Privacy also depends on security to avoid it being bypassed. It's also missing many of the standard Android security patches and protections. GrapheneOS preserves the baseline and makes major privacy and security improvements along with being far better at patching vulnerabilities rather than far worse.

/e/ and Fairphone don't do the bare minimum to protect user privacy and security by keeping up with updates. Both are missing crucial standard patches and protections needed against many real world adversaries including widespread privacy abuse by apps.

by grapheneos

7/23/2026 at 7:19:26 AM

and actually makes their own hardware

Fairphone hardware and software is developed/maintained by a Chinese ODM (T2Mobile).

by microtonal

7/23/2026 at 8:18:50 AM

[flagged]

by warrantisall

7/26/2026 at 4:53:20 PM

Privacy depends on fixing widely abused privacy weaknesses by patching privacy vulnerabilities and shipping major privacy improvements. /e/ is missing many standard Android privacy patches and protections. Privacy also depends on security to avoid it being bypassed. It's also missing many of the standard Android security patches and protections. GrapheneOS preserves the baseline and makes major privacy and security improvements along with being far better at patching vulnerabilities rather than far worse.

/e/ and Fairphone don't do the bare minimum to protect user privacy and security by keeping up with updates. Both are missing crucial standard patches and protections needed against many real world adversaries including widespread privacy abuse by apps.

by grapheneos

7/23/2026 at 8:55:01 AM

You can't have good privacy without good security

by preisschild

7/23/2026 at 9:02:37 AM

[flagged]

by warrantisall

7/26/2026 at 4:52:39 PM

We definitely don't see privacy and security as binary.

Privacy depends on fixing widely abused privacy weaknesses by patching privacy vulnerabilities and shipping major privacy improvements. /e/ is missing many standard Android privacy patches and protections. Privacy also depends on security to avoid it being bypassed. It's also missing many of the standard Android security patches and protections. GrapheneOS preserves the baseline and makes major privacy and security improvements along with being far better at patching vulnerabilities rather than far worse.

/e/ and Fairphone don't do the bare minimum to protect user privacy and security by keeping up with updates. Both are missing crucial standard patches and protections needed against many real world adversaries including widespread privacy abuse by apps.

by grapheneos

7/24/2026 at 6:20:31 AM

It turns out that companies also 'attack' your phones to get your data. E.g. at some point Facebook/Yandex apps opened localhost sockets for tracking pixel code to connect to:

https://localmess.github.io/

by microtonal

7/26/2026 at 5:11:33 PM

GrapheneOS largely prevented it for Vanadium before this came to light and fully fixed it long before Chromium did. Android 17 prevents cross-profile loopback connections, which is one of many important privacy improvements in it. Android 17 fixed a massive number of privacy weaknesses including vulnerabilities which will not have patches backported. Only a subset of High and Critical severity patches are backported to older Android releases. Only a subset of that subset are shipped by /e/ despite claiming to provide the latest patch level.

by grapheneos

7/23/2026 at 10:45:36 AM

[flagged]

by stymaar

7/24/2026 at 6:23:52 AM

Fully agree. In the end everybody has to make their own threat assessment and make their choices based on that. I think research is particularly important to unravel what data leakage there are in various phones and apps, so that people can make informed choices. I think this kind of information presented presented in a neutral way is sorely missing.

by microtonal

7/23/2026 at 10:44:31 AM

[flagged]

by benrutter

7/26/2026 at 5:05:58 PM

/e/ goes in the opposite direction from AOSP for privacy and security compared to GrapheneOS. It lags far behind on providing standard privacy/security patches and protections. It bundles their own privacy invasive services and has many built in Google services with privileged access. /e/ devices do not have reasonable privacy or security. People are much better off with an iPhone if they care about privacy.

https://discuss.grapheneos.org/d/24134-devices-lacking-stand...

by grapheneos

7/23/2026 at 11:45:18 AM

Another dev has been hard at work bringing Fairphone 6 Linux support for calls, audio, microphone, NFC, GPS, and IMU: https://blorp.piefed.zip/inbox/u/https%3A%2F%2Fani.social%2F...

It's now probably the most modern well-supported pmOS phone.

by pizzaiolo

7/23/2026 at 12:36:55 PM

Amazing, I didn't see this yet. Indeed seems like it is well on track to become a usable device now.

by nondescriptp

7/22/2026 at 11:47:34 PM

I wish one day I could do cool stuff like that. Kudos!

by BraveOPotato

7/23/2026 at 7:38:18 PM

I'm sure you will!

by nondescriptp

7/23/2026 at 7:53:34 PM

Never give up!

by tuutuP

7/22/2026 at 11:07:56 PM

Good to see this! Love Fairphone!

by noIdeaTheSecond

7/23/2026 at 2:56:56 AM

Does the article seem AI-written/assisted to anyone else?

Some parts that stood out to me: > A phone camera is not a single device. On Qualcomm SoCs, the capture path is a chain: > The bus register base moved from 0xa00 to 0x1800, and encapsulating that offset shift accounted for most of the work. > It gated the AHB register bus used by the whole camera complex, including the CCI. Without it, register accesses silently returned zero. > With the wrong numbering, CSIPHY programmed a lane mask with lane 0 missing, and the PHY never locked. > This was the main bug. Frames arrived at the right rate and size, and buf_done fired, but every pixel was zero. [...] The data path delivered frame timing, but not pixel data. > Changing the register value from PLAIN64 (0xa) to 0x0 turned the all-zero frames into real images: the maximum pixel value was 255, the full colour-bar pattern appeared, and the violations stopped.

Sorry if not, but it seems like so much uses AI nowadays.

by Throwaway698514

7/23/2026 at 9:01:18 AM

I submitted this article, as the author of the blog article is my close friend and we’re trying to build an open phone stack together. He clearly wrote that he used Opus for helping him write the driver. He also used LLM to help him write the article, but everything in the post is correct. The fact is that 1) the driver has been fixed and the camera is working (most important accomplishment) and 2) humans are able to help make drivers in a fraction of the time cost that it used to take. Both points are remarkable and deserve HackerNews top 1 position. Vote up please! :)

by helonaut

7/23/2026 at 6:06:43 AM

Before AI slop, I rarely saw humans make so many words bold and explicitly mention all affected filenames. On the latter point, humans try to convey the main ideas, while LLMs tend to enumerate the files they changed.

Since this post has a lot of terms in bold and enumerates filenames, yes, it seems at least ai-assisted.

by microtonal

7/23/2026 at 7:37:51 AM

I've been doing it all along. Formatted texts just look well from the point of perception — same for em dashes.

by warrantisall

7/23/2026 at 5:40:15 AM

It is almost certainly AI-written. Very odd writing style, also the repo README is Claude-generated.

by flawn

7/23/2026 at 9:03:55 AM

True, the article was written with LLM help. Although the most important takeaways are that 1) the camera driver for the FP6 has been fixed and 2) humans can help produce drivers in a fraction of the time cost thanks to LLM help. These are both remarkable enough to vote this article to first place on HackerNews :)

by helonaut

7/22/2026 at 8:16:01 PM

[dead]

by helonaut

7/23/2026 at 1:10:51 PM

[flagged]

by 1970-01-01

7/23/2026 at 1:54:40 PM

Really bad attempt at trolling. Linux works on the fairphone. Just with proprietary and non-mainlined firmwares.

by prmoustache

7/23/2026 at 2:50:06 PM

The phrase "standing on the shoulders of giants" comes to mind. So what happened here? Shouldn't there be at minimum a framework for making a camera driver? Nope. They're gluing everything together and hoping it works.. Again. This is not standing on the shoulders of those that came before. It's the same issues year over year over year. It isn't trolling, it is calling out the highly non-optimal, "reinvent the wheel using these bits we have lying around" situation for getting things working.

by 1970-01-01

7/24/2026 at 5:25:56 AM

Linux on desktop and Linux on phone hardware are entirely different beasts.

Phones have literally never been open. Historically telecommunications has kept a tight, tight grip on everything, hardware and software included.

Even android, which is open source and based on Linux, cannot boot on any devices on earth without propriety blobs for the hardware. There is not UEFI or ACPI for phones, it doesn’t exist.

The entire history of IBM PCs and phones are just very different. This isn’t a Linux versus the rest thing. We already HAVE Linux on phones, for decades. That’s not the problem. The problem is the hardware manufactures and firmware. They absolutely will not let it go.

We saw this when Qualcomm entered the PC market. They wouldn’t upstream fuck all, and surprise surprise those chips were destined for the trash bin due to low support. That just doesn’t fly on PC, even on Windows. Say what you will about x86, intel and amd. But at least it’s an open and interoperable ecosystem.

by preg_match

7/23/2026 at 8:39:12 AM

Has anyone had any luck in writing drivers using LLMs? It’s one of those areas of software that is very niche and no one wants to do it. And it’s also relatively testable

by ClumsyPilot

7/23/2026 at 8:52:10 AM

Drivers live at a nasty intersection of kernel land code, hardware-coupled code, poorly documented interfaces and undocumented interactions that have to be trialed-and-errored on real HW.

Modern LLMs kick ass, but they aren't magic.

Fully vibe coding a driver for things more complex than, perhaps, a well documented CMOS sensor (that's a small part of what's covered in the article) is still a no-no.

But an LLM does wonders at emitting boilerplate, "vibe checking" your implementations, suggesting how to implement certain things, helping debug some of the things, etc. You can get the LLM to do a lot, but you still need a lot of understanding, and a lot of applied handholding.

by ACCount37

7/23/2026 at 8:54:27 AM

Yes this was done with Opus 4.8 and it was very effective. I ran a local harness on the phone itself so it could probe around and experiment. You do have to reboot into a newly compiled kernel occasionally if a module reload is not sufficient.

Obviously this work was mainly porting downstream code and information so the scope was fairly limited but the diagnostics it could do were very impressive.

by nondescriptp