Comparing specs of upcoming Linux phones

João, muito obrigado. Agora posso escrivir mais.

1 Like

Great post! I’ve found a few minor nitpicks:

  • etnaviv already supports OpenGL 2.1 as well (in addition to OpenGL ES 1.1 and OpenGL ES 2.0)
  • is there any reason to include “A2DP” in the Bluetooth row for PinePhone but not for Librem 5?
  • postmarketOS already has Librem 5 support merged in. I have tried it myself from an SD card a few days ago and it works :wink:
  • the smart card size is 3FF now; it was 2FF in Birch and Chestnut only
  • the photo with “Hardware kill switches and 2FF smart card on side of Chestnut” title actually shows kills switches and a SIM+microSD tray

@dos, Thanks for spotting those errors.

Are the specs for the Librem 5 at MobilityArena correct?

Specifically, MobilityArena says:

Rear Camera : 13 MP camera, f2.2 Aperture, LED flash, 1080p@30fps video recording
Front-facing Camera : 8 MP, f2.0 Aperture, 1080p@30fps video capture.
Music Support : PCM, AAC / AAC + / eAAC + / MP3 / AMR – NB / WB / APE
Video Support : H.264/MP4/MPEG4 player
Bluetooth : v4.2, A2DP
WiFi : Wi-Fi 802.11 b/g/n, hotspot
Battery Charging : 5V/2A Fast Charging

Specs on the Purism website say “Bluetooth 4” and don’t mention “A2DP” and WiFi “hotspot”. It isn’t clear which RS9116 chip is used, so I can’t check the Bluetooth version.

The free Etnaviv driver only supports OpenGL ES 1.1, 2.0 and 2.1)

OpenGL ES 1.1, 2.0 and OpenGL 2.1 - those are different APIs :slight_smile:

Regarding MobilityArena link, some of these things don’t really make sense since they’re software defined. A2DP is also one of those things - it’s a matter of software stack.

In fact RS9116 is said to support Bluetooth 5.0, but I don’t think anyone actually verified that with any Bluetooth 5.0 peripheral so far. Same with WiFi hotspot - although currently you need to switch the kernel module into a different mode to make use of it, which is kinda PITA; hopefully the driver can be improved in the future to do that automatically via regular interfaces.

OK, I am going to list it as “Bluetooth: 5.0 (only Bluetooth 4 verified)” with a link to your comment.

Pine64 says that it will support WiFi hotspot and A2DP, but it doesn’t sound like Purism has firm plans, so I will not list it for the Librem 5 until we know for sure.

Any chance that you can tell us what are the models of the image sensors for the front and back cameras in the Librem 5? (That is the big mystery that everyone wants to know.)

We sure want to support WiFi hotspot, but I’m not sure how well the driver supports it right now; will have to test it at some point.

Cameras are Samsung S5K3L6XX and SKHynix YACG4D0C9SHC.


@dos, Thanks. You’re awesome.

1 Like

Based on other posts in this forum, WiFi hotspot basically already works. However the interface is clunky i.e. no GUI and you probably have to configure manually from the shell. Good enough for developers and early adopters and techies. Not ready for the masses.

However I would take from that there are no driver issues e.g. putting the WiFi in AP mode rather than client mode, or something like that.

I did a bit of Googling and found that the Samsung S5K3L6XX and SKHynix YACG4D0C9SHC have no public documentation, but Replicant listed some specs:

Samsung S5K3L6XX:
1/3" 13Mpx CMOS sensor; 4224×3136 active pixels;
30fps @4K, 60fps @FHD, 120fps @HD; focusing range: 10cm - ∞ @AF; FOV: 81.5°

1/4" 8Mpx CMOS sensor; 3264×2448 active pixels; 30fps @QUXGA, 60fps @FHD (Crop), 90fps @HD; focusing range: 28.9-65.0cm; FOV: 83.3°

Although the Samsung S5K3L6XX supports 4K video, there is little chance that the Librem 5 will be able to use it. The i.MX 8M Quad has no hardware video encoder, and I only found NXP docs talking about video encoding 1080p at 30fps in software with the i.MX 8M Quad.

The only phone that I can find using the Samsung S5K3L6XX is the Galaxy J4+ which has a comparable Snapdragon 425 (4x 1.4GHz Cortex-A53, 28nm) processor, and its highest resolution video is 1080p at 30fps.

However, a review of the Galaxy J4+ praised its back camera:

As for the phone’s camera capabilities, the J4 Plus employs a solitary 13-megapixel camera unit on the rear, with a respectably wide aperture of f/1.9. This lacks the secondary depth-sensing unit of its bigger brother, the J6 Plus, although I don’t think this is a big loss. A 5-megapixel, f/2.2 selfie camera sits on the front of the phone.

Image 9 of 12

As long as you have plenty of light, the Galaxy J4 Plus is a pretty solid photographer’s companion. Of course, the results don’t look quite as swish as the images captured by fancy flagships such as the Galaxy S10 or Huawei P30 Pro, but the end result is an image that looks rather good given the price.

Pictures come out with plenty of detail, colour reproduction looks nice and accurate and the phone’s HDR algorithms do a tremendous job of lifting up shadows and softening overly-bright areas of the scene. Everything is captured well enough, but you begin to spot a handful of issues as the light dims. Mostly, images get too noisy for most tastes, although not distractingly so.

I kind of doubt that we will get the same image quality in the Librem 5 as the Galaxy J4+, since the Snapdragon 425 has an image signal processor and digital signal processor for providing HDR, plus it probably has some proprietary software magic as well. The i.MX 8M Quad lacks both an ISP and DSP. We also don’t yet have support for the cameras in the kernel and there is not yet a GTK/GNOME camera app. Still, Samsung ISOCELL image sensors are considered pretty good and we have a wide aperture, so there are some good aspects to the camera.


if i drop this 800 dollahs mediocre “camera” though …

The 4k 30 sounds awesome.
But I don’t understand why the hardware video encoding is necessary. The raspberry pi 3 soc neither has 4k video encoding but it is able to make 4k video. Can someone explain why the hardware encoding is necessary? Or is it just inefficient to let the GPU do the work?

The Librem 5 can output 4K video to a monitor (decode) just like the raspberry pi can. But neither the Raspberry Pi or the Librem 5 supports 4K encoding (taking a raw 4K stream and converting it to an encoded stream, a camera outputs a raw stream).

Having an encoded stream is necessary because otherwise the video will take up hundreds of megabytes every minute. Video encoding is simply compression that is lossy and is specifically optimized for video.


In theory you could create a driver that captures 4K raw video from the image sensor and writes it to a high capacity UHS-I microSD card. The L5’s microSD card uses a USB 2.0 bus, which can probably support up to 40 MB/s in duplex, and there are UHS-I cards that support 90 MB/s writing. Then, you could encode the raw video later with software.

Based on other posts in this forum, WiFi hotspot basically already works.

Do you have any links? This sounds pretty wrong - there is a GUI and has been from the beginning, but it doesn’t work (and same with regular CLI methods known from PCs) because from what I’ve seen in the docs the driver needs some special care in order to switch into hotspot mode - it needs to be put into hotspot mode at module load time.

I’m going to play with with sometime soon anyway and we’ll see :wink:

Tried it today and I can say that the WiFi hotspot works fine :slight_smile: Software still has rough edges and needs some love, but I got it to work here.

Looking at the driver docs ( it seems like monitor and P2P modes should work too, but I haven’t tried those so far.


I’m sorry, but that’s not possible in theory because you seriously underestimate how much space raw video takes up. 4K@30fps with 24bit colors I calculated to be around 5.7GB/s. It might however be possible in software to do encoding with a subset of the h264 standard to get it significantly down while still probably being fast enough, but an raw image stream is not possible.


Yes, you are right that it is way more than 40 MB/s, but I’m getting something different than 5.7 GB/s.

Here is what I calculate:
4096 x 2160 pixels x 3 bytes per pixel x 30 frames per second = 796,262,400 bytes/s = 0.8 GB/s

Am I missing something?

that’s 796,26 MB/s (mega-BYTES) x 8 = 6370,1 Mb/s so SATA III (6 gb/s) will be a little bottleneck …

Sorry you are correct, I wrote GB/s but meant Gb/s, so multiply it by 8 and you get close to what I calculated (I also just did 4000x2000 instead of 4096x2160). Most video applications measure bitrate in Mb/s rather than MB/s and I guess that’s also why it’s called bitrate rather than byterate.

My confusion was that the Raspberry Pi 3+ has only 1080p@30p hardware video encoding (H264).
Which is with the calculation mentioned here: 1920x1080 pixels x 3 bytes per pixel x 30 fps = 1.5 Gb/s
But in the picamera documentation:
there is also a mode to film with 3280 x 2464 @ 15 fps which is 2.9 Gb/s. Which is nearly twice the bitrate. What I missed was that this is only possible with the MJPEG format not with H264.

1 Like