@caveman

Somewhere along the enormous amounts of kernel patches I noticed power usage doubled and I cant think of anything particular that caused it or pinpont it in any way. Currently too busy to start poking with it.

@caveman, again, and other interested parties..
Powertop:
The battery reports a discharge rate of 169 mW
The estimated remaining time is 22 hours, 18 minutes
Display off, kbleds off, wlan on. My not-that-good battery at 90%.

Anyway, display hogs quite a lot power, soo, I quickly put up replacement /etc/acpi/handler.sh for acpid to toggle display and kb leds on/off with lock switch. Note that though it puts display on/off, it does not disable input. There are ways to handle that from X. I'll see if I can figure something else too, will be reporting back.

EDIT: Well, I added few arguments to the script so you can lock the input too, you will need xinput and something to execute a script on XF86ScreenSaver keypress, like xbindkeys, which I use.

Been quite busy this week, and will probably remain so, forgive me my absence. Here's the reply-to-all post..

Probably depends on what you expect, I think both performance and functionality is pretty good. Most people who seem to actually use it, seem to be quite satisfied. Feel free to correct me if I'm wrong.

Well, a few at least. Though not related to this, Pali is doing a great job with upstream kernel. While following the progress there, I'll try to keep my old tree up to date, keep the distro running and try to experiment, test, fix, optimize, do everything better, document, help etc. People here and on IRC are also contributing in many ways, so, even though our user count is probably not that high, the activity in here is quite good indicator of dedication indeed.

Try it out and see? I still think it's somewhat useless/strange to compare native, full Linux distribution with a chroot environment. I don't know anything about EasyDebian, never used it and never will, but I suggest that you start comparing by setting up Arch chroot (plenty of guides and scripts to do that around) and perform whatever tests you may find relevant.

Probably a quite tiny improvement, at best

Not sure I understand you. This can be installed on both emmc or sd-card, partition does not matter as long it's big enough and extfs.

Always wondered why it was set up as kp_enter. There's probably no-one against it if I change it to return?

Arch installation guide tells you to create that symlink. I've heard timedatectl not working if you somehow managed to avoid running systemd, which I doubt. No other idea.

Usually window managers expect modifier + key combination for stuff like that, so try Mod5 (or mod5, might be something that is defined in a conf, depends) or whatever your IL3 Shift is mapped as. Just an idea, hopefully it helps.

Not sure that would be a good idea. Out of the mobile GUI's around, most are bloated ****. Then again, I don't know the details, but it's probably possible unless they've done something evil to tie the GUI to some particular platform/whatever. You're trying to get me interested, aren't you?

Out of curiosity, does it "only" disables input, or put digitizer to sleep too? Otherwise, even if unused, digitizer eats quite a lot of power, due to being "on voltage" (and awaiting for input, that is processed by it's hardware and send to system, then ignored, cause you disabled input).

As said, if you took care about it, scratch the above. If not, it may be something worth investigating (no idea how to achieve it, though - probably need to mimic something that maemo is doing).
---

Overall, awesome work. Going to install Arch soon, and experiment a little with things that made Easy Debian faster (like using eMMC for system and swap on microSD *only*).

BTW, I wonder, if performance boost could be achievable, by putting crucial components on rootfs *with compression off* (as many things, as possible to put on this limited space)?
---

I've heard, that hildon-desktop is running on arch too. It's more like a proof-of-concept only, or actually usable for something? IMO, it would be nice to have familiar and very good, lightweight Ui like hildon-desktop, on top of Arch (with other things as available alternative/for certain task, of course).
---

Any sights about utilizing telephone stack?

/Estel

Ofono works with outdated/patched pulseaudio but it breaks audio elsewhere. Tested two way calls and they worked fine. Although no GUI, everything needs to be done using ofono-scripts.

Maybe Ubuntu phone will create a reusable GUI phone. Related question, not answered yet:
What GSM middleware will “Ubuntu for phones” use?

"Only" disables input devices. No idea how to disable-disable the device, though I'd think that would/should be done by driver/xinput, in 2013. sysfs entry for runtime pm shows auto, if memory serves. Unfortunately that doesn't prove anything.[/QUOTE]

It's possible but you would need to either rebuild kernel or create initfs as onenand etc are as modules.

Proof-of-concept, though it does work as a window manager without a hick. Or did when I last tried, at least.

GUI for ofono could be easily written, but what exactly you mean by "break sound elsewhere"? Break it at all, or only during call?

In case of future projects that would recreategui for phone, addressbook (or using some existing project?), and sms database (mms code could be borrowed from FMMS on maemo), this project could become what deblet failed to be - a full featured alternative system (without sacrificing phone functionality) for N900.
---

I suspect, that power-saving bits may be harder than phone things. IIRC, it was first major issue to overcome for Mer. I wonder if things of interest for disabling-disabling hardware parts may be found in their source code?

Maemo's idle power consumption (with offline mode, screen locked etc) is as low as 3-4 mA per hour. Quite a challenge to replicate it.

I post my results for comparison. Usecase: powertop at the console, and let it sit there for a while (+1 min) after the screen went blank, no X running, wifi on and connected.
discharge rate @ 66.6mW
estimated remaining is 57 hours
my battery reads 63% charged.

The only power-related changes applied were enabling SR and
+ cpufrequtils.

Yes, probably so. There is sphone which I think would be a great candidate. It needs updating regarding ofono, and some UI love at least but to me it appears as a good base for minimal GUI tool to handle this stuff. I do have some other expectations about this matter though, more about it later on this reply.

Nokia blobs require somewhat patched PA 0.9.x. We are going at version 3.x in Arch, so PA support breaks for everything, when downgrading. I'm not that fancy about the idea of recompiling, packaging and hosting everything that is linked with PA, so this is clearly a temporary solution for testing, and can generally be used as audio still works with alsa without any problems.

Now, I have PA3, with just about everything from Nemo, compiled and packaged in my testing repo, I'll move it to n900-extra as soon I've done enough testing with it so those enthusiast enough can start trying to get call audio out of it. Personally I would want everything to work with alsa, but I guess there is relatively little or no hope for that happening at all, ever.

The expectations I briefly mentioned.. I want to be able to do everything possible from command line, and without X. At this point, I want small, simple and suckless (carefully planned choice of a word) CLI C applications, as well as shell scripts, to do stuff that we need to do with this device, be it testing out something or just using it daily. That's my priority.

After that comes all the GUI stuff, applying the same expectations I have for CLI tools, preferably using them instead of reinventing the wheel.

Then, for the potential developers, and why not everyone else; I don't want any absurd forks used/created which will be soon left unmaintained an tie us with, let's say, a certain version of some dependency; if something needs patching, send the patch upstream if there's even a slightest chance it could get accepted. If not, keep it simple, minimal and public, so if you lose interest someone else can continue. Don't deviate too far from upstream, keeping changes at absolute minimum.

Of course, these are just my random thoughts of the matter.

This is the goal I'm heading at, with a steady snail paced movement, and was the founding idea when I started. That and the distribution being a proper, real, lightweight, flexible, up-to-date, simple, efficient and fast Linux system.

I have a lot of plans (and a way too less time and almost no development skills), some of those including a thought about doing a complete spin-off (already is, in a way) of Arch/Alarm for our purposes, since there are lots of stuff in both that are either completely wrong or not suitable as-is for our use. We'll see where all of this leads us to.

Challenging indeed. Currently my focus is elsewhere, so I'm happy with what I got, though I do know there is got to be a way to decrease the power usage somehow and someone has to make it happen. Of course if I notice something, I'll share and I'm quite confident all our fine users will do the same.