8 ms·
Fairphone 6 wide camera experimental Linux support
- helonaut 2mo ago[dead]
- noIdeaTheSecond 2mo agoGood to see this! Love Fairphone!
- BraveOPotato 2mo agoI wish one day I could do cool stuff like that. Kudos!
- nondescriptp 2mo agoI'm sure you will!
- tuutuP 2mo agoNever give up!
- NooneAtAll3 2mo agohave fairphone looked into supporting GrapheneOS? what exactly is missing there other than "it's not Pixel"?
- Telaneo 2mo agoThe hardware doesn't support the relevant security features GrapheneOS requires. https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices
- NooneAtAll3 2mo ago[flagged]
- Telaneo 2mo agoFairphone 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.
- warrantisall 2mo ago[flagged]
- Cider9986 2mo ago>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.
- microtonal 2mo agoFairphone 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.
- stymaar 2mo ago[flagged]
- warrantisall 2mo ago[flagged]
- microtonal 2mo agoI 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?
- izacus 2mo agoThey'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.
- warrantisall 2mo agoHow do they intend to comply with the European CRA act then?
- izacus 2mo ago
- Cider9986 2mo agoIt 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.
- izacus 2mo agoA team of people patching and releasing firmware and hardware drivers to the public on a monthly basis.
- grapheneos 2mo agoIt 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.
- benrutter 2mo ago[flagged]
- grapheneos 2mo ago/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-standard-privacysecurity-patches-and-protections-arent-private https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
- Throwaway698514 2mo agoDoes 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.
- flawn 2mo agoIt is almost certainly AI-written. Very odd writing style, also the repo README is Claude-generated.
- helonaut 2mo agoTrue, 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 :)
- microtonal 2mo agoBefore 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.
- warrantisall 2mo ago
- ClumsyPilot 2mo agoHas 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
- ACCount37 2mo agoDrivers 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.
- nondescriptp 2mo agoYes 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.
- amelius 2mo agoIt's a pity those IMX and ISOCELL sensor chips are unobtainable from Digikey. Anyone with experience buying them in smaller quantities?
- immmmmm 2mo agoThere are some vendors that have a good variety of IMX sensors boards. Usually labelled Board Level MIPI camera, some with usable v4l drivers.
- ACCount37 2mo agoThey 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.
- amelius 2mo agoOk, how would you buy them if you were a small company making e.g. scientific instruments?
- ACCount37 2mo agoYou 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!
- pizzaiolo 2mo agoAnother 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%2Fu%2FTheMightyCat https://blorp.piefed.zip/inbox/u/https%3A%2F%2Fani.social%2F... It's now probably the most modern well-supported pmOS phone.
- nondescriptp 2mo agoAmazing, I didn't see this yet. Indeed seems like it is well on track to become a usable device now.
- helonaut 2mo agoLink broken... https://lemmy.ca/post/68231524 https://lemmy.ca/post/68231524
- 1970-01-01 2mo ago[flagged]
- prmoustache 2mo agoReally bad attempt at trolling. Linux works on the fairphone. Just with proprietary and non-mainlined firmwares.
- 1970-01-01 2mo agoThe 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.
- preg_match 2mo agoLinux 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.
- 1970-01-01 2mo ago