Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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 testableby ClumsyPilot
- 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 - 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 - 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.
- It is almost certainly AI-written. Very odd writing style, also the repo README is Claude-generated.by flawn
- 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 - 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
- Good to see this! Love Fairphone!
- I wish one day I could do cool stuff like that. Kudos!by BraveOPotato
- Never give up!by tuutuP
- I'm sure you will!by nondescriptp
- 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 - Amazing, I didn't see this yet. Indeed seems like it is well on track to become a usable device now.by nondescriptp
- Link broken... https://lemmy.ca/post/68231524by helonaut
- have fairphone looked into supporting GrapheneOS? what exactly is missing there other than "it's not Pixel"?by NooneAtAll3
- A team of people patching and releasing firmware and hardware drivers to the public on a monthly basis.by izacus
- 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 - The hardware doesn't support the relevant security features GrapheneOS requires.by Telaneo
- It's a pity those IMX and ISOCELL sensor chips are unobtainable from Digikey.
Anyone with experience buying them in smaller quantities?
by amelius - 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
- 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