Related
Hi,
this is a topic I want to start in order to help the development of more intelligent brightness control for Galaxy S (probably regional variants of it will benefit as well).
It began with my PM to some of kernel DEVs that I've noticed brownish color instead of black on ONE brightness setting. My idea was to omit that one brightness level.
Overnight, I already got two responses. One that it should be no problem and one that the link I sent might lead to fixing the problem I mentioned as well (color correction).
The other, connected to brightness topic, thing I've noticed is that auto control of it is retarded. First, it's too jumpy without any reason (like let's say change of outside brightness) and second it likes to set level that burn the eyeballs. I've never had such problem on my CM Hero.
Here's my original PM:
embrion said:
Hi,
I'm PMing you as the most popular kernels coders.
Long story short: SAMOLED screens like to make black or similar colors brownish at low brightness. I've (and not only me) noticed that there's a step just about min. when it starts to be brown and a next step after that it magically stops. The idea is to omit this step at all or just in auto brightness table. I believe It's doable by using those methods.
The original story begins here from the first half of #522 post
Like I've wrote there, this problem exists in all kernels and all color temperature variants of them + stock one.
If you're interested, please respond me. If not, also respond as I'd like to know if I can count on anything.
Thanks
Click to expand...
Click to collapse
Some links that might help:
[SOLUTION] Fix for minimum screen brightness! [10/13 - adjustable]
Kernel makers, please add the ability to adjust auto brightness.
[APP] Different auto-brightness
Gizmodo - Why iPhone 4 and Android Brightness Controls Are Effectively Useless
My random thoughts:
One option would be fooling the sensor that it is less bright than it is
Another, more proper I believe, it to modify some brightness tables to leave extreme brightness levels to extreme outside light situations. This one would also help skipping this "brown" brightness level as like I said, it looks to be only one level
Color correction MIGHT fix "brown" problem too, but I'm not sure as COLD and WARM kernel variants didn't changed this brown problem (unless colors are optimized only for some of the levels like I've read at VOODOO site)
CM 6 already has such brightness level options in Settings-> CM Settings - > User interface -> Automatic backlight -> Use custom(just checked on my Hero) so probably lot of code can be reused (as I believe there is CM for Galaxy S)
Kernel DEVs, fell free to hijack this thread. It is to help your cooperation (unless each one of you prefer to solve problems on they own ) Btw. don't be offended if I didn't included you in the DEVs list I've sent my PM. It was late and I PMed only those I've noticed that they kernels I've used. All of you are more than welcomed.
Other, please don't post "I cannot see any brown", and those one that can see it, please stop posting about info after first 5 people do
I'm so happy to read this threat. I had posted questions about display and auto brightness a couple of months ago in the questions section but never received any credible responses.
My problem is that when I turn auto brightness on, not only does my display get exceptionally dark, but it becomes very noticeable that e.g. grey turns more brownish. Comparing my display to yet another Galaxy S confirmed my suspicions that this is not they way the display is supposed operate, i.e. compared to mine the other Galaxy stayed a lot brighter in equal lighting conditions and the grey remained grey (instead of brownish-grey like mine). I compared the grey tones of the numeric buttons in the stock Dialer APP to conclude this.
I suspectED the light sensor might be defective, but I have run the test menu on a couple of Galaxies (*#0589#) and the units always display the same values when put next to mine.
You might see why this is bugging me so much, it seems my galaxy's display is not using less battery even though I get less brightness than the others on auto brightness. Unless I manually bump up the brightness to full the colors on my screen look dull (grey turns Brownish, and over all it looks not as alive) as compared to other units. Simply bumping the brightness up is of course not an option, this drain the battery like crazy.
EDIT: I too have tried the various Kernels, hardcore warm and cold, voodoo w/ color fix sadly all to no avail
EDIT2: @embrion The above all doesn't explain why our phones have this problem, but the far majority of Galaxy S phones doesn't. Of course I cannot statistically back this up, but I have not physically seen any other device that gets brown on autobrightness like ours. Any Ideas?
Do you say your friend's Galaxy S doesn't turn brownish or it does but gives higher brightness than your device in same lighting conditions?
embrion said:
Do you say your friend's Galaxy S doesn't turn brownish or it does but gives higher brightness than your device in same lighting conditions?
Click to expand...
Click to collapse
It does not turn brown and appears much brighter in equal lighting w/ auto brightness ON. I edited my post above, please read again if it was unclear before. Thank you!!
You should check it at manual brightness at level set few steps higher than min. I'd like to separate brownish display problem at one brightness level from inproper light sensor measure
embrion said:
You should check it at manual brightness at level set few steps higher than min. I'd like to separate brownish display problem at one brightness level from inproper light sensor measure
Click to expand...
Click to collapse
Like I said, the light sensor does not give an improper measure, the readings in *#0589# menu are equal across the devices (including mine). The brownish color tones do, to some degree, disappear if the brightness bar is set two ticks to the right of minimum.
(Auto)brightness corrections
Original Auto Brightness level is too high & sluggish.
It 's need to fix like a voodoo Brightness level fix (2.1 only).
schiphol said:
Like I said, the light sensor does not give an improper measure, the readings in *#0589# menu are equal across the devices (including mine). The brownish color tones do, to some degree, disappear if the brightness bar is set two ticks to the right of minimum.
Click to expand...
Click to collapse
Yes, mine too. Second step from min. setting. I'll ask guys at my local forums to get some statistics. If your friend doesn't have such problem at the same color/theme than it must be display fault
embrion said:
Yes, mine too. Second step from min. setting. I'll ask guys at my local forums to get some statistics. If your friend doesn't have such problem at the same color/theme than it must be display fault
Click to expand...
Click to collapse
Which CSC code do you have? I mine was originally XEN (Netherlands). The units I tested that did not have the problem were all DBT (german Sim free). Just asked my brother and he says his phone also gets brownish (also XEN). Have to check product codes later, will update then.
Mine is XEE (Orange, Poland)
Supercurio did some tinkering with those settings:
https://github.com/project-voodoo/l...a2/Kernel/drivers/video/samsung/s3cfb_mdnie.c
I suspect this is the file we need to modify;
Code:
mDNIe_data_type mDNIe_UI[]=
{
#ifdef CONFIG_VOODOO_MDNIE
// Voodoo color: optimized UI mode
// reduce the sharpness filter radius to make it much closer
// to the real fuzzyness introduced by the SAMOLED Pentile pattern
// color saturation boost on everything is also disabled because
// it causes harm on stock settings (exaggerated colors)
0x0084, 0x0040,
0x0090, 0x0000,
0x0094, 0x0FFF,
0x0098, 0x005C,
0x009C, 0x0613,
0x00AC, 0x0000,
0x00B4, 0x0A00,
0x00C0, 0x0400,
0x00C4, 0x7200,
0x00C8, 0x008D,
0x00D0, 0x00C0,
END_SEQ, 0x0000,
Any thoughts and datasheet quotations on this? Because seriously I see just random numbers in this.
Some interesting code begins around line 315, but seriously I'm clueless
Another interesting file:
https://github.com/project-voodoo/l...2/Kernel/drivers/video/samsung/s3cfb_tl2796.c
My screen has brownish/reddish deep grays on brightness settings under 16-17%. However when I set it over 17% and use screen filter app deep grays are NOT brownish/reddish, this means there is definitely something with lower brightness settings.
Xan, check out the link I've posted in the first post. He gives sources that might be helpful
And the problem appears only at 2nd step of brightness (counted from zero brightness)
embrion said:
Xan, check out the link I've posted in the first post. He gives sources that might be helpful
And the problem appears only at 2nd step of brightness (counted from zero brightness)
Click to expand...
Click to collapse
@embrion so did you pm Supercurio? What did he say? It's too bad this color/sharpness fixing will probably be put on a back burner what with Gingerbread and CM7 development. D*RN IT! I tried an app in the market that is more precise than the built-in slider. Try it out Adjbrightness (free). I punched in all values possible between 2-255. The tipping point (where the browness is gone) lies at when you go from 34 to 35. Is this the same for everyone suffering from this problem. Please remove all apps like e.g. 'screen filter' before you try!
For me crucial step is going from
/ # echo 53 > /sys/devices/platform/s3cfb/spi_gpio.3/spi3.0/backlight/s5p_bl/brightness
to 54, however I'm running trasig's voodoo.
While 54 and over looks ok, lower values are... reddish/pinkish.
@schiphol: yes I did but no response. In dark colored Gingerbread era, this problem will be become more and more evident.
@xan: dzieki I'll flash latest Darky as it is based on trasig's voodoo and try your fix.
--edited--
Supercurio just responded me, I'll let you know about results
embrion said:
@schiphol: yes I did but no response. In dark colored Gingerbread era, this problem will be become more and more evident.
@xan: dzieki I'll flash latest Darky as it is based on trasig's voodoo and try your fix.
--edited--
Supercurio just responded me, I'll let you know about results
Click to expand...
Click to collapse
No fix there, just a different behaviour...
Would like to see this in next voodoo, might even write some simple user interface for this.
I have an idea but its not quite clear yet, however if this patch will let most users 'calibrate' their screens.. I think I'll give simple GUI a shot.
@embrion
Could you perhaps upload the screenshots you talked about in R64's thread so I can replicate. Because of different kernels and settings I want to try and establish beyond a doubt that the problem we're having is of the same nature and root cause. Thanks
This wont be visible on screenshots. You need to make a photo, problably with DSLR and know how to do it
I'll try it today and let you know
According to Supercurio, this is Samsung's color profile deviation, not SAMOLED fault itself.
Anything software broken can be software fixed
@schiphol, xan: yes, it won't be noticed at screenshots, I've already compared R64's black notification bar screenshots and my brown ones. Color picker showed a little difference in color (R:24, G:24, B:24 or something VS RGB: 0, 0, 0 - true black). Such difference should'n be visible and is not visible from software screenshot point of view but Samsung color profile makes 24,24,24 brown IN REAL LIFE while 0,0,0 is still black. I repeat, they're both black at screenshots no matter which brightness level is set, but only 0,0,0 black doesn't look like brown when viewed by bare human eye. Samsung profile at this brightness treats 24,24,24 as brown while it should as black.
--edited--
You're right, Xan. It's just another, ( but 1337 ) method of changing the brightness. I thought there's a plaintext table with levels accessible to change by hand
Hi Ok I have kept the brightness at 2 clicks to the right from minimum to stop grey from looking grey-brown all through today. Now my display accounts for 95% of the battery usage, it has never been this high before. The battery is at 25% whilst I only used the display for 44 minutes.
Thats ridiculous battery drainage and should be taken into careful consideration when a fix is developed for this issue. Are you guys having a similar experience??
This is a two part question. What screen brightness do you usually leave your phone at? I leave mine on what seems to be 0 (see next paragraph for explanation) and my screen still always uses around 60-70% of my battery. I don't understand how it can use that much without the backlight on.
Next question - When adjusting the screen brightness and the slider is all the way to the left is that 0? I'm asking because every widget out there when set to 0 is a a few times brighter than when I manually move the slider all the way to the left. Also, after using a widget to toggle to 0 and I check in the display settings, the slider isn't all the way to the left.
So I'm wondering what is true 0? What the widgets set it to or with the slider all the way to the left? Could the slider being all the way to the left actually be hurting my battery life?
No zero on the slider is technically not zero. You can confirm this checking your brightness sysfs file. You have to decompile framework and adjust some numbers. We can take it down to true zero or slightly above which would be much dimmer.
I did this for the atrix. Im surprised it hasnt been done yet for the nexus.
I know it is not actually 0 because if it was I wouldn't be able to see anything on the screen.
Is there anyone that has insight on my questions though?
I dont understand your question. Zero is not true zero unless we mod the framework. So your backlight is not "off". I dont know why youre getting so much drain.
But we should mod this anyway. Use root explorer and go to sys/devices/omapdss/display0/a6e8aa0 and open the brightnesd file. Note that value with your slider at zero and you will see a reading of 30 (0-255). So we can lower that down to maybe 5-10 and zero on the slider will be much dimmer = battery saving.
I have a similar problem. The max brightness is piercing and the min brightness is just a tiny bit too dim.
I have tried used root explorer to change the maximum brightness from 255 to 100 hoping that the slider may be more granular after. For some reason however I cannot update the max brightness file. I have ensured that it is r/w mounted and tried changing the permissions too. It says that the changes have been made and the original backed up. When I reopen the file it hasn't changed.
BTW, my 'brightness' file is at 10 when placed at the minimum brightness.
Try the newest AOKP.
Brightness controls.
I actually have NEVER used auto brightness...even back in my OG days.
And my X days.
Even when custom auto-brightness options were around I ignored them.
I'd simply keep it at around %20 of the default lowest value.
BUT...this is slightly annoying when you step into the sun and can't see anything.
With the newest AOKP you can even set the amount of brightness changes.
I set up four values.
I've mine set up for a pitch black room to lowest.
Average room to my previous 20%ish.
Bright (sunny) to 100/255
SUPER sunny to 240/255.
I didn't notice any added drain today.
But this was my first test.
I think this feature was actually kanged from CM9, but I'm not certain.
So far I have resisted the temptation to get flash happy and I am on stock 4.0.2 but rooted. Do I have any options without changing ROM?
aidanbree said:
I have a similar problem. The max brightness is piercing and the min brightness is just a tiny bit too dim.
I have tried used root explorer to change the maximum brightness from 255 to 100 hoping that the slider may be more granular after. For some reason however I cannot update the max brightness file. I have ensured that it is r/w mounted and tried changing the permissions too. It says that the changes have been made and the original backed up. When I reopen the file it hasn't changed.
BTW, my 'brightness' file is at 10 when placed at the minimum brightness.
Click to expand...
Click to collapse
We cant change that brightness file with root explorer, even mounted, unless we mod the driver first. It will likely just revert right back to its previous value.
However it is possible i bet to edit the driver. Would be a cool project. You could also try to echo your desired value in terminal. ie echo 255 > brightness. But you prob will get the same result as using root explorer.
Maybe ill look at the driver with my limited skills heh. Or the alternative is to mod the framework which is def possible to fix this, and easier. We did exactly this on the atrix. And the sgs2 had it done too.
Edit: i think i found the code for your granular request. Check lines 30 or so.
https://github.com/ogdobber/android...0/include/linux/platform_data/panel-s6e8aa0.h
Still would be easier to do in framework instead.
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a light image, 15 a dark image.
Renate NST said:
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a dark image, 15 a light image.
Click to expand...
Click to collapse
Nice find! I didn't know that was a B/W threshold. But I think you meant "1 gives a light image and 15 a dark image".
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too).
What I actually use for "contrast" adjustment in NoRefreshToggle is a different approach. Using a fixed threshold of 14 (dark image), I've managed to lower the black level (turning it more greyish) to achieve a smaller color range. This way, the dither patterns appear more often. However, my technique to achieve this effect is not so elegant: I overlay the entire screen with a semi-transparent white pane. This has the inconvenient of controlling the pane visibility: whenever A2 mode is turned off (by user or system), I need to hide the pane View.
If I could temporarily avoid the automatic changing of screen modes by the system, this would be much simpler. I've had no success at this issue so far.
marspeople said:
I think you meant "1 gives a light image and 15 a dark image".
Click to expand...
Click to collapse
Yup, good catch. The preceding two sentences were correct. I edited the third.
I have a demo panning grayscales. It's easy to see where the threshold is occurring. Shown below.
Oh! I did see something about the dither modes.
They would certainly be useful for video, less so for text.
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
Click to expand...
Click to collapse
i seems to me that n-r mode would be much more usefull if would could regulate when its on a and when off. Its quite pain running the app again and again. it seems to me that quicker reaction is much better than nicer pictures in average use - pdf reading, browsing, video, managing system...
marspeople said:
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too)
Click to expand...
Click to collapse
I don't think the dithering can be 'tweaked' as such. It's caused by the reduction of 24-bit color images to the 16-bit colorspace of the OS. Dithering is performed by the graphics hardware to prevent obvious colour banding, and there's no OpenGL functions to control dithering parameters.
The A2 mode seems to choose a threshold value for black in the 16-bit colorspace. Values above this are white. In order to obtain black and white dithering we have to pick values in the 24-bit colorspace which all lie in the same 16-bit band.
The easiest way I've found is to keep the R and G values at 255 and vary the B value. I think the default threshold lies at 255,255,198. If you start at that and increase the B value you get 7 dithered grey shades before you reach white.
Guys, as far as i know, eink display is build of tiny capsules, much smaller that one pixel is, and a chip is joining them into pixels. So mayby there is a way to divide single pixel into 2 or even 4? It is much much work, but it would make us easier draw some tones of monochrome? Example: to get dark gray, instead of displaying one of five black pixels white, we can make one's "subpixels" 3/4 black, 1/4 white.
Does it make sense/do you get it?
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
Click to expand...
Click to collapse
I agree with you. But having temporary exclusive control of A2 mode would make my application more efficient. I don't intend to use A2 system-wide.
Renate NST said:
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Click to expand...
Click to collapse
I just tried this but I've got nothing more than a simply darker and checkered image. I don't understand how it would be better.
marspeople said:
I don't understand how it would be better.
Click to expand...
Click to collapse
Well, halftone screens have been around forever.
Think of it this way, it would give you two different thresholds.
With a bigger pattern you would get more thresholds but a coarser pattern.
That is always the way with dithering or halftone.
Probably a screen would not work well with an underlying dither.
A useful observation from http://forum.xda-developers.com/showthread.php?t=1502723&page=11 is that by listening to the screen you can hear screen activity.
After a quick test I suspect ONESHOT mode allows the screen to enter a power saving mode (in which the screen is completely silent) after a few hundred ms of inactivity, while ACTIVE prevents it. No idea whether there are other issues involved.
The native Reader.apk uses GU, ONESHOT_ALL when turning pages.
Every 6th page it uses GC, ONESHOT_ALL.
In an overnight test with the nook screensaver / lock screen mode inhibited by my application and no screen updates, I obtained power consumption of 0.75% / hour with ONESHOT mode. In a previous test with ACTIVE mode I got ~7% / hour with the same scenario(!)
With fast screen updates of ~ 1Hz ONESHOT does not appear to give any power saving benefit over ACTIVE mode, and a quiet hiss can be heard from the screen at all times in both modes at this refresh rate. I think this indicates the ONESHOT mode allows the screen to enter a power saving mode after a period of inactivity.
Neither of these were scientific tests but I strongly suggest trying ONESHOT mode in favour of ACTIVE whenever using A2 mode.
Well, there must be some benefit sometime to the ACTIVE mode or they wouldn't have it.
It's hard to differentiate the different modes, but it seem that ACTIVE responds quicker with less delay.
I switch to ACTIVE_ALL, A2 for panning and switch back to ONESHOT_ALL, AUTO afterwards.
(I don't use full-time A2).
See my demo of panning: http://forum.xda-developers.com/showthread.php?t=1563645
I'm running about 7%/hour drain. My Nook is not suspending when I do a simple power button click. I don't know why.
A few folks seem to be using EpdController in a useful manner.
Their use of Java reflection is clever, but it's not supposed to be that difficult.
I wrote a Java stub (basically declarations) for EpdController and wrapped it in a jar.
If you just put this jar in your compilation classpath with your normal android.jar
then you will be able to use the EpdController without all the fuss and muss.
For example, in my latest (unreleased) version of UsbMode I want the blinker to go on and off cleanly:
Code:
EpdController.setRegion("UsbMode", EpdController.Region.APP_3, blinker, EpdController.Wave.DU);
That's it, one line, no initialization.
The EpdController class was designed to handle such trivial uses.
Note: This jar itself has no functionality, all the method bodies are {}.
You will have to import android.hardware.EpdController
The 1.2 update uses a different EpdController and has a new EpdRegionParams.
This may or may not break code written for previous versions.
The best way to write code to use EpdController is to have it detect if there is no Epd
(i.e. for other devices), the old version or the new version.
Wrap a try/catch around a Class.forName("android.hardware.EpdController").
Wrap a try/catch around a Class.forName("android.hardware.EpdRegionParams").
The new epd.jar in the signature will allow you to compile without using redirection both the old and the new.
For details on the changes, see: http://forum.xda-developers.com/showpost.php?p=35390192&postcount=8
Bump & additional info.
By experimenting and reading documentation for other eInk controllers I've figured out the following:
Controllers support different algorithms for updating the pixels depending on the precision of the gray scale required and the compensation for previous ghosting.
On the Nook, we have the choice of waveform modes:
GC
GU (gray update)
DU (direct update)
A2
GL16
AUTO (auto selection of algorithm)
The screen can be divided up into regions where different algorithms may be used.
Some controllers support 15 regions, ours supports 8.
4 of these regions are earmarked for system usage, specifically:
Toast (popups)
Keyboard (soft keyboard layout)
Dialog (popups)
Overlay
The remaining 4 regions are left for the user.
Note: "HwRegion" is an enum for the complete 8 regions, "Region" is an enum for the 4 user regions.
An example: In my audio recorder I have two regions set aside for the VU bar graphs.
By setting these two regions to DU I get rid of update clutter and the response is quicker.
Currently, the EpdController in the Nook only operates with portrait coordinates.
If you wish to use this while in landscape mode you will have to rotate the coordinates first yourself.
It's sometimes hard to see exactly what/if some EPD setting is doing.
A good way to check it is to set a region for one half the width of whatever active graphic element you are trying to improve.
The difference can be very clear.
Renate NST said:
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Click to expand...
Click to collapse
Excellent work! Do you happen to understand/can write up what the various fast mode/no refresh hacks do/how they use these different modes?
I've had X 'running' on my nook but only by triggering a full refresh every few seconds, and wondered how I could be more selective.
My reading of Norefresh was that it was doing something like parsing android log structures for areas that have changed.
Is there an easy way to trigger a refresh of part of the display from userspace, preferably directly on the driver or fb?
As for where the dithering is done, my guesswork is this is done by a blob running on the DSP module within the OMAP (which is perhaps the only interesting use of it I've seen).
Dave
Just done some playing writing directly to the entires in /sys/class/graphics/fb0 ; so for example:
echo -n 100,100,200,200,0,14 > epd_area
echo 2 > epd_refresh
causes the square 100,100->200,200 to be refreshed
the 14 being REGION(8)+CLEAR(4)+ONESHOT(2)
the 0 is wvfid+threshold*65536 I think.
I've put some code that runs under X to trigger updates; here (actually the comment is wrong, it's currently using oneshot+clear);
I never managed to get active to work.
http://forum.xda-developers.com/showthread.php?p=42393733#post42393733
Dave
Hi Guys,
Not sure if this is covered anywhere or if it's even an issue or maybe Percieved issue.
Between Flashing Cooked ROM's and Stock ROM's etc it always seems that the display while using stock ROM's doesn't seem as bright / vibrant - it always seems a bit duller at max Brightness, the Whites dont 'Pop' off the screen as much.
Is there any truth to this or is it just me? If it is the case what are the Chef's doing to make this so and can i do it to a Stock ROM?
Cheers
Paul
it can depend on 2 things
- kernel used -> some kernels disable or can disable "adaptive brightness" and modify color values
- the value set for auto-brightness in framework-res.apk. Most devs keep the standard values from google, I usually find them "too boring and dark" so i modify them.
So not your perception - you are quite correct
Thyrus said:
it can depend on 2 things
- kernel used -> some kernels disable or can disable "adaptive brightness" and modify color values
- the value set for auto-brightness in framework-res.apk. Most devs keep the standard values from google, I usually find them "too boring and dark" so i modify them.
So not your perception - you are quite correct
Click to expand...
Click to collapse
Ah thanks for the response. Though if i understand correctly this just affects the 'level' at which the brightness will be set at certain detected light levels on the Auto Brightness settings?
What i mean is that if i just go in and turn off Auto Brightness and slide it up to the Max - the Cooked ROM's always seem more vibrant and brighter.
Also is there anything that i'd be able to do to a Stock (rooted) ROM to get this extra Brightness?
Cheers
Paul
Thyrus said:
it can depend on 2 things
- kernel used -> some kernels disable or can disable "adaptive brightness" and modify color values
- the value set for auto-brightness in framework-res.apk. Most devs keep the standard values from google, I usually find them "too boring and dark" so i modify them.
So not your perception - you are quite correct
Click to expand...
Click to collapse
More details on this please?
Edit: nevermind, found it.
Mind Sharing Your findings MS? Or could someone else please help?
Cheers
Paul
Here's something about content adaptive brightness:
http://forum.xda-developers.com/showthread.php?p=28126141
You can turn it off with Franco's kernel app or with Supercurio's Voodoo display app, available in his thread here on xda.
paulrgod said:
Mind Sharing Your findings MS? Or could someone else please help?
Click to expand...
Click to collapse
Here it is. I had no chance yet to try it, but i believe it should work.
Thanks guys - went for Francos Kernel and can now adjust the levels with the tool
Hello Everyone,
I have a problem with my amami and I doubt I am the only one but for some reason people do hardly complain: the brightness even at lowest possible setting is still too bright.
I had this back when I had original FW and I am having the same issue with CM11 (latest nightlies). Using manual control or auto-brightness doesn't make much difference, i.e. in a totally dark room the ambient light sensor reports 0Lux and the screen is still too bright.
I found a workaround already (the ScreenFilter app that people recommend all over the internet) but it sucks because it heavily reduces the picture quality, i.e. visibly reduces contrast and especially the gray color resolution. And it also doesn't reduce power consumption like real brightness value change would do.
I looked around for possible solutions and there is a trick with writting a new value of current limit to Linux settings (some mA value between 0 and 20 to some max_current file in procfs). And this really helps but also impacts the maximum brightness, the screen is hardly ready in sun light with reduced current.
Is there a silver bullet? I am thinking about writing an app for that but it would require SU permissions and is kinda dirty to implement. Can anyone recommend a better solution?
have you tried the xposed Modul "minimum brightness" ?
Install Lux Brightness. from play store.
You can overboost it or make the screen so dark that you can't even see it.
Another great screen mod is Twilight which basically dims the screen red based on clock so it helps fall sleep faster when using phone before bed.
New Folder said:
Install Lux Brightness. from play store.
Click to expand...
Click to collapse
Yes, another vote for Lux. It lets you set brightness to negative levels, mine is usually around -50%. https://play.google.com/store/apps/details?id=com.vito.lux&hl=en
Vote for Lux here too.
Nothing comes close
camaro322hp said:
Yes, another vote for Lux. It lets you set brightness to negative levels, mine is usually around -50%. https://play.google.com/store/apps/details?id=com.vito.lux&hl=en
Click to expand...
Click to collapse
Thanks for the hint. I tried the Lite version and AFAICS it simply uses the same trick as ScreenFilter and other "sub-zero" regulators, putting an alpha overlay on top of the image stack.
You can identify this kludge easily by looking at the button areas, they don't get darker anymore. And you can see the black level not getting real black, i.e. the power consumption is not reduced.
However, Lux seems to be one of the better toys because of the plugin interface. Unfortunately there is no HW plugin for Sony devices but judging by the quick look at the Nexus-4 plugin (it's open source!!) it should be possible to adopt this method to Z1 as well. So, maybe when someone could eventually implement that.
xposed Modul "minimum brightness" works, i tested it for you. you can make the screen dim to complete black with your normal display brightness slider without grey or black overlay. it just sets down the minimum brightness level to 1 or 0 (default is 10 or 20), so it should also work with enabled auto brightness
chertVdetali said:
I looked around for possible solutions and there is a trick with writting a new value of current limit to Linux settings (some mA value between 0 and 20 to some max_current file in procfs). And this really helps but also impacts the maximum brightness, the screen is hardly ready in sun light with reduced current.
Click to expand...
Click to collapse
As far as i remember, /proc is only used to call upon information, not to set specific values. What you are looking for is placed within /sys.
To be precise in /sys/devices/leds-qpnp-ee125e00/leds/wled:backlight/. There you will find a file called max_current with which you can easily control the brightness and set it to a very low level. Note that this actually dims the screen and not just applies a filter like most apps do...
One drawback is that the value will change again after you restarted the device. I set up a little flow with Automate β that takes care of this for me. I find this solution a lot better than all the screen filter apps.
This is true for CyanogenMod 11 and GreatDevs Kernel. It might be different on Stock. I know that the path for my Nexus 7 is sys/class/leds/lcd-backlight.
I hope this helps you a little bit.
rob rich said:
xposed Modul "minimum brightness" works, i tested it for you. you can make the screen dim to complete black with your normal display brightness slider without grey or black overlay. it just sets down the minimum brightness level to 1 or 0 (default is 10 or 20), so it should also work with enabled auto brightness
Click to expand...
Click to collapse
I am wondering how you can claim that the result is complete black. Calling this black is like saying "TN monitors have good black values" (I know such people, they change their mind quickly when they see my Eizo with a VA panel at night).
No, seriously, the default was already 10 (see config.xml in cm11 repo) and the difference between 1 and 10 is hardly visible. It's still way too bright for work without eye strain in the darkness.
@Wooaarr: thanks, this is apparently the way to go, I just need to find time to configure it. And yes, of course, the file is in sysfs and not procfs (automated typing, when I grew up with Linux there was no sysfs out there ).
chertVdetali said:
I am wondering how you can claim that the result is complete black. Calling this black is like saying "TN monitors have good black values" (I know such people, they change their mind quickly when they see my Eizo with a VA panel at night).
No, seriously, the default was already 10 (see config.xml in cm11 repo) and the difference between 1 and 10 is hardly visible. It's still way too bright for work without eye strain in the darkness.
@Wooaarr: thanks, this is apparently the way to go, I just need to find time to configure it. And yes, of course, the file is in sysfs and not procfs (automated typing, when I grew up with Linux there was no sysfs out there ).
Click to expand...
Click to collapse
when i disable autobrightness and push the slider to the left my screen goes completely off, so you wanna say that screen off isnt black? funny
chertVdetali said:
Thanks for the hint. I tried the Lite version and AFAICS it simply uses the same trick as ScreenFilter and other "sub-zero" regulators, putting an alpha overlay on top of the image stack.
You can identify this kludge easily by looking at the button areas, they don't get darker anymore. And you can see the black level not getting real black, i.e. the power consumption is not reduced.
However, Lux seems to be one of the better toys because of the plugin interface. Unfortunately there is no HW plugin for Sony devices but judging by the quick look at the Nexus-4 plugin (it's open source!!) it should be possible to adopt this method to Z1 as well. So, maybe when someone could eventually implement that.
Click to expand...
Click to collapse
Interesting information, I did not know that. You are correct, the navigation buttons are brighter than the rest of the screen at negative values. I had noticed that before but didn't know why. Works well enough for me though.
rob rich said:
when i disable autobrightness and push the slider to the left my screen goes completely off, so you wanna say that screen off isnt black? funny
Click to expand...
Click to collapse
Well, you claim that it works for me because you tested it on your device. So... yeah, why not, I could say what you mentioned above just following the same logics. :silly: