Sorry, I haven't posted here for a few months because u-boot (the October release) refused to boot my Archlinux and I didn't want to reflash the whole phone because of that.

Anyhow, Arch is working again for since the last u-boot update.

I'm considering to hack up a little daemon in C which would dim the screen after a certain delay (I've already got a working bash script but that's merely a POC because the event loop needed after dimming the screen to fully re-enable the backlight once the screen has been tapped eats quite some CPU whilst the goal is obviously to *save* power.

The daemon will be based upon xssstate (just as is the bashscript I'm using right now):
http://tools.suckless.org/xssstate

I'm also considering working out an improved German keyboard layout offering additional chars like &, |, <, >, `, tabstop, delete, brackets and curly braces.
I had already done one of these, but I can't find it right now, so chances are that I might have to restart from scratch.

Skry: I'm having 2 problems with the kernel right now:

1. I'm using acpid with a custom script to disable the screen, lock the touchscreen and the keyboard, and switch off the keyboard LEDs and the backlight (and to undo all those things when the screenlock trigger is pulled again). However, acpid refuses to start up automatically as a daemon during boot because it can't find /proc/acpi/events (it only works when I start it manually after I've logged into my X11 session). Could you please enable CONFIG_ACPI_PROC_EVENT in the kernel config to fix this?

2. I have added the option "ubi.mtd=rootfs" to the kernel cmdline in the bootmenu item file and I'm using the following line in my /etc/fstab to mount Maemo's rootfs:
I did have to comment it out however, because for some odd reason, the kernel refuses to mount that that file system during boot.
When I remove the # after booting up, and mount it with "mount /mnt/maemo" (as root of course), everything works fine and I can't find any problem (unless I forget commenting out the line again before rebooting). Any ideas what where to look for the culprit?


As far as the crackling audio is concerned, I've found out that for some reason, lxmusic (uses xmms2d) does *never* crackle whilst VLC has garbled audio as soon as you've once had a 100% load peak on the CPU (I use "sha512 /dev/urandom" in a terminal window to trigger the problem).
lxmusic even plays the music without the slightest problem when the cpu is at 100% from my sha512 test above. VLC however has a ridiculously high CPU load to begin with, and often reaches already one of those fatal CPU load peaks when you just try to jump to another position in the same song. If the audio is once garbled, it will stay garbled until you stop the playback of the song (just pausing it isn't enough) and restart it again. The bug seems to occur regardles of whether pulseaudio or plain ALSA is used.
I suspect some bug in VLC or one of the libs VLC is using, but I haven't investigated this thouroughly enough to be sure.

regards
Pascal