[MyL5] First Impressions of Evergreen (Tim's story)

I’d suggest actually decreasing input level, it should make it sound better.

Anyway, yeah, it’s known, but it’s just a software thing - see also my post in Librem 5 Ready-To-Market? (although I think I’ve changed my opinion about it being “good enough” already, I’ll try to spend some time on it again soon ;))


To include a quote, highlight the phrase you’re referring to. The option to Quote it in your reply will pop up. Select it and it will be added to your reply.

I wonder if you can the proper battery at Batteries Plus Bulbs outlets?

I can see it on ebay, so I don’t think it will take too long for Pottery and Pulps to pick it up.

We haven’t heard yet anything about suspend. we have heard that @dos has worked or he is working for the muffled-sound problem, we have heard that people have been working for cameras but I have not yet read anything about the suspend which is very important to my opinion.


Nobody is working on suspend explicitly, but there have been some power management improvements lately that will also matter for suspend, for instance https://source.puri.sm/Librem5/linux-next/-/merge_requests/279

Personally I believe that it’s way more important to keep extending runtime battery life and treat suspend as the very last thing in the chain of things needed to be done for good power management. Suspend isn’t a magical answer to all battery life problems - if you need to suspend to get reasonable battery life you’re going to be very limited with what you can do with your phone.


Well, I could just use it … as a phone? :wink: It wakes up and rings, I talk, I hangup, it goes to sleep sometimes after.

I know that there are not too many people who do not want to be bothered by their phones, but I am one of them. Fine for me if it just alerts me when a call or SMS comes in.

Anything else I want from my phone: I switch it on. Only thing that I could be missing would be if during suspend there could be no alert for appointments in my calendar. But I’d get over that, too, because I’m used to check from time to time.


I perfectly understand that and I’m looking forward to be able to suspend as well - it would match my usage pattern pretty well. That said, we’re probably in the minority and I still believe that reaching for suspend too early is just sweeping your problems under the carpet :wink:


From what I understood suspend mode would only work as a phone if you don’t follow the IP narrative. I moved with my family to a self hosted matrix instance using it to call and text each other which is basically the old phone functionality - however as far as I understand a suspended phone would not ring as it could not be woken up by the modem as the modem is only triggered by “real phone calls”.

that’s correct, suspend itself is not enough, there should also be wake timer and software optimised to use wake-timer. Eg. Nokia solved that with iphb 1o years ago which was making suspend while adjusting system monotonic timer (to become less monotonic). but that requires software which is either aware of non-monotonic wake-timers (passive) or actively using iphb timers instead.
In other words - adaptive ui is not enough for mobile pc, it also needs adaptive software.
I don’t know how purism is going to solve this, but I’m not aware of any method to solve it on a platform level (without touching the software). again - similar to ui (which also needs software changes).

Depends on the modem used. In theory, both the cellular and local wireless modems could trigger a wake event on the CPU. There are wake-on-lan protocols that will need to be supported.

You would not want to wake up the phone by any traffic. On the other hand you want your traffic to be encrypted so that only the phone knows that there has been a call or message. To decrypt the traffic the phone has been active. So the phone has to be active to notify me of an incoming call or text. So let’s sleep the phone and wake it up regularly to check if there’s a call or text. Calls are real time. No caller waits 5 minutes for other phones to check for calls. I hang up calls after 10-30s. Have in mind that accepting a call also takes some time (getting your phone out of the pocket, leaving a room, plugging in a headset …). It would be unpleasant if you always miss calls. So the phone could only sleep for second(s).

I conclude from this, that in order to use it as the ip narritive phone in everyday use for parents, CEOs and tech geeks suspend is not the solution to the battery run time problem.

But I could be wrong :slight_smile:

1 Like

Yup, but that’s okay. There is a requirement that the CPU firmware and kernel can cheaply and quickly move in and out of the suspend state. When the phone gets ready to sleep, it should disconnect everything that shouldn’t send notifications. This decreases the amount of traffic it’ll have to deal with. Then it software suspends the userspace stuff. Then it goes to sleep. When network traffic comes in, it wakes just the kernel, checks to see if something in userspace needs to be made aware (usually not, usually it’s just keepalive messages), and goes back to sleep. This wake->think->sleep cycle will happen a few times per second, but if it takes 20 μs to do one interrupt process, and does that 3 times a second, you’re talking 0.000060 seconds spent not asleep per second. Depending on the wifi card used, it might not even need to wake the kernel for simple ACK/ICMP packets.

As for the 20μs number… Assuming the CPU is running at 1GHz, 20μs is 20 000 cycles, which should be enough to see if the message is going to a userspace application.


Thanks and best regards to you. I suppose one probably must be sincere to commit the money and time we have to the phone. The world needs better choices.


Hi dos, thank you for your reply, I appreciate it. When the mic input level was at its out-of-the-box value of about 50%, my test call recipients had trouble hearing me amplitude-wise as well as intelligibility-wise. With the mic input cranked up to 100%, the sound level meters appeared below over-modulation, but I will reduce the mic input level down to 80% and try with the same test people this weekend.
In my particular case, phone call quality is the most important thing I use a phone for. Everything else is a nice to have except the hard switches, which fortunately for me already work. The camera for me is not a big deal, but others undoubtedly have different use cases. I know Purism has finite resources to accomplish many software items. If there’s any way I can help elaborate on what I’m finding, feel free to direct message me.
Take care,

@ruff nearly every time posts with interesting background informationg :wink:

The average linux admin would solve the problem by just having an wake-up interval - which clearly doesn’t help in the phone-over-ip setup if you’d expect a signal when an sms-over-ip or a call-over-ip arrives.

Another approach would be the one I see for the pinephone: They start to replace (parts of) the system running on the modem and I’m wondering whether it would be possible to implement very simple services there.

E.g. the modem could listen for traffic and when some data (like voice and sms also do) matches a certain pattern it could wake up the mainboard. Very rough and there is no real concept behind it, but it would implement some kind of wake-on-lan for mobile connection.

Well, we’ll see whether you’re right or not :wink: … The pinephone does suspend already and we can follow the progress to make it last longer unsuspended.

1 Like

Thanks for the clarification :slight_smile: I am eager to see this in the real world :slight_smile:

I sort of disagree. I am going to be annoyed that I have to power off my device and lose my session because suspend isn’t there.

I just need suspend to ram. I don’t care if the only way to wake from that is the power button initially. This ability is about cutting the cycle of charging simply to use the device. In a day I’m rarely actually using my phone for more than 2 hours a day collectively. The power on time is good enough already.

Furthermore, given the state of the Linux phone right now, standby is just a reality of phone life. Ignoring it to chase down a rabbit hole that is infinitely deep (optimization work is NEVER done) is something that can be fully embraced when there is a reliable power saving scheme in place. This scheme is standby (suspend to RAM) for the time being. This gives you all the time in the world to develop a low power mode, or work on runtime optimization.

From the discussion above it seems that there could be different types of suspend that work best for different usage patterns. Maybe this could be something that could be configured in settings. I guess that the “low power mode” on phones is one of them. Maybe there could be several others.

I’m talking about suspend to RAM as used by Linux. Other kinds of PM like turning the cores and peripherals off while not in use are either already there or being worked on.