I agree and haven’t seen any evidence of urgency on this, despite it being a huge gap in Librem 5 functionality. Maybe purism is working around the clock on this and we just don’t see it? In any case, it would be nice to have some more info on how things are progressing.
2 Likes
The cameras are getting as much attention as they can, but it’s not unlimited. There are 2 important factors:
- winter holidays
- the task is really difficult with half-documented hardware, making it close to reverse engineering. I can’t speak for Martin, but I needed a break with something where I could make actual consistent progress, or else I was risking burnout (that’s when nothing gets done at all).
You can see the priorities from the fact that we have 2 engineers dedicated to this area.
27 Likes
Thanks for your response
I hope I speak for all when I say: As strong as we would like to see the camera working, your health is more important. Take the time you need for yourself. Work is not everything.
13 Likes
Thanks for the response! Yes health is the most important thing.
Super excited for the camera development. I think it’s the last thing before I would be very content with the phone. Other development will be great too, such as suspend/inactive-battery-life, but to me, that’s just icing on the cake.
2 Likes
NXP has been lackluster in supporting its i.MX 8M chips in mainline Linux, and the mainline driver still doesn’t have good support for the i.MX 8M’s MIPI CSI2 camera interface. When asked about this issue, Guido Gunther responded on August 17, 2020:
CSI2 for mainline is still being worked on (as is mhdp for DisplayPort HDMI) by various parties but the diff has become more and more reasonable.
The “diff” is the difference between the code in NXP’s driver and mainline Linux’s driver for the i.MX 8M. This means that Purism has to take code from NXP’s driver in order to use the MIPI CSI2 interface. Another difficulty for Purism is that NXP has poorly documented its MIPI CSI2 interface, and people on the NXP forums are complaining that they are having trouble implementing their cameras (1 2 3 4 5 6).
At this point, the problem is the poor documentation by NXP of its CSI2 camera interface and you should read the links to the NXP forum threads that I provided if you want more info. NXP provided one sample implementation with a 5MP camera, and just expected everyone to figure it out from that sample implementation, rather than properly documented how their interface works. I could understand if NXP had just released the chip, but the i.MX 8M Quad has been in mass production since Jan. 2018. Just like NXP has never fixed the 2 bugs in the chip’s power management and never fixed the bug that limits USB 3.0 to 150-170 MB/s (see the FAQ for links), NXP hasn’t bothered to properly document its CSI2 camera interface.
I don’t know if NXP is ever planning to fix these problems in the Quad, or will only fix them in the future i.MX 8M Plus. At this point, the Plus is now almost a year behind schedule. Honestly, it is really depressing that the i.MX 8M is the best option available for making mobile devices (laptops, tablets and phones) that can run on 100% free software, because NXP has done a pretty bad job so far.
All NXP had to do was add two Cortex-A7x cores to the Plus and do a die shrink, but instead it designed a chip with a worse VPU and GPU and hasn’t fixed the problems in the Quad. Given that Samsung offers 11nm, 10nm and 8nm FinFET, it is pretty disappointing that NXP went with Samsung’s 14LPP FinFET for the Plus. NXP isn’t even trying to offer competitive mobile chips, compared to the RK3566, RK3568 and RK3588 that Rockchip will be releasing in 2021.
9 Likes
Wait, what? they have 2 power-managment silicon bugs, which they refuse to fix? Holy shit.
And yes, 2x weaker gpu and slightly better (but still shitty 4 cpu cores) doesn’t make it better. Looks like I will need to put my L5 Fir batch order to later batch. I really don’t want a piece of shit SoC.
Whoa. RK3588 looks really promising. I just hope, that transition would be smooth. I am worried about driver support of Arm Mali “Odin” MP4 GPU.
Personally, in ideal case I would want that Purism collaborates with many similar thinking organizations (such as Raspberry pi foundation (which expressed a wish for binary blob free RPi)) to slap together a good RISC-V mobile SoC, with help of Sifive or similar company. In that way they would have saying not to put IP in, which requires proprietary drivers to work. Just think about it. In that way Purism could reduce separate chips on the board and not reverse engineer proprietary drivers.
1 Like
1 Like
It is horribly under-powered, expensive devkit. Librem 5 seems like an absolute bargain compared to that thing. There is no RISC-V SoC. The RISC-V cpu can be implemented in FPGA and then it will run at 100MHZ, which is nothing.
1 Like
Yeah, I am glad that the documentation is free to access at all and somewhat complete, so I’m not going to diss it a lot, but it’s confusing in several important places. Still, that we have to use a datasheet for the I.MX7 series to find out half of the info about the CSI interface is silly.
8 Likes
As far i know NXP fixed the big bugs related to energy leaks on the soc, so all L5 it fine.
Starting from Linux 5.10 Purism is working on the support of the camera and gps and smart charching.
1 Like
At the kernel side GPS has worked for a while already - you can access NMEA data with sudo cat /dev/gnss0 and observe it getting a fix. What’s still missing are some user-space parts, but that’s coming (you can already get it to work on apps that use geoclue, but it needs some manual assembly at the moment).
14 Likes
Wow GNSS is already supported on the kernel. Thank you very much.
2 Likes
Nice. It only need a button in Posh to ON OFF the GNSS.
At present I only need a soft back cover to protect my L5 of falls TO USE IT AS MY DAILY DRIVER.
2 Likes
Can one also select which GNSS should be used in case one particular system is sending wrong coordinates?
Where can I find directions on how to do this?
Otherwise, when will it be fully functional?
Geoclue doesn’t open GPS devices by itself, so it needs to work with gps-share. There’s https://github.com/zeenix/gps-share/pull/17 that makes it work with new GNSS kernel subsystem that we’re using.
That should already work as a proof of concept, but gps-share works by broadcasting NMEA data over network, which is likely something you don’t want 
Therefore there’s https://gitlab.freedesktop.org/geoclue/geoclue/-/merge_requests/79 and https://source.puri.sm/angus.ainslie/gps-share/-/commits/local to make it work with local Unix sockets as well.
5 Likes
Is look that we will have GNSS working on apps very soon. Thank you @dos for the amazing work well done on L5!
1 Like
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.