i never would have guessed..just tested in sunlight..this mod is awsome!!..really..cssu stuff..thks a lot doc!

hi dr_frost_dk,
I try to run your custom_brightness_init script as a background process. it work most of the times, but the screen brightness will randomly set back to nokia's default value (in my case 51).
why is that? the script itself still running.
how you ever encounter this when you use the qbw?

hi dr_frost_dk,
I try to run your custom_brightness_init script as a background process. it work most of the times, but the screen brightness will randomly set back to nokia's default value (in my case 51).
why is that? the script itself still running.
have you ever encounter this when you use the qbw?

well there are 2 scripts, 1 script and 1 to start the other...., and no my brightness never goes to "stock" settings.

ok, I put "sh your_custom_script" to another file and running it as background program, and it's works like a charm.
thanks.

Hi all,

dr_frost_dk,
I'm currently using your custom brightness script with QBW. However I think it's better to strike at the source of the problem. I am a software developer specializing in C/C++ so it was pretty easy to find what's bothering us in filter-brightness-als (from the MCE source code, link has been posted before http://meego.gitorious.org/meego-mid...master/modules).
I believe it would be better to have ALS enabled (at least for the sake of the keyboard backlight control).
Firstly, here's how filter-brightness-simple works and why:
filter-brightness-simple.c, line 91:
What this means is that it will take the raw brightness setting (1 to 5) and multiply by 20, obtaining something in 20, 40, 60, 80, 100.
Then this will be converted (by another function) to the 0-255 value by simply multiplying by 255, that's how the 5 equal steps are obtained.
However the filter-brightness-als works differently and has the so-called "profiles" that decide what % of brightness the screen should be at from ambient light AND brightness setting.
There are a bunch of different profiles for different hardware (i think that's in order to be combatible with all NXXX models), but for Nokia n900, which uses the TSL2563 ambient light sensor, it is easily fount that the following profile is used:
filter-brightness-als.h, line 402:
This structure means:
1. The brightness setting (Minimum = 1, Maximum = 5)
2. In each setting we have intervals that indicate the ambient light domain (probably in lux), example: { 160, 320 } means from 160 to 320 ambient light value. I guess here -1 means infinite ambient brightness (or in any case very bright ambient, like in direct sunlight)
3. For each domain there is a setting for the actual screen brightness in % of maximum.
For example, the profile for Normal (brightness setting 3) states:
Which means that from 24 to 40 lux the screen will be at 17% brightness (which means: 43). From 100 to 200 lux ambient light - 30% brightness (translates to 76-77), etc.
I guess the gaps between neghboring brightness domains are for hysteresis - maintaining the same screen brightness stably not only based on current ambience but also on previous level. In practice this means that to switch to a different brightness the phone needs to be exposed to a substantially different ambience lighting (you've certainly all experienced that. annoying, innit?)
I find that in a bright office the ALS usually reports between 200 and 300 lux, which would put us in the { 160, 320 } range, which would give us the following percentages depending on brightness setting: 10%, 20%-40%, 30-60%, 90%, 100%
So here it is, the 30%-90% between setting 3 and 4 - that's your huge brightness gap and this is what should be solved as a general solution.
Furthermore, I believe this can be extracted into some external config file and loaded on boot (or MCE restart) so that to give almost limitless flexibility to the user (not that hard to do either).
Also another solution would be to put fixed steps for screen brightness but still use ALS methods for keyboard backlight.

Once the desired solution is implemented, compilation shouldn't be an issue as MCE ahs it's own properly written makefile.

I will keep you updated with my progress, but there are a couple of things that set me back: 1. I have no experience with creating .deb packages and submitting them to the repository (that's where such a patch belongs); 2. my usb broke off and I haven't been able to re-attach it yet (still waiting for some replacement parts and tools). This means I can't use the device in R&D mode properly. 3. I would choose to compile the modules on the device itself but can't install the package build-essential for some reason (will look into that more thoroughly once I get started).

P.S.: this is my first post (yes, I finally got around to register) and would like to take this oportunity to acknowledge the huge contribution of dr_frost_dk to the n900 community and to my personal user experience. Lately, whatever problem I have with my n900 google seems to invariably point to one of his posts. Thank you.

Thanks for the kind words , and da*m you know alot more then me on the programming front , i still basically use scripts, other then that i used to use QBasic (yes that thing from far far away)

But yes please keep me/us updated on this, i would be nice to have a real solution instead of this "patch" i made, it works but can still be improved (referring to my own custombrightness witch is the one im still using).

Yeah, it would be great to switch off or do something about display brightness regulation but leave everything else (LED pattern brightness) intact!
I know I am being overly sensitive here but isn't that what the N900 is all about, pleasing even the weirdest geek?

Yes! that's exactly my opinion! It's open source so it should be for the user to decide how it will behave and when!
First some bad news: I still haven't repaired my usb port, and although installed the build-essential package, still can't compile the MCE modules because of required environment flags and some missing headers (I guess).
Good news is I will try setting up the dev environment on a PC this weekend. It was a pain in the ***** as I remember it but will try nevertheless.

Now I want some opinions. Dr_frost_dk didn't like the original filter-brightness-als in part due to it switching display brightness in an annoying way (when you actually wouldn't want it to change).
First question is to those that are annoyed by this (as Dr_frost_dk): will less switching steps (ambient-related, and set further apart, more stable in theory) be ok or just do away with ambience-varied brightness altogether?
Secondly, would we be able to agree upon the 5 brightness settings and hardcode them, or go all the way and make them configurable from some .ini file somewhere?

Well, I wouldn't mind if automatic brightness would be disabled completely. But ini-customizable brightness levels and thresholds sound good too. It makes sense to dim the display in low light situations, but I'd like to determine "low light" myself and not let my phone do it (wrongly) for me.