[Tinkerphones] Librem 5

[Jonas Smedegaard]

Quoting H. Nikolaus Schaller (2021-02-13 14:53:00)
> 
> > Am 13.02.2021 um 11:52 schrieb Jonas Smedegaard <jonas at jones.dk>:
> > 
> > Quoting michael spreng (2021-02-13 10:45:18)
> >> In December I received my librem5 phone and now had some time to try 
> >> it out. It seems to work reasonably well, can make phone calls and 
> >> messages. Though there is no support yet for the camera.
> > 
> > Seems camera support saw progress for the low-level driver part as 
> > recent as yesterday: 
> > https://source.puri.sm/Librem5/linux-next/-/merge_requests/309
> > 
> > User-level access to camera seems tracked here: 
> > https://source.puri.sm/Librem5/Apps_Issues/-/issues/6
> > 
> > Using the camera from sripts seems possible since 2 months (but possibly 
> > specific to certain revision of the phone, or maybe the devkit): 
> > https://source.puri.sm/Librem5/linux-next/-/merge_requests/255
> > 
> > The phone ships with the more stable "amber" release of PureOS.  Geeks 
> > might wanna explore the in-progress "byzantium" release instead, to get 
> > and play with bleeding edge changes: 
> > https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html
> > 
> > 
> >> Though programs not adapted for the phone screen are rather weird, 
> >> like vlc.
> > 
> > A geeky way to locate _some_ adaptive apps is to look for packages 
> > depending on libhandy-1-0 (or libhandy-0.0-0).  That only covers GTK 
> > apps, though - I am unaware if any such package-level indicators exist 
> > for Qt-based apps like VLC.
> > 
> > The user-friendly way is to use the appstore, which shows only adaptive 
> > apps - and yes, there are only very few so far...
> 
> I am sure this will change.

If by "this" you mean availability of adaptive apps, then I agree: Seems 
to me there is enough momentum - e.g. multiple vendors reusing code from 
each other, all tied to mainline Linux


> Our GTA04 history shows that the basics must work and then come apps. 
> Unfortunately it is a sisyphos work to make the basics work and keep 
> them running... So manpower to keep pace with upstream kernel releases 
> is key.
> 
> The main reason why we were (are) stuck with QtMoko and Replicant 
> is that the kernel is still not in a perfect shape like people need
> so that they can focus on improving their apps. And in the meantime
> nobody knows any more how to rebuild QtMoko and Replicant from scratch
> on a recent build system.

Seems to me the failure is directly tied to getting code pushed 
upstream.

Obviously when upstream project is dead (as is the case for QtMoko) 
there is no way to upstream - apart from taking over as upstream.  And I 
guess over-the-fence upstreams like Qt and Google can be painful to push 
changes to (e.g. require copyright assignment), but I am not familiar 
with the details of those.

Purism evidently invest in pushing code to mainline Linux and u-boot 
(and other projects higher up the stack as well).  Time will tell if 
they push enough, and if there continues to be enough momentum.

I am optimistic.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.goldelico.com/pipermail/community/attachments/20210213/80e07b5b/attachment.asc>