View Single Post
Posts: 28 | Thanked: 46 times | Joined on Apr 2012
#176
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:
Code:
	/* Convert to percentage */
	raw *= 20;

EXIT:
	retval = GINT_TO_POINTER(raw);

	return retval;
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:
Code:
static als_profile_struct display_als_profiles_rx51[] = {
    {       /* Minimum */
        {
            { 24, 32 },
            { 160, 320 },
            { 720, 1200 },
            { 14400, 17600 },
            { -1, -1 },
        }, { 3, 10, 30, 50, 1 }
    }, {    /* Economy */
        {
            { 24, 40 },
            { 100, 200 },
            { 300, 500 },
            { 720, 1200 },
            { -1, -1 },
        }, { 10, 20, 40, 60, 80 }
    }, {    /* Normal */
        {
            { 24, 40 },
            { 100, 200 },
            { 300, 500 },
            { 720, 1200 },
            { -1, -1 },
        }, { 17, 30, 60, 90, 100 }
    }, {    /* Bright */
        {
            { 24, 40 },
            { 50, 70 },
            { 60, 80 },
            { 100, 160 },
            { 200, 300 },
            { -1, -1 },
        }, { 25, 40, 60, 75, 90, 100 }
    }, {    /* Maximum */
        {
            { 32, 64 },
            { 160, 320 },
            { -1, -1 },
/* XXX: Insane request from higher management */
        }, { 100, 100, 100 }
//        }, { 35, 80, 100 }
    }
};
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:
Code:
{    /* Normal */
        {
            { 24, 40 },
            { 100, 200 },
            { 300, 500 },
            { 720, 1200 },
            { -1, -1 },
        }, { 17, 30, 60, 90, 100 }
    }
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.
 

The Following 9 Users Say Thank You to gebeleysis For This Useful Post: