[Tinkerphones] ZeroPhone site offline

Andreas Kemnade andreas at kemnade.info
Mon Jan 3 21:32:16 CET 2022


Hi,

I am also adding my unfinished thoughts here.

On Sun, 2 Jan 2022 22:01:51 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

[...]
> > "The Pine64 developers and the community need to put more focus onto making 
> > the PinePhone perform the most basic of mobile phone tasks, Like making and 
> > receiving phone calls, using headphone earpieces, receiving and sending SMS, 
> > phonebook. The basic essential stuff required for someone to just buy this 
> > pinephone and use it to replace a cheap android phone. Focusing on apps and UI 
> > and all that stuff means nothing if the average idiot cant use this phone out 
> > of the box!"
> > 
> > https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5521
> > 
Well, I had also my bad experience: USSD is even working better with my
simple dialer on the GTA04. So what is the point here. Designing
something more complex than you have resources to test and maintain
it? 

> > There's also a lot of complaints about Signal not being available for the 
> > phone, but I think that those people bought the wrong product.
> >
hmm, I do not understand the point, it would be good to have some
messenger available, if it is opensource. I would expect that I cannot
connect to everything, but at least to something.
 
> > The PinePhone initiative seems to be an interesting experiment in seeing 
> > whether various Linux-plus-graphical-environment distributions can deliver a 
> > usable phone experience. I recall things being said about the Openmoko 
> > FreeRunner not being quick at handling calls, with assertions about the 
> > software stack not being responsive enough to deal with the different 
> > hardware-driven events, and I imagine that despite a lot of disdain for what 
> > Openmoko and others sought to achieve all that time ago, the situation is 
> > still not that great even now.  
> 
So we are at the same place with just consuming more ressources for
that?

> Hi Paul,
> you have probably pinpointed the most important aspect of all discussions.
> 
> We have no high-quality power management in any of the devices...

I think that need to be a bit more differenciated to find answers.
- power management with quirks in your backyard?
Many of the N900 regressions seem just to be a problem with runtime
pm, if you have scripts to put your device into suspend, it is not that
problematic. Even the vendor firmware of e.g. the Kobo firmware does
that.
And I have seen a kernel maintainer just running some pm reading script
on the droid4 showing awesome values.

- power management in specific configurations?
For the N900 there seem to be a lot of kernels where it runs reliably,
maybe it does not get tested too well.
The question is here maximum achieved power management vs.
theoretically possible. 


- What kind of devices have proper power management?
SoC + PMIC combinations often have, for omap3 there are some boards
which have. So next question, if you add something to devices with
proper pm, how much can you add without causing pm trouble.
N900 and also droid4 adds modem via serial, GTA04 via USB. The latter
causing trouble, because of some errata with the pmic.

But there is still the question where the diff between GTA04 and N900
comes from.

> We spend (spent) a lot of time to make it work, get hardware out just
> to get the same feedback as you have cited above.
> 
> We (as the OpenMoko and GTA04 community) have faced it. I think also
> the Librem 5 has. And the Pinephone you have cited.
> 
> What should be different?

I have not analyzed things too much with the Pinephone, so here it is
with the GTA04.

There are three fields: maintenance, clean it up and getting it low
initially.
Maintenance needs probably only the pinephone to disappoint me even
more... to finally fix up scripts and wirings... So priority..
Manpower? How much do you need, unclear question. If regressions are
spotted, work could be distributed to fix that or to create workarounds.

Getting things initially lower. IMHO there had to be more intensive
work with the beagle-hybrid (and other stuff). So how much can you add
to the beagle without messing up things? Here we have a chicken-egg
problem. If we do not know the problems we do not know what is the
solution. So git bisect good beagleboard ;git bisect bad
beagleboard+additions. 

Freedom to test? E.g. I cannot do e.g. things with that beagle hybrid. I
do not have it, so I would need to convince someone to test things for
me for example. And developers are like cats... For my day-job I have
a bunch of different boards and developments at home now. You would not
have that stuff if you just have one phone.

I am wondering whether creating pools at local linux organisations
would help, so people could easily share things.

Cleaning things up needs people with kernel knowledge (including
processing stuff and unwritten rules) and hardware knowledge, but not
so much equipment, you have always chances to bisect between good and
bad. But on the n900 and droid4 the way from vendor kernel to ml was
somehow done, afaik there is a modem driver missing. Somehow here the
answer is mainly manpower, not something organisational.

No fully finished thoughts here.

Regards,
Andreas


More information about the Community mailing list