3 ms·

It needs a full-stack integration to work properly, it's an immense amount of work. The Linux kernel is great at lots of things, but being good at scaling back

It needs a full-stack integration to work properly, it's an immense amount of work. The Linux kernel is great at lots of things, but being good at scaling back power usage is not one of them. You'd want to be able to have timers that will wake the machine up form suspension that application developers can use and throttling of radios. The device has to be suspended, but you should still be able to receive calls. MacOS does this impressively well (try pinging your Macbook as it's slowly nodding off, and see the response time increase). Better still, you can ping a macbook over WiFi that's completely suspended - SSH and other services won't work, but the kernel will still be there and do some I/O - this requires some kind of a power-level aware system in the kernel that can coordinate with device drivers and have userspace interfaces for registering applications that might want to receive data when the machine should be suspended. The designwork required to achieve this with Linux and it's ecosystem is far more than the capable but small team at Librem can reasonably achieve, not because the team is small, but because this would require a lot of coordination between different upstreams.

outsomnia 6y ago
It's definitely a huge amount of work... there are many wrinkles to it, eg, if integrated to the radio firmware, it can do things like wake on specific network traffic and then go back to sleep if it understands the nature of the wake reason only extended to handle that network traffic on the cpu. But then if eg, the ssh session has keepalive enabled, there has to be infrastructure to schedule doing that coupled with another limited-scope wake and go back down afterwards. Last time I worked on this kind of thing there was great kernelside suspend support that works, but in terms of userland there was no generic linux arrangements for this kind of finegrained management of it. I also understand the point that for users, atm they just see no ability to defer when they will use the phone while it's still needed to receive calls, which is fatal. It seems properly solving this needs a new, separate userland project somewhere.

outsomnia 6y ago

It's definitely a huge amount of work... there are many wrinkles to it, eg, if integrated to the radio firmware, it can do things like wake on specific network traffic and then go back to sleep if it understands the nature of the wake reason only extended to handle that network traffic on the cpu. But then if eg, the ssh session has keepalive enabled, there has to be infrastructure to schedule doing that coupled with another limited-scope wake and go back down afterwards. Last time I worked on this kind of thing there was great kernelside suspend support that works, but in terms of userland there was no generic linux arrangements for this kind of finegrained management of it. I also understand the point that for users, atm they just see no ability to defer when they will use the phone while it's still needed to receive calls, which is fatal. It seems properly solving this needs a new, separate userland project somewhere.