And progress is so extremely slow. Look at the activity dates. I also have looked at developer activity and they basically put their 80% of attention to Squeekboard (on screen keyboard) (and other stuff). You can see the activity log. I understand, that it is important, but I think they would need to spend their time on camera support, because Squeekboard works meanwhile camera doesn’t work at all.
Can some insider tell, why doesn’t camera get the full attention? It is an essential phone feature, just like calling and webrowser.
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.
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.
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.
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.
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 (123456).
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.
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.
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.
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.
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.
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).
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.
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.
Therefore there’s