I would have payed an extra fee not to have this camera bull**** in my phone. If I want to take pictures I use a camera. If I want to take bad pictures I am stupid. Still no excuse to continue this marketing fart called camera in a phone. Yes I witnessed how all that started as a marketing initiative to charge more MMS usage. Went wrong. Now we have to suffer from useless and expensive camera crap in the little computers called Smartphone. I would still pay a premium NOT to have this crap wasting resources and space and cause privacy issues.
What point is so difficult to understand to make me pay and possess devices I do not want? Camera is for photographs. Phone for talking. Computer for data processing.
My demand: No camera stuff at all in phones.
I pretty agree with that sentence, however people need to take simple reminder pictures for work or leisure (not necessary high quality artistic photo), perform some data processing and obviously talking, all this carrying around only one small device.
I donât think a no camera smartphone would be successful nowadays.
You can easily open the phone, grab the cameras (maybe not that easy) and throw them in the bin and save that extra fee.
If you want to rant more about that, you should open a new topic and let this one be about camera support dev.
I only have so many pockets when I travel. And I pack very light.
My phone takes excellent pictures. And itâs always on me when I walk out the door.
Feet for walking. Gum for chewing.
From a censor: I think youâre on the clear side. I try to err on the side of being lax, but if people flag posts, this can be hard 
Itâs not easy to find the right balance when different people have differing sensibilitiesâŚ
True. Iâve used a phone as a lame scanner. We donât all carry a scanner around with us?
There are lots of reasons for having a camera on a phone.
Generally the argument would be made that this niche market is not big enough for Purism to make two models, one with and one without. So Purism presumably needs to go with the majority. If anyone wants to debate that the majority wants a camera then start a topic with poll.
Purism presumably provides a couple of ways of disabling the camera.
- Thereâs a kill switch. Canât get more solid than that. However it will be necessary to enable the camera temporarily each time a call is made.
- It can be disabled in software. Blacklist the driver from the kernel?
- Get your phone today and disable software updates. (This is a joke, folks.)
according to x-ray view the camera module sits separately on a flex ribbon cable in a fpc connector. which is similar to pine phone. Iâve never removed camera module on L5 but on pinephone itâs quite easily done.
Thatâs fine. Just need to make sure that the software handles that nicely.
AFAIK beaglebone just announced a RISC-V SBC.
Except when there is no bubblegum. Then feet for kicking ass
Iâm referring to these silicon bugs, and as far as I know, they havenât been fixed:
The i.MX 8M Quad currently has two outstanding silicon bugs in power management:
e11174: CA53: Cannot enter WAIT mode
Description: CA53 platform cannot enter WAIT mode if there is a pending interrupt. If the chip enters WAIT(WFI) mode, the chip requires a reboot to recover.
Workaround: No workarounds. SW should not use WAIT mode.
Impact: This mode turns off the power to the SCU (Snoop Control Unit) and the L2 cache. Not having this mode affects only 1 mode of core power savings.e11171: CA53: Cannot support single-core runtime wakeup
Description: According to the GIC500 specification and the Arm Trusted Firmware design, when a CPU core enters the deepest CPU idle state (power-down), it must disable the GIC500 CPU interface and set the Redistributor register to indicate that this CPU is in sleep state. In such case, if the CPU core is in WFI or power-down with CPU interface disabled, another core cannot wake-up the powered-down core using SGI interrupt.
Workaround: One workaround is to use another A53 core for the IRQ0 which is controlled by the IOMUXGPR to generate an external interrupt to wake-up the powered-down core.The SW workaround is implemented into default BSP release. The workaround commit tag is âMLK-16804-04 driver: irqchip: Add IPI SW workaround for imx8mq".The MIMX8MQ6DVAJZAB used in Evergreen contains the 2N14W mask set which hasnât fixed e11174 and e11171. Given that NXP still hasnât fixed these bugs in the silicon after 2.5 years, it is seems unlikely that they will ever be fixed.
Thank for the info, i am new here.
I do not believe that the L5 evergreen is has a SOC Rv0, the link of the erratas that you share is from a revision 0 and old, it is possible that NXP does not have updated the PDF of errata revisions and hopefully the evergreen are without critical errors. 
There is some progress on this topic: https://source.puri.sm/Librem5/linux-next/-/issues/44
but:
To anyone getting too excited about this picture, fixing whatâs seen here is only half the work. Thereâs still the question of not having to reboot sometimes twicee between pictures, random shearing (see previous pic), and of focusing.
Best image so far (from https://source.puri.sm/Librem5/linux-next/-/issues/43 for the selfie camera):
In general I agree. I never use the phone camera because I carry a small rugged REAL camera with me all the time. It COULD be used for documentation if I for some reason do not have my real camera with me but it is about two years since I last used the phone camera. I vote for putting resources on other issues first for example battery time but I do not demand the removal of the camera.
is this the RAW data that comes from the sensor ? can we get a 1:1 ratio please ? ideally powers of 2 âŚ
We probably can, but we need to figure out how exactlyâŚ
Take a look on the git issue linked above. Raw data are available.
did any of you guys find this useful/relevant to the current/future camera goals ?
no updates from 2019-12-14 though ⌠i hope nothing BAD happened (the last activity was some time after my last donation to the project)