yashsingh1/xdaforums huggingface dataset:
[Desire Android Development] tobi01001:
Well, I've never seen the values in up and down. I set them different by purpose. But at least for me, it turns out they are never set.

Short answer: maybe, but with little use.

Well, at the moment it is possible to adjust the table in the bravo board file. Those represent somehow the raw values and are then set as light levels.

I do not know how to change the 10 to a 20. But that would make not that much sense since the driver will set the same levels. Android (the sensor manager) would only see a 20 instead of a 10 - but the environmental light conditions didn't change.

However, it would be possible to increase the value, which represents level 0 - so the span for level 0 would be a bit wider. Actually, I already proposed this with using 4 instead of 1...

Further:

I just found, that if you turn on the screen in absolutely brightness then the screen brighness is still set to the value of level 1 (40 in my framework). In this case it does somehow not go down to the value of level 0. There is a change to a brighter value needed first.

I will investigate a bit more and play with different settings as soon as I have time to do so.
[Desire Android Development] tobi01001:
In my bedrom is totally darkness... at least when I intend to sleep. So level 0. With common indoor light it is usually level 1 to 3. Level 4 to 5 in some cloudy sky and or in the shadow. The upper levels need more or less sunlight.

Do you have a case or something covering the lightsensor maybe?
[Desire Android Development] tobi01001:
So you are using 9 values (stock ones of course) in

<integer-array name="config_autoBrightnessLevels">

as well.

Could you maybe confirm that you see Level 0 and the corresponding screen brightness (33 in your case)... If so, I may have been totally wrong in my assumptions about the framework. :D

I do not understand the slight differences in the up/down lists and my personal feeling is that those have no impact on what you actually see. :-)

I have them set totally different and as already mentioned, I never saw the screen brightness set to any of them.

this is how I set my values in the framework, but thats personal feeling anyway:

<integer-array name="config_autoBrightnessLevels">
<item>21</item>
<item>41</item>
<item>91</item>
<item>161</item>
<item>226</item>
<item>321</item>
<item>641</item>
<item>1281</item>
<item>2601</item>
<item>10241</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>21</item>
<item>40</item>
<item>50</item>
<item>70</item>
<item>80</item>
<item>90</item>
<item>120</item>
<item>160</item>
<item>200</item>
<item>255</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValuesUp">
<item>21</item>
<item>28</item>
<item>45</item>
<item>60</item>
<item>75</item>
<item>85</item>
<item>105</item>
<item>140</item>
<item>180</item>
<item>228</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValuesDown">
<item>28</item>
<item>45</item>
<item>60</item>
<item>75</item>
<item>85</item>
<item>105</item>
<item>140</item>
<item>180</item>
<item>228</item>
<item>255</item>
</integer-array>
[Desire Android Development] t-minik:
I'm pretty sure it works perfectly on 10 levels without adding any level in framework.

values, valuesip and valuesdown are very close and it should work perfectly.

for me, values, valuesip and valuesdown are the same and it's perfect on BravoS V7 ;)
[Desire Android Development] ivicask:
I just puted thos 1 point differences to test if it will ever switch to those values, but it allways just switches to ValuesUP.

And btw just realized, not every time it switches to value 0.Out of 10 phone unlock in total dark it goes 0 6 times and 1 4 times ..strange..gona do some more testing of my own..but i think i know whats wrong.
[Desire Android Development] t-minik:
when i say change 10 to 20 for level 0 it seems sensor need more light to go to level 1, just the 1rst level is less sensitive.
[Desire Android Development] NeoEpsilon:
Well...

Only a clear screenguard...

Should not pose any problem... :D

BTW...

I just realized that no one is posting if they got an AMOLED or SLCD Desire... :D

It should be different right..? :D

My Desire need around 60-70 brightness to achieve a good color and readability in a normal room...
[Desire Android Development] ivicask:
Okay, im going crazzy..

As you see i got min and max values and it works (i cover sensor it goes 30, i put it under lamp goes max)

D/lights ( 1739): set_light_buttons_func: on=1973790 brightness=30
D/lights ( 1739): set_light_buttons_func: on=16777215 brightness=255

The problem is when i turn on phone in tottal darkness sometimes it goes to lowest value, and sometimes to next one, just randomly without reason.

Is this maybe a kernel prob ? Or we still dont understand something about framework..
[Desire Android Development] tobi01001:
Thats what I experience as well. And actually that is the effect which made me do the framework changes in the OP. Now they may turn out completely wrong and useless (but luckily without negative side effect). I allready changed the first post.

When turning on the phone with power or trackball I get either the value for level 0 (very seldom), level 1 (most of the time) or level 9 (many times but mostly if I turn off and on very quick).

This is crazy since it makes level 0 rather useless again. Reason for me to have it was not being blinded at night when just looking at the phone... :D

I have to check my (just created) logs. I already have a solution in mind... but first I have to be sure about the problem.
[Desire Android Development] tobi01001:
Okay, I dived a little bit deeper into details and I think I know why the phones behaves like it does.

I will change the OP with the solution if it is tested.

Now for the problem:

When the screen is being turned off, the phone usually goes to sleep. This will send the light sensor to sleep as well. I think the SPI to the sensor stays enabled but ins't served by the sensor anymore.

The state of the lightsensor (being enabled or not) can be checked here:

cat /sys/devices/i2c-0/0-0066/ls_auto

When the lightsensor is asleep, the values the driver gets from the SPI are (totally) random and the reported levels use the full range from 0 to 9.

If someone needs a hardware supported random number generator, this may be a place to look. LOL

The problem is, when you turn on the phone and the screen respectively, the screen will be turned on immediately (users would complain otherwise :p ) but there are no light sensor values to work with. So android must somehow work with the wrong values. the lightsensor is then warmed up and provides correct values for the light condistions. At this time the sensor is still being reported as "disabled". So when the light sensor is finally reported as "enabled", the values and the level are already settled.

For a brightness change there is (in my opinion) a level change needed (as trigger / event). If sensor values are somehow settled, there is no trigger and the screen will stay on the wrong brightness unless the level change.

One remark: It does not change when going from level 1 to 0. I think there may be no trigger for that change.

So one possible solution would be to prevent the light sensor from going to sleep. That would be a bad idea in terms of battery life.

So my solution would be the following:

Before we go to report the adc_values (lightsensor data) and report the corresponding level, we check first if the sensor is actually enabled. If the sensor is currently disabled we report adc_value 0x00 and level 0 as default.

The change needed in the driver would be:

Only the marked if condition has to be added. (I din't know if that will work but I am quite confident.)

static int get_ls_adc_level(uint8_t *data)
{
struct microp_ls_info *li = ls_info;

...
...

adc_value = data[0]<<8 | data[1];

[B][I]if(li->als_intr_enabled == 0)
adc_value = 0x0;[/I][/B]

if (adc_value > 0x3FF) {
printk(KERN_WARNING "%s: get wrong value: 0x%X\n",
__func__, adc_value);
return -1;
} else {
if (!li->als_calibrating) {
adc_value = adc_value * li->als_gadc / li->als_kadc;
if (adc_value > 0x3FF)
adc_value = 0x3FF;
data[0] = adc_value >> 8;
data[1] = adc_value & 0xFF;
}
...
...
...

The if statement could be placed on many other places in the code. I put it there by reason in order to not change how and/or if values are reportet but just what is being reported when the sensor is off.

I will see if someone provides me a test kernel and report back.
[Desire Android Development] PeQuEsan:
Looking forward to seeing your test results. If you need third party tests, please don't hesitate to contact me.

Thanks for all.
[Desire Android Development] ivicask:
I managed to fully fix autobrightness bug by moding Services.jar, i have ported all PowerManagerService smali's from HTC Sensations services to desire, now autobrighntess works perfectly (no more 0-1 jumping on unlocking phone)
[Desire Android Development] anderl78:
Very interesting! Could you please upload your modded services.jar? Would be great to take a look inside!
[Desire Android Development] ivicask:
View attachment services.jar

Taken from AceSMod007 (Sense2.1+3 rom.

But there are 2 bugs:

1:CRT Animations are forced ON, cant turn them off via Screen options like before

2:Battery usage shows high screen usage, but theres no higher batter drain at all(just visual)
[Desire Android Development] PeQuEsan:
Should this services.jar fix the problem that darker brigthness value inside arrays.xml is actually not being applied (although you can see the change in catlog when entering a dark room)?
[Desire Android Development] ivicask:
I didint even notice this kinda off problem, but i tell you it works preety well and smooth..just try it, or if your on another rom give me your services ill mode them for you so you can try.
[Desire Android Development] PeQuEsan:
I'm on AceSMod007, so I'm good with your services.jar.

Tobi described a very similar problem in one of his posts.

Thanks a lot.
[Desire Android Development] ivicask:
I just tryed.

1.Unlocking phone in total darkness 10 times =Brightness 0

2.Unlocking phone under sunlight = Brightness MAX

3.Unlocking phone under sunlight than moving inside than comming to the room with total darkness =Phone goes from max than slowly falling down as i move in less light, than when i enter total darkness it goes to 0.

Its switching values in steps of i think 27..so if you go from MAX brightness to total dark, it takes 5 sec for him to slowly dim it (its very smooth and cool)

What ever i do it works as i expected, can you give me any other scenario which i can test? :)

Edit:

And this are my values and i can get any of them depending on light comming to sensor

<item>35</item>
<item>51</item>
<item>74</item>
<item>97</item>
<item>120</item>
<item>143</item>
<item>166</item>
<item>199</item>
<item>222</item>
<item>255</item>

This are results after moving phone closer to light (sun), as you see i managed to get all levels except one (166), but its hard to adjust it, im sure it works!

C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
35
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
51
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
74
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
97
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
120
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
143
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
199
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
221
C:\Users\Ivica>adb shell cat /sys/class/leds/lcd-backlight/brightness
255
[Desire Android Development] PeQuEsan:
Cool!!! :)

I've just flashed your services.jar. Transitions are smooth and very very cool now! :), and those bugs you "introduce" doesn't bother anyway.

Another side effect is that catlog brightness messages are not consistent... I just open "catlog" and filter by "bright"... Before, I had a message each time I changed ambient light... Now I hardly can see this messages, and always are followed by another one notifying a change to max (255).

BTW, I "think" now I can't see the bug I told you before... Now I can see my lowest value (which in fact is minimum brightness, 30).

I'll post back in case of any other issue or comment.

Thanks. :)
[Desire Android Development] PeQuEsan:
I can confirm that with your services.jar, I can go down to 30, which is my lowest brightness level inside arrays.xml. I repeat the issue: before, system went down to 30 regarding the log... but I couldn't see an actual brightness decrease in my screen... Now, I can see it... :)

So, so far so good!!! :)
[Desire Android Development] tobi01001:
Thanks... Will have a look soon. Saved a lot of time since I may not have to jump into services.jar myself... Actually, I was not quite sure on where to find it exactly and had limited time the last days...

I will report back...
[Desire Android Development] tobi01001:
Thank you very much.

I flashed this services.jar onto LeeDrOiD 3.3.3-R5 and it is working just great.

Only thing: If you turn the screen off and on very quick, brightness gos to max. at least for me. but it will afterwards smoothly go down to the desired level.

Further, I updated the first post accordingly and added besides other things the following:

Update: Information for Brightness / Gamma settings for Amoled (not SLCD) devices

- max brightness value is 250

- min value is 10 but anything <31 will be set to 20

- gamma steps are 30 and there are actually 9 levels. But that doesn't matter. any value between 30 an 250 should be (more or less).

So if you take those "restrictions" into account while changing your framework, it could add a bit of smoothness (yet not sure about it).
[Desire Android Development] ivicask:
Yea, if you unlock it very quickly few times in a row it jumps to max...but who does that anyways?:) But im using moded services for 3 days and its working 100% perfect for now, newer jumped to max on unlock or so...

Btw Tobi have you tryed buttons backlight tweaking now with moded services?If still doesnt work, its definetly kernel bug...
[Desire Android Development] tobi01001:
Didn't look into key backlights yet and atm I don't know what I have in the framework. I'll have a look...

/EDIT: button backlight is working as well.. So I will adjust the framework to have them only illuminated at level 0.

/Edit2:

found something for the maxbrightness issue (if you quickly lock and unlock): unfortunately, this is within one of androids libraries. Should be possible to change them somehow if it's not some HTC-brewed stuff...

https://github.com/CyanogenMod/andr...mmit/db0fd83aa961bbd3c5e6db98d4f58fc847e56e64

But actually I don't know if it's worth the hassle... may have a look tonight.
[Desire Android Development] backfromthestorm:
Would anybody have a modded framework_res.for the official gingerbread (3.14.405)?

Or be able to make one? I don't have a pc at the moment, so kinda screwed.

Would be much appreciated.

http://db.tt/472a9HDE

Edit- sorted now, all credit to Droidzone. Thanks.
[Desire Android Development] siskiou:
Hi,

I came across this thread when searching for sensor data problems with my droid incredible 2.

Unfortunately, I'm not very savvy when it comes to the intricacies of programming.

Is the services.jar file that I could use for my phone, running a sense 3.5 rom?

I discovered that my sensor doesn't detect any lux lower than 160, even when in a completely dark room, and I'm not sure if this is fixable, or if I should get a replacement phone.
[Desire Android Development] tobi01001:
Well, it really depends. First of all, you should get a bit more details.

Providing no less than 160 can have many causes.

Could be the sensor, the driver, the services or even a combination.

If your problem does not affect other people, than its likely that you may need a replacement... But I'm not sure to say.

Best option is to read the sensor directly from /sys/... if you're driver is providing that information.

Here you can check what adc values and levels are provided. What the services are doing with it is just another story....
[Desire Android Development] siskiou:
Vielen Dank! Ich sehe, dass du eine deutsche Flagge hast. Ich komme aus Duesseldorf, wohne aber seit 1989 in den USA

(Translation: Thanks! I see you have a german flag up. I'm from Duesseldorf, but have been living in the US since 1989).

Would you be able to tell me what type of file I'd be looking for and where in /sys/ it might be located?

I did a search for "sensor" in Astro and found the following:

/dev/lightsensor (no file extension, can't open with anything on my phone)

/system/libservicesensorservice.so

/system/lib/hw/sensors.viwow.so (can't open these either)

After further digging, I also found a couple of folders under /sys/bus/platform/drivers:

lightsensor_microp and lightsensor_smd

Both contain the following files: bind, uevent, unbind.

Can't view any of them with what's on my phone.
[Desire Android Development] tobi01001:
Well, on the desire you can read raw sensor data at "/sys/devices/i2c-0/0-0066/ls_adc". Shouldn't be that different on the incredible if hardware is similar. So you may look under i2c devices.

It's probably good to look/log with a console. Something like adb shell cat /sys/devices/i2c-0/0-0066/ls_adc should do the trick from the PC. Without adb from a terminal on the phone itself.

It should - depending on the driver - give you raw values and the level belonging to that value.

It is actually readable like a text file. Might work with astro as well. Not sure about that.

Yes, I'm from Germany... Currently thinking about moving to the US. But not that long.... ;-)
[Desire Android Development] siskiou:
Well, I hadn't planned on staying, when I spent a vacation here. *g*

And it seems the devices are different enough (or my knowledge insufficient) that I get stuck at i2c-0. I can't find any files with a name that makes me think it's related to the light sensor. Nothing with ls or similar in it at all, and an Astro search finds nothing.

I went though all the i2c devices entries and all have files like this:

modalias, name, uevent, and then the subfolders power and subsystem.

I can open them as text files, but haven't found anything that seems related to the light sensor.

Thanks for your help!

Edited to add: I think I'm way over my head with this, since I can't even figure out where to find the driver on my phone.

How would I replace the services.jar with the one provided here, just in case it works, and if it doesn't, will I be able to go back to a nandroid?

I assume it's not as simple as unzipping the rom, replacing the services.jar, and zipping it again.

Figured out how to push the file, but phone got stuck at HTC screen. Restored to a nandroid and am no wiser. ;)

I may just have to live with a malfunctioning sensor, since I don't really want to buy another sim unlock code.
[Desire Android Development] littlej:
hey i am ussing insertcoin 1.0.8 in my opinion this is the best stable and best powersaving rom, but it lacks this patch to enable all light sensors levels, can anyone help me making it for insert 1.0.8 ? i am not that good with moding files :(

thanks
[Desire Android Development] erklat:
I'll make it for you. All you have to do is extract framework-res.apk from the zip and share it here?
[Desire Android Development] littlej:
Hey i extracted the zip, here it is! thanks.
[Desire Android Development] Droidzone:
Mine? You get all locales, and India as default for free.. :D
[Desire Android Development] erklat:
OK, I'll see to it asap.

SwiftKeyed from my HTC Desire using XDA App.
[Desire Android Development] siskiou:
I'm back again, after looking at the source codes HTC made available recently.

I *think* this might be the relevant part for my phone (Droid Incredible 2).

Can I make changes in there that will let me get the lower levels? I notice several

0x0s. Is this why I get nothing lower than 160 lux?

I'm a total noob at this, and really have no clue, but am determined, and able to follow instructions, if there is anyone here who would help me.

Or is it simply that this sensor *can't* read these missing levels?

________________________________________________________________

static struct lightsensor_smd_platform_data lightsensor_data = {

.levels = { 0x0, 0x0, 0x0, 0x3A3, 0x97B, 0x1873, 0x2B21, 0x3CC8,

0x4E70, 0xFFFF },

.golden_adc = 0x1D98,

.ls_power = capella_cm3602_power,

};

static struct platform_device lightsensor_pdev = {

.name = "lightsensor_smd",

.id = -1,

.dev = {

.platform_data = &lightsensor_data

}

_________________________________________________________
[Desire Android Development] tobi01001:
Yes, looks like this is part of the reason. Just take a look at the array with the sensor levels:

There are 10 in total (which actually seems to be a android thing). Every single value (or more precise entry) represents one level within android. The values are the thresholds to switch to the next level depending on the raw sensor values. All this happens in the driver. If the driver is implemented like the desire driver then zeros are just ignored. This seems to be the case here as well.

So one could adjust the values to start with 0x1 and adjust the inbetweens accordingly.

You need one to compile the kernel for you.

Further, it may depend on more than just the kernel. But it's a good point to start and might quite sure enable all lightsensor levels.
[Desire Android Development] backfromthestorm:
oh ok, I just stole the framework off your light sensor zip. Comes up as English still as i don't wipe data. Just as well, I don't speak anything else.
[Desire Android Development] siskiou:
Thanks a lot!

I am very slowly learning a little about kernels, but have nobody to help me out and no knowledge of linux.

I'll be sure to make nandroids, to have something to go back to if I screw up anything, which is very likely! *g*

I noticed that you changed the 0xsomething to regular numbers, except the last value. Is this something I could try?

And I managed to take a look at the Framework-res.apk of the rom I use, but there is nothing like framework-res.apk\res\values\arrays.xml.

Not sure where the equivalent would be.

I apologize for all the newbie questions, but I really don't know where to go for help with this.

Thanks so much for not just ignoring what must sound like inane questions!
[Desire Android Development] tobi01001:
To determine the values it would be best to read the raw values.

But in your case, draw a curve with the values already in the array. Then interpolate the others down to 0x1...

For your framework: did you just extract it like a zip or did you decompile it using apktool? You may have to use the latter...

There is a link in the first post to a guide on changing the framework values...
[Desire Android Development] siskiou:
I've read so many tutorials that I don't even remember how I opend it! I think I unzipped and used your tutorial that you linked to in this thread.

I will try again with apk tool, once I have a few hours of time.

I'm not sure I can read the raw values on this phone.

I have adb working, but don't really know how to get to this file on my phone: arch/arm/mach-msm/board-vivow.c

I found it in the HTC source code that they published a few days ago, but now I'm stuck. Will study more and hope to find enlightenment some day! :)

Can you change things in the source code and then compile a kernel from that?

Would it be okay to pm with further questions, to not clutter up the thread?
[Desire Android Development] tobi01001:
Sorry, I may not be able to compile a kernel for you... Well at least this kernel wouldn't work...

Couldn't you just ask a kernel developer in the incredible forum?
[Desire Android Development] siskiou:
Oh, no, while l would love for someone to take this on, I wasn't meaning for you to do this. And it seems nobody else with the Dinc2 is worried about the autobrightness levels. I was just hoping for some hints how to at least add those missing levels.

I'll keep researching...