Related
TorchButton v2.x supports the Leo as well as Raphael and moved to a new thread! Click this link!
On my previous devices (Wizard, Hermes) I found it very useful to have the camera LED function as flashlight. However, all those tools that were previously available to enable the LED didn't seem to work on the Raphael.
I've just spent some time debugging and testing and got it to work on my Raphael. The cab to install is attached to this post. It'll create a shortcut in your programs menu.
Usage is currently twofold. When you start the app, the flashlight turns on. When you don't do anything for 60 secs it will turn off automatically to prevent your led from burning (heard it happen before on other devices). If you start the program again within the 60 seconds, it will manually turn the flashlight off.
I've only tested this on my Raphael so far. Please let me know if it works for everyone.
---------------
Supported modes:
TorchButton has 5 modes so far. Each one explained in short:
Normal
Simply enable the flashlight until the application is started again or the configurable timeout occurs (60 seconds by default). This mode can be used for a prolonged period. I have only tested it up to 5 minutes though.
Bright
The Bright mode is exactly the same as the Normal mode, with the only difference being that the LED is more bright. This mode is equal to the short moment when you make a photo with flashlight on. Note that this mode does stress the LED and should not be used for prolonged periods. I have used this up to a minute without problems.
Blink
The Blink mode turns the LED on and off in specific intervals that you can configure in the registry. An example of usage is the bike light.
SOS
This is extensive mode that supports sending custom morse code. The text to be sent via morse code signals can be configured in the registry. This defaults to "sos ", thus the SOS name for this mode. NOTE that the flashlight timeout does NOT interrupt a text. It checks if the timeout occurred when it starts over again and quits when it reached the timeout.
PTT
The Push-To-Torch mode. When your device has a key you can map to 'hold', you can use this feature to keep the light on as long as the key is pressed. The AT&T Fuze is one of those devices with a PTT button.
---------------
UPDATE 01-09-2008 v1.1:
TorchButton v1.1 now includes the ability to override the default timeout from 30 seconds to anywhere between 0 and 300 (= 5 minutes) seconds. The regkey is HKLM\Software\TorchButton\FlashlightTimeout (DWORD). When the application installs or when it starts for the first time it will create the registry setting if it doesn't exist yet.
UPDATE 09-11-2008 v1.2:
Finally a new version of TorchButton.
* Enlarged maximum timeout override from 300 seconds to 86400 seconds (a day).
* Added 'bright' feature. Note that the light may flicker almost unnoticeable every 750ms. Can't prevent that.
* For Devs: attached source code of TorchButton to this post.
* For Devs: I've created a C# library for easy control of the camera led. Also attached to this post. The .zip contains a readme which has examples on how to use it.
UPDATE 14-11-2008 v1.3:
* Added 'blink' feature. Registry configuration options:
- blinkTimeOnInMs (DWORD), default 500. Configures the time the LED is on.
- blinkTimeOffInMs (DWORD), default 500. Configures the time the LED is off.
* Added 'SOS' feature. More like a 'morse code' feature though. You can set any morse code to be signalled in the registry. Options:
- sosCode (SZ), default " ...---...". Configures the morse code to signal.
- sosDotTimeoutInMs (DWORD), default 200. Configures 200ms LED on, and 200ms LED off for ".".
- sosDashTimeoutInMs (DWORD), default 400. Configures 400ms LED on, and 400ms LED off for "-".
- sosSpaceTimeoutInMs (DWORD), default 1000. Configures 1000ms pause when processing space " ".
* New shortcuts are added for those features.
* Shortcuts are moved to a TorchButton folder within the Programs, for grouping purposes (in case you're wondering where TorchButton went!).
UPDATE 29-11-2008 v1.4:
* Fixed 'sos' mode. It now properly uses a single configurable unit time to calculateother intervals.
* Updated 'sos' mode. You can now configure a text to be sent via morse code in the registry. Check configuration part of the readme for more info.
* Removed old 'sos' registry settings and replaced them with new ones.
- Check out the new configuration settings in the readme.txt (attached to this post).
* Increased default flashlight timeout from 30 to 60 seconds.
* Changed default 'blink' time to 250ms for both on and off.
UPDATE 28-04-2009 v1.5:
* Added Push-To-Torch (PTT) mode. Probably only useful for devices that have the PTT button, such as the AT&T Fuze.
* Added brightResetTimeInMs registry setting for owners of the Alltel Touch Pro. They need to set this value to 100 for bright mode to work properly.
---------------
TODO's:
* Change LCD brightness to minimum when application starts, and restore when exists.
* Prevent standby mode while active
---------------
Developers:
The source code has been attached as well. The app has been written in C/CPP using VS2008. The code doesn't deserve a beauty-price, but it does its job. The 'TorchButtonBright' project is just a wrapper that calls TorchButton.exe with the /bright parameter. This is a workaround to be able to deploy two shortcuts with different icons and a parameter. If anyone decides to use this code, please rename the project. I've also written a C# library that allows easy access to the normal and bright flashlight modes. Attached as well.
---------------
TorchButton v2.x supports the Leo as well as Raphael and moved to a new thread! Click this link!
Works beautifully with stock HTC ROM provided with Raphael released in Europe. One small request: can you provide also an option to change the timeout? For starters - in registry. Some people would like it to work only for 10s, others: for 60s. Others might have the fun of burning it out [anyway you can limit it to max 2 minutes just to protect those less-aware.]
Tnx
Tnx for your effort. It works great.
Works like a charm! Thnx!
I second the request for a change in time out. I need to make it from the front door to my bed without waking my gf, and i don't make it in 30 seconds
works great! Nice job! This will become a standard application on all custom roms
)
Thank you NetRipper. This is a 5 Star utility!!!
HALLELUJAH !
thank you a million times !
make that trillion
Thanks for all the great responses and I'm glad it works for everyone. I'll add that feature to change the hardcoded 30 seconds timeout tomorrow or the day after.
the flashlight has a normal condition and a very bright condition. would it be possible to make a dimmer on the flashlight so that for example one can attach it to the volume buttons on the side ?
Thank you . I have it as part of favourite programs in TF3D . Works great.
da_jojo said:
the flashlight has a normal condition and a very bright condition. would it be possible to make a dimmer on the flashlight so that for example one can attach it to the volume buttons on the side ?
Click to expand...
Click to collapse
The flash indeed has two modes. However, the very bright mode is automatically disabled after 1 or 2 seconds by the camera driver. It's possible to make it sleep for that amount of time and re-set the bright mode, but I can't imagine it being very good for the LED to burn for a longer period of time at that mode. It would also flicker every 1 or 2 seconds.
I think the normal LED is bright enough, so unless the demand for the extra bright setting is overwhelming, I'll keep it like this.
mm that sucks.
its not a great idea to have a flashing flashlight unless one wants to drive anyone crazy or likes discolights ... maybe an idea lol... a stroboscope.. or some sort of signaling light..
it wouldnt hurt to have the LED on for a longer period. since the lifespan is over 50000 hours and it is running on lower power then intended .. only thing, is that it takes toll on the battery. i wouldnt care to much for the LED as it will last longer then the phone's display.
Looks good to me, but you could always play on words and rename it TorchPro. :-D
yesterday I wrote for myself something just like yours. but i prefered fullscreen button which would change color to black while LED switches on (useful in dark places - eyes are not blinded by bright screen).
it is possible to change timeout (setting written in registry) using track bar or up-down, left-right keys.
enter key switches LED on and off. just like big on screeen button.
have fun.
Great stuff, works really well.
steveoidm said:
Great stuff, works really well.
Click to expand...
Click to collapse
+1
Just what i was looking for,
Nadavi
Thank you guys. You,re perfect. I was very sad,when I found out,that VJCandela doesn't work.
new feature request.
Using the Gsensor let it keep the led on as long as the device senses motion, put it down and it turns the led of in 10 seconds.
Doable?
Thanks
Jules
Now thats an excellent suggestion.
Are we 100% sure that leaving the LED on for prolonged periods at the low level is not going to have any adverse effect on it.
Any chance of a version for the LG KS20 ?
hi
is there any way to disable the led of the hardware buttons. i know where the buttons are. i dont need a light to find them. and it looks ugly when they light up. after i used them i always wait to touch the screen until they are off.
I think neldar knows the most about this since he has done the backlight notifications mod. It would be super to have an option in the recovery to disable backlight in the buttons. They are annoying at night when using Screen filter to dim the screen, buttons are very bright in contrast to the screen.
Agreed. I would love to be able to switch them off.
Yes this is true and really anoying!
At night they are much to bright. Would love a "disable" option, too.
Is it maybe possible to dimm the buttons, too?? This would really be awesome
ok, i'm not the only one who wants that leds switched off. but isn't there anyone who has an idea how to do that
Anyone figured this out yet?
i found an app in the market called“ leds hack“. it supports samsung vibrant, but it dont works on my phone. isnt it the us-name for the sgs? maybe the rom is the problem. i'm on darkys 9.3
i tryed to find the script that controls the backlight. here: stackoverflow.com/questions/4152053/android-turn-off-key-lights i found this info:
A: The keyboard backlight can be controlled via /sys/class/leds/ keyboard-backlight/brightness. It appears that it's a simple on-off control (echoing '0' turns it off, echoing '1' or higher turns it on). For some reason, the default system backlight control stuff seems to set this to "83", but I don't know why. I can't seem to see any difference between 83 and any other number. The file is readable by anyone, but only writable by root, so you'll need root access to the phone to manipulate it this way.
can anyone tell me where i can find the file on my phone...
Has anyone found the answer?
This is honestly something that I would even pay for if a dev wanted to create a little app or mod that could do this quickly and easily for those that are not confident to make these changes on their own.
No one? :/
magooo said:
/sys/class/leds/ keyboard-backlight/brightness
Click to expand...
Click to collapse
this doesnt exist on our android.
There is is /sys/devices/virtual/misc/melfas_touchkey/brightness
you can do
echo '1' > /sys/devices/virtual/misc/melfas_touchkey/brightness
to turn it on, but i have not found a way to turn it off permanently
Can some one bind this to light sensor? So that we can have it disabled during day and have it enabled at night??
how can i edit this files? i cant find an editor or something like that. i'd like to play around with this script?
joseph.carty said:
This is honestly something that I would even pay for if a dev wanted to create a little app or mod that could do this quickly and easily for those that are not confident to make these changes on their own.
Click to expand...
Click to collapse
I'd pay too
Please, It have to be so easy
magooo said:
A: The keyboard backlight can be controlled via /sys/class/leds/ keyboard-backlight/brightness
Click to expand...
Click to collapse
I don't have the folder /leds. What version of android do you have?
I found this. As a new user, I can't send links to the forum, I paste the important part:
Samsung GT-I9000
s3c-keypad
- scancode = 26 (confirmed with keylayout/s3c-keypad.kl)
/sys/class/backlight/s5p_bl/brightness
drivers/input/keyboard/s3c-keypad.c
drivers/video/backlight/backlight.c
- brightness and actual_brightness 's get/set method. (actual_brightness is read only)
drivers/video/samsung/s3cfb_tl2796.c
- Samsung's implementation. MIN_BL = 30. Lower than this == black out.
Could it be useful?
Thanks
This project started becaues at night the Atrix display is far too bright. I've successfully compiled the kernel (faux's) and made some changes to the display driver, and from there I found a world of useful info and hacks which enhance our display.
Kernel Update
I have compiled faux's kernel and attached it to this thread. please note, this is NOT the cyanogen version of the kernel, only standard ROM's that use faux123's kernel. i can compile the cyan kernel next. this kernel change is simple, it defaults both the display and buttons to the lowest 5mA display mode. this way a reboot puts you right into the lowest mode, and you can manually set reg 17 to higher as-needed. reg 17 will stay set until the next next reboot.
NOTE: THIS RAMDISK WAS MINE PULLED FROM THE STOCK ROM "WITH EXTRAS", SO PLEASE IF YOU TRY A DIFFERENT ROM HAVE A NAND BACKUP READY TO RESTORE JUST IN CASE!!! I HAVENT TRIED THE OTHER ROMS.
it is the zImage and Ramdisk, so it is flashed like:
boot into fastboot (volume down and power on, then vol down till fastboot shows, then vol up to select).
Code:
moto-fastboot flash:raw boot zImage ramdisk.gz
sorry it's not a flashable zip. i purposely uses RAR so nobody tries to flash it with CWM.
Update - The brightness limit of 30 has now been removed:
The autobrightness can now go all the way down to 00 even with your stock kernel and ROM. The limit was coming from the frameworks. I've re-compiled the frameworks for the stock ROM and also for Cyan pre-beta 3. There are 2 frameworks attached to this post, stock and cyanogen. download from this post and unzip your correct file for your ROM, and ADB push the files to your phone:
Code:
- boot to recovery
- mount system
adb push framework-res.apk /system/framework/framework-res.apk
adb reboot
Update - Cyanogen Pre Beta 4 frameworks added
unzup and flash with adb shown above.
Here is what is found in the frameworks, under res/values/arrays.xml:
Code:
10
50
100
150
200
700
1300
2000
3000
4000
5000
6000
7000
8000
9000
20
20
34
46
62
81
100
119
137
138
153
170
187
206
221
255
255
255
255
192
128
0
0
0
0
0
0
0
0
0
0
0
I changed the first value in config_autoBrightnessLcdBacklightValues from a 20 to a 2, and now in auto brightness mode the screen goes all the way down to 2.
Update:
We now have the proper official data sheet (link below) thanks to Saltinbas.
Documentation - Data Sheet
Our backlight chip is the lm3532, which is basically same as lm3530 which is used in the moto droid. i've read the entire data sheet twice and still trying to grasp everything. the data sheet can be found here:
http://www.national.com/ds/LM/LM3532.pdf
Not all registers are exactly the same, so some reverse engineering is needed.
Source Code (Kernel)
The relevant kernel source code:
leds-lm3532.c - Driver
leds-lm3532.h - Headers
board-mot-lights.c - Initialization
What I've Tried So Far
The first change I made was in board-mot-lights.c.
Code:
struct lm3532_platform_data lm3532_pdata = {
.flags = LM3532_CONFIG_BUTTON_BL | LM3532_HAS_WEBTOP,
.init = disp_backlight_init,
.power_on = disp_backlight_power_on,
.power_off = disp_backlight_power_off,
.ramp_time = 0, /* Ramp time in milliseconds */
.ctrl_a_fs_current = LM3532_26p6mA_FS_CURRENT,
.ctrl_b_fs_current = LM3532_8p2mA_FS_CURRENT,
.ctrl_a_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_b_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_a_pwm = 0x82,
};
I changed lines 99 and 100 to this:
Code:
.ctrl_a_fs_current = LM3532_5mA_FS_CURRENT,
.ctrl_b_fs_current = LM3532_5mA_FS_CURRENT,
Success
And bingo, display brightness reduced significantly lower than stock. the display has many different "modes" and I went right to the lowest on the list. Here are the brightness modes which can be found in the header file leds-lm3532.h:
Brightness Config Values (Header File)
Code:
#define LM3532_5mA_FS_CURRENT 0x00
#define LM3532_5p8mA_FS_CURRENT 0x01
#define LM3532_6p6mA_FS_CURRENT 0x02
#define LM3532_7p4mA_FS_CURRENT 0x03
#define LM3532_8p2mA_FS_CURRENT 0x04
#define LM3532_9mA_FS_CURRENT 0x05
#define LM3532_9p8mA_FS_CURRENT 0x06
#define LM3532_10p6mA_FS_CURRENT 0x07
#define LM3532_11p4mA_FS_CURRENT 0x08
#define LM3532_12p2mA_FS_CURRENT 0x09
#define LM3532_13mA_FS_CURRENT 0x0A
#define LM3532_13p8mA_FS_CURRENT 0x0B
#define LM3532_14p6mA_FS_CURRENT 0x0C
#define LM3532_15p4mA_FS_CURRENT 0x0D
#define LM3532_16p2mA_FS_CURRENT 0x0E
#define LM3532_17mA_FS_CURRENT 0x0F
#define LM3532_17p8mA_FS_CURRENT 0x10
#define LM3532_18p6mA_FS_CURRENT 0x11
#define LM3532_19p4mA_FS_CURRENT 0x12
#define LM3532_20p2mA_FS_CURRENT 0x13
#define LM3532_21mA_FS_CURRENT 0x14
#define LM3532_21p8mA_FS_CURRENT 0x15
#define LM3532_22p6mA_FS_CURRENT 0x16
#define LM3532_23p4mA_FS_CURRENT 0x17
#define LM3532_24p2mA_FS_CURRENT 0x18
#define LM3532_25mA_FS_CURRENT 0x19
#define LM3532_25p8mA_FS_CURRENT 0x1A
#define LM3532_26p6mA_FS_CURRENT 0x1B
#define LM3532_27p4mA_FS_CURRENT 0x1C
#define LM3532_28p2mA_FS_CURRENT 0x1D
#define LM3532_29mA_FS_CURRENT 0x1E
#define LM3532_29p8mA_FS_CURRENT 0x1F
Then i discovered that we don't even need to compile a new kernel to access this chip. We have the proper sysfs files already given to us by motorola engineers. here are some useful commands:
Terminal Commands
Use terminal app and navigate to:
Code:
su
cd sys/bus/i2c/drivers/lm3532/0-0038/leds/lcd-backlight
you can set any of the above modes you want. as an example let's say I want to set to maximum brightness mode, use the corresponding hex value in the header file from earlier, and type:
Code:
echo 17 1F > registers
that sets register 0x17 (the brightness register) with value 0x1F (the maximum brightness value from the list).
To set the minimum brightness:
Code:
echo 17 00 > registers
now for those of you who would like to help out with this and test other registers, you can see all register values by typing:
Code:
cat registers
that brings up this:
Code:
OUTPUT_CFG_REG (0x10) = 0xD4
START_UP_RAMP_REG (0x11) = 0xC0
RUN_TIME_RAMP_REG (0x12) = 0xC0
CTRL_A_PWM_REG (0x13) = 0x86
CTRL_B_PWM_REG (0x14) = 0x82
CTRL_C_PWM_REG (0x15) = 0x82
CTRL_A_BR_CFG_REG (0x16) = 0xE3
CTRL_A_FS_CURR_REG (0x17) = 0xFF
CTRL_B_BR_CFG_REG (0x18) = 0xE3
CTRL_B_FS_CURR_REG (0x19) = 0xE4
CTRL_C_BR_CFG_REG (0x1a) = 0xF1
CTRL_C_FS_CURR_REG (0x1b) = 0xF3
ENABLE_REG (0x1d) = 0xFF
FEEDBACK_ENABLE_REG (0x1c) = 0xF9
ALS1_RES_SEL_REG (0x20) = 0xE0
ALS2_RES_SEL_REG (0x21) = 0xE0
ALS_CFG_REG (0x23) = 0x44
ALS_ZONE_REG (0x24) = 0xF0
ALS_BR_ZONE_REG (0x25) = 0xF8
ALS_UP_ZONE_REG (0x26) = 0xF8
ZB1_REG (0x60) = 0x35
ZB2_REG (0x61) = 0x33
ZB3_REG (0x62) = 0x6A
ZB4_REG (0x63) = 0x66
CTRL_A_ZT1_REG (0x70) = 0x51
CTRL_A_ZT2_REG (0x71) = 0x66
CTRL_A_ZT3_REG (0x72) = 0x99
CTRL_A_ZT4_REG (0x73) = 0xCC
CTRL_A_ZT5_REG (0x74) = 0xFF
CTRL_B_ZT1_REG (0x75) = 0x00
CTRL_B_ZT2_REG (0x76) = 0x66
CTRL_B_ZT3_REG (0x77) = 0x99
CTRL_B_ZT4_REG (0x78) = 0xCC
CTRL_B_ZT5_REG (0x79) = 0xFF
CTRL_C_ZT1_REG (0x7a) = 0x33
CTRL_C_ZT2_REG (0x7b) = 0x66
CTRL_C_ZT3_REG (0x7c) = 0x99
CTRL_C_ZT4_REG (0x7d) = 0xCC
CTRL_C_ZT5_REG (0x7e) = 0xFF
VERSION_REG (0xcc) = 0xE4
You can set any register XX with any value YY as follows:
Code:
echo XX YY > registers
additional knowledge i've learned so far. Ctrl A is the main display. Ctrl B is the bottom buttons. Ctrl C is webtop. So all we really care about are Ctrl A registers for now.
Additional Info
The display is set to linear mapping mode by default. but changing to exponential mapping mode gives a huge range from minimum to maximum brightness. but it's still not ready for primetime. to try out exponential, type:
Code:
echo 16 01 > registers
now go to your main phone settings, display, brightness, and drag the slider from min to max and see the enormous full range now available. dont worry, to reset exponential mode just lock the screen with power button then unlock, exponential mode gets cleared. that can be fixed later in the kernel when we get it working better.
just setting to minimum brightness alone gives a huge increase in battery life for display-on time, specifically at night. there's more potential to get out of this chip so hopefully you guys can dig up more stuff that i'm missing.
at some point I can compile the kernel with any changes discovered from this thread, and perhaps we can merge the code changes back into the kernel repo if faux doesn't mind.
Problem 1
I don't fully understand the meaning of the header file brightness values. The names list current mA values, that is clear. but there are also other info in the name which I don't understand yet.
similarly, in the data sheet, they give detailed examples of how to calculate the current draw of each brightness mode, and walk thru setting up the general configuration register. i've been reverse engineering the registers by looking at the data sheet, seeing each 8 bits and what they are assigned, then using appropriate hex value to turn off and on each of those bits in the output config reg. i echo a value, and see the result. most of the time it matches the data sheet, but not always.
Problem 2
There are also 4 boundary zones which trigger the backlight to adjust it's brightness. i've attempted to set these boundaries to different values, but so far i've not had any success with this.
Problem 3
Before this all started, no matter what the display brightness only goes down to 30 from a range of 0-255. even changing all the modes i've listed above, in every one it stops at 30. you can check brightness level by:
Code:
cat brightness
I'm stumped on where the 30 limit is coming from.
Ultimately, we can permanently change the following code in board-mot-lights.c to whatever desired values we want to be in the kernel permanently:
Code:
struct lm3532_platform_data lm3532_pdata = {
.flags = LM3532_CONFIG_BUTTON_BL | LM3532_HAS_WEBTOP,
.init = disp_backlight_init,
.power_on = disp_backlight_power_on,
.power_off = disp_backlight_power_off,
.ramp_time = 0, /* Ramp time in milliseconds */
.ctrl_a_fs_current = LM3532_26p6mA_FS_CURRENT,
.ctrl_b_fs_current = LM3532_8p2mA_FS_CURRENT,
.ctrl_a_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_b_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_a_pwm = 0x82,
};
And a companion app could also be made to automate the setting of these registers and such.
last thing, above notice the PWM value being set to 0x82. this is pulse width modulation mode, and is a significant power saving method in electronics. fortunately this is turned on by default, which is what the value 0x82 is doing. i've experimented turning it off and on for the hell of it.
hope some experts can join in this thread and see how far it goes. any questions feel free to ask.
Curious about the difference between software modification (screen brightness apps) and kernel modification (for brightness)
Excellent I like tinkerers and thanks for info so far
Magnetox said:
Curious about the difference between software modification (screen brightness apps) and kernel modification (for brightness)
Click to expand...
Click to collapse
Well this project is both kernel and could use an app to control the registers. But primarily this is to make kernel changes for now.
is this able to lower the brightness to BELOW the '2' setting? that's as low as AdjBrightness app lets me go, and also doesn't allow me to dim the home buttons. it would be nice to be able to dim the buttons at least, especially if watching a movie or something in the dark.
dLo GSR said:
is this able to lower the brightness to BELOW the '2' setting? that's as low as AdjBrightness app lets me go, and also doesn't allow me to dim the home buttons. it would be nice to be able to dim the buttons at least, especially if watching a movie or something in the dark.
Click to expand...
Click to collapse
Yes this can absolutely dim the buttons, anywhere from off to full brightness. Just echo to ctrl B register.
I'm not aware of the display app you mentioned. Does it do all the things I already listed in this thread? If so I feel dumb, I've not heard of the app you said.
Edit: I see that app in the market. This thread is specific to the atrix kernel, so it offers much more control. Activate exponential mapping mode and the display brightness goes down so low you wont even believe it. We'd then maybe make an app to automate it.
Forgive my ignorance, but the app SuperDim changes the brightness on my Atrix. Perhaps you guys are talking about something else though?
The lowest brightness setting is still much too bright to enjoy my Atrix in the dark (lol). The wife gets pissed... but this app definitely works.
Very cool!
'cat registers' only works when display is on. I'll have to see if an app can be done that doesn't have to fight the system.
Cheers!
or you could get an app called screen filter which does all this o.o
xepter said:
or you could get an app called screen filter which does all this o.o
Click to expand...
Click to collapse
Well, no, actually.
Hopefully something similiar to this, kernel maybe, all contains settings for the touch screen(digitizer)and we can alleviate the pesky rain drop detection issue.
A little late for me to start playing with this, maybe tomorrow!
Thanks
Sent from my MB860 using xda premium
what this is doing is reducing the current sent to the backlight to dim it.
Screen filter doesnt reduce current to the backlight past the stock minimum limit. It just puts a transparent "mask" over the display with the opacity depending on your setting, done entirely in software.
m0biusace said:
what this is doing is reducing the current sent to the backlight to dim it.
Screen filter doesnt reduce current to the backlight past the stock minimum limit. It just puts a transparent "mask" over the display with the opacity depending on your setting, done entirely in software.
Click to expand...
Click to collapse
Yes you bring up my next point, this isn't just brightness. This let's us reduce the current draw pulled by the display, and a good amount at that if you read the data sheet and look at the registers.
Additionally this let's us set and change the zone boundaries of the light sensor. It let's us change mapping mode between linear and exponential.
It also let's us control PWM, though that should just stay on all the time. Also there is ramp time register, which is set to zero by Motorola, so that might be useful.
Also there is the brightness config reg, full scale current reg, and general output config reg. All these look to have purpose needed to be tested.
There are many registers to tweak which gives us control, and that's the goal of this thread I think. Once we crack it all open then we can make permanent kernel changes if we want. Or an app would work. I think we could do something crazy like double screen time by finding optimal combo of reg settings, e.g. set min brightness mode with exponential mapping mode, then adjust the zone boundaries slightly,and it literally could give huge display savings for power. At least worth testing to see.
faux123 said:
Excellent I like tinkerers and thanks for info so far
Click to expand...
Click to collapse
Dude thank you for letting me compile your kernel. Much appreciated! And tinkering is what's fun about android!
some interesting behavior here:
lowest brightness in Stock 2.3.4 is "20", you can adjust to "2" by using app "adjbrightness", while you can set brightness lower to "1" in "moboplayer".
Even though, the "1" brightness is not good enough.
I'm wondering if this MOD can make brightness lower than "1"?
NFHimself said:
Very cool!
'cat registers' only works when display is on. I'll have to see if an app can be done that doesn't have to fight the system.
Cheers!
Click to expand...
Click to collapse
Yeah the driver is overriding some things, we could easily fix the code though. For example if you change the gen config reg to activate a different mode, soon as screen goes off locked the register is set back to previous value cause its hard coded. We just change that. So during testing I just keep the screen on.
I do have a battery app which does the echo and cat commands already written. Could just change the path and use it for this project...
kenyloveg said:
some interesting behavior here:
lowest brightness in Stock 2.3.4 is "20", you can adjust to "2" by using app "adjbrightness", while you can set brightness lower to "1" in "moboplayer".
Even though, the "1" brightness is not good enough.
I'm wondering if this MOD can make brightness lower than "1"?
Click to expand...
Click to collapse
Yes. Just enable exponential mapping mode, then use the slider in main display setting to see the full range.
echo 16 01 > registers
Be ready, super dim with that setting. Note still even with that being much lower brightness, the actual brightness value still wont go lower than 30. I can't figure out why.
SuperDim
As member bongd mentions already, SuperDim does the thing, free on the Market. I've pressed thanks button to show appreciation to the OP's efforts.
maajstor said:
As member bongd mentions already, SuperDim does the thing, free on the Market. I've pressed thanks button to show appreciation to the OP's efforts.
Click to expand...
Click to collapse
Superdim does not allow the brightness to even get close to the minimum level that the screen does by setting the registers. Testing is needed and that's kinda the point here.
So the lm3532 chip has brightness capabilities from 5mA up to 29the mA. Stock value in the kernel is set to very high at 26 mA. So just setting the lowest brings the current draw to 5 mA. The data sheet then shows the equation gives final result of close to 0.78 mA with all set properly. So there's savings to be had which is what needs to be tested here.
As an example, last night I changed to the lowest register setting, and after an hour of web screen-on time I was still at 86%the battery still.
maajstor said:
As member bongd mentions already, SuperDim does the thing, free on the Market. I've pressed thanks button to show appreciation to the OP's efforts.
Click to expand...
Click to collapse
Wow! You guys just aren't getting it. The apps you find in the market do not do the same thing. "Yes in the aspect they dim the screen" but they do it in to completely different ways. The way the op is talking about could add hours of battery life to are phones if done right. Because it changes how much power the display uses. There is not an app in the market or out that does that.
I've seen many people ask the same question, always to get the wrong answer
I'd like to change the time that my display will remain active,
whilst in lockscreen mode.
So I don't care about timeout of the screen in normal operation,
I want my lockscreen (with the clock, weather, and music) to
NOT TIMEOUT in 5 seconds but stay on forever, or configurable.
This setting is most certainly unavailable. The setting under settings,screen,screen timeout are not the settings I need.
All the tools in the market either replace your lockscreen, or
won't let you set the time the lockscreen stays "active" or "illuminated"
Please help, this drives me nuts.
Update :
From the devs at teamhacksung I learned about the class : KeyGuardMediator.java (from the gingerbread branch
https://gist.github.com/CyanogenMod...nternal/policy/impl/KeyguardViewMediator.java
android_frameworks_base / policy / src / com / android / internal / policy / impl / KeyguardViewMediator.java policy/src/com/android/internal/policy/impl/KeyguardViewMediator.java
/**
* The default amount of time we stay awake (used for all key input)
*/
protected static final int AWAKE_INTERVAL_DEFAULT_MS = 5000;
/**
* The default amount of time we stay awake (used for all key input) when
* the keyboard is open
*/
protected static final int AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS = 10000;
/**
* How long to wait after the screen turns off due to timeout before
* turning on the keyguard (i.e, the user has this much time to turn
* the screen back on without having to face the keyguard).
*/
private static final int KEYGUARD_DELAY_MS = 5000;
I'd like to see the bold values changed to 3600000 and 60000 .
How do I go from here ?
any news on this? I have the same issue. my phone is set to turn off the display after 30 seconds. If i unlock my phone and go to the home screen, that works. If i just turn my screen on and look at my lock screen (to read weather, time) it turns off after 5 seconds. so annoying without an adjustment
Same issue/annoyance here- subscribed
Found a workaround. App is called ISeeYou. Similar to gs3, screen will stay on as long as the front camera detects a face
Sent from my Galaxy Nexus using XDA
Just installed it, haven't tested it thoroughly. Doesn't work in the dark. Seems promising though
Sent from my Galaxy Nexus using XDA
This started out as an idea I had while trying to calibrate the screen color of my Nexus S using a colorimeter. While a lot of users are not particularly picky about colors, I do hope quite a number of people would also be interested in this. To give a clearer understanding for all, I'll put in a not-so-short introduction.
As most of us would know, AMOLED screens, while good in terms of brightness and contrast, tend to distort colors. If you're viewing an image on an AMOLED screen, you'll likely notice areas which appear oversaturated and have blown-out details. The reason behind this is that our AMOLED screens have a much wider gamut (i.e. displays more colors) than how images are encoded. If you look at the image below, the bigger triangle represents the set of colors that the AMOLED screen can display. The smaller triangle is the sRGB reference color which is how Android and most images are encoded.
Unfortunately for us, the Android OS isn't aware of this difference. A color with value of #00FF00 (pure green) should look like the green at the upper peak of the smaller triangle. But in reality, it is shown to us as the green of the larger triangle. This remapping between the two color spaces causes lighter shades of color to appear darker (or actually more saturated).
So far, the solution to fixing the problem is through the use of voodoo color (cheers to supercurio). Voodoo allows for the modification of gamma which somehow compensates for the saturation levels of the colors. Also, color multipliers allow for the shifting of the white point. White point, you ask? See, the intersection of the dotted lines? That is the white point which is how white would appear on the screen. Some like warm colors (white points to the right) while cool colors are to the left. However, gamma and multipliers only operate on a single color at a time. This means that the larger triangle will always remain the same shape regardless of the settings we use. Colors would look better but still not the same as the original intent.
So what can we do about it? Well one way would be by analyzing the way in which colors are mapped to a visually-oriented reference (such as the xyY/XYZ space shown in the above image). A standard sRGB image would be mapped using:
While the Nexus S (using the marmite kernel by bedalus with equal multipliers) would map out like:
In effect, you can find a map to convert the intended sRGB colors to the values usable by the screen to simulate the original rendering intent of the colors. This is done by using the following relationship:
Note that the other non-labelled matrix here is simply a way to shift the white point from 6500K (warm) to 9300K (cool) to display good colors on our devices using chromatic adaptation. The end effect is a means to fix color by simply mixing together red, green, and blue values (after gamma correction to be strictly accurate but this has its tolerances). The mix is just as shown above or in a more non-scientific notation:
Code:
R = 0.7043 * R + 0.3440 * B - 0.0028 * B
G = 0.0160 * R + 0.8930 * G + 0.0598 * B
B = 0.0195 * R + 0.0846 * G + 1.1185 * B
As an example, I've uploaded a before-and-after comparison of a test image. On a computer display, the right image (modified) would appear weird compared to the left image but if you load it up (or just view it) on your phone, you can see that the right one actually looks better (no oversaturation). This would be better if you have voodoo color with the multipliers set to more or less equal values.
The task then is to implement this on a kernel level (or similar) which I will touch on my next post (maybe tomorrow). Note that I have not successfully done the modifications as I lack the development skillz to match. In this regard, I would like to solicit the assitance of the dev community with a much wider experience with these things than I do.
So I decided to continue writing this today...
Unlike the voodoo color codes which rely on hardware (TL2796 AMOLED driver) to implement gamma correction, the color mixing process is a bit more involved on the software end. There are no chips on the Nexus S which can be configured to perform the mixing process natively. Instead, I have a few ideas on the implementation of the mixing process.
1. Rewrite the framebuffer
I've attempted doing this using native code by opening the /dev/graphics/fb0 device but the problem lies in timing. If the timing is off, the mixing either never occurs or is repeated several times for a given frame causing color distortions. This is further complicated by the use of double buffering on the device. Even more so with the switching behavior between double and triple buffering in JB! I've tried hijacking the VSYNC signal to operate on the timing (see colormix.c attached) but the result is still very glitchy. Or I may be doing it wrong...
2. Handle all routines that write to the framebuffer
Another way would be to handle all the writes to the framebuffer device. This eliminates the need for timing as processing occurs only once as the data is transferred to the framebuffer. I've seen the codes for cfbcopyarea.c, cfbimgblit.c, and cfbfillrect.c but I'm not sure where direct writes to the framebuffer (using mmap access) are handled (if at all handled). So again, I'm not too sure about this one.
3. Hijack the interface from the LCD driver
Yet another unsure idea by the way. Since the LCD driver interact with the physical hardware through 24 GPIO pins, there should be some code describing how data is transferred to these pins. At that level, it might be possible to manipulate the signal just before it is sent to avoid timing issues mentioned earlier.
Most of these ideas are speculative from a person who is not really that deep into development (I'm more of an image processing researcher ). Any feedback and ideas from the community would be great!
I'm down with matrices. Sign me up!
some good ideas here, if you manage to calibrate our screens without using voodoo, this idea can potentially be used on other amoled devices such as s3 to calibrate it, removing it's over-saturation
bedalus said:
I'm down with matrices. Sign me up!
Click to expand...
Click to collapse
LOL. Matrices are fun! Thanks bedalus!
By the way, I took a look at the driver codes and it may be possible to find the next framebuffer using ioctl (from an external program).
Code:
case S3CFB_GET_CURR_FB_INFO:
next_fb_info.phy_start_addr = fix->smem_start;
next_fb_info.xres = var->xres;
next_fb_info.yres = var->yres;
next_fb_info.xres_virtual = var->xres_virtual;
next_fb_info.yres_virtual = var->yres_virtual;
next_fb_info.xoffset = var->xoffset;
next_fb_info.yoffset = var->yoffset;
next_fb_info.lcd_offset_x = 0;
next_fb_info.lcd_offset_y = 0;
if (copy_to_user((void *)arg,
(struct s3cfb_next_info *) &next_fb_info,
sizeof(struct s3cfb_next_info)))
return -EFAULT;
break;
Invoking this should at least resolve the double buffering issues if timed correctly with VSYNC. Again, IF.
noobiekins said:
some good ideas here, if you manage to calibrate our screens without using voodoo, this idea can potentially be used on other amoled devices such as s3 to calibrate it, removing it's over-saturation
Click to expand...
Click to collapse
Yes actually. You just need colorimeter readings of the locations of the red, green, and blue primaries to build the matrix for any other device and compensate for it.
So based on my last post I tried looking at the behavior of the framebuffer device. It seems that there are a few parameters which are being used by the device namely:
xres/yres - dimensions of the visible image in pixels
xres_virtual/yres_virtual - dimensions of the virtual image in pixels
xoffset/yoffset - position in the framebuffer being used
Click to expand...
Click to collapse
Dumping from a test program, I get one of two sets of values from the framebuffer device:
Code:
Start address: 4debf000
Visible resolution: 480, 800
Virtual resolution: 480, 5600
Offsets: 0, 800
Start address: 4debf000
Visible resolution: 480, 800
Virtual resolution: 480, 5600
Offsets: 0, 0
This more or less tells us that the framebuffer memory is actually divided into multiple buffers each with the visible size (480x800) of the display. They alternate (using the offsets) to provide the double buffering effect Android uses. However, what I can't understand is why there are 7 buffers allocated for the device instead of at most 3 (for triple buffering). It might be useful to take snapshots of the entire framebuffer and write them to consecutive bitmaps but I won't bother with that at the moment.
I've also tried using this behavior to synchronize the framebuffer writes using changes in the offset as a trigger:
Code:
for (;;)
{
do
{
// Extract variable framebuffer information
if(ioctl(fd, FBIOGET_VSCREENINFO, &next_vi) < 0)
{
perror("Cannot extract variable framebuffer information");
return -1;
}
} while (next_vi.yoffset == cur_vi.yoffset);
...
<insert color mixing here>
...
}
Unfortunately, the screen still doesn't update as desired. Lots of flickering involved. I'm not sure if the memory accesses are just too slow such that the screen refreshes before we completely rewrite the framebuffer or if its some other problem. I've attached the full code for anyone who might be able to shed some light on this. In this code, I just did a dummy rewrite (red = green, blue = green) instead of color mixing to avoid computation therefore minimizing CPU loading and to have a more pronounced effect on the screen.
I'm clueless about video, but I'm digging around... These are the files that compile in /drivers/video/
Code:
/home/dave/android/androidkernel/drivers/video/backlight/lcd.o
/home/dave/android/androidkernel/drivers/video/backlight/backlight.o
/home/dave/android/androidkernel/drivers/video/backlight/built-in.o
/home/dave/android/androidkernel/drivers/video/fb_notify.o
/home/dave/android/androidkernel/drivers/video/display/built-in.o
/home/dave/android/androidkernel/drivers/video/fb.o
/home/dave/android/androidkernel/drivers/video/fbsysfs.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_nt35580.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_tl2796.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_fimd6x.o
/home/dave/android/androidkernel/drivers/video/samsung/built-in.o
/home/dave/android/androidkernel/drivers/video/cfbimgblt.o
/home/dave/android/androidkernel/drivers/video/fbmem.o
/home/dave/android/androidkernel/drivers/video/modedb.o
/home/dave/android/androidkernel/drivers/video/cfbcopyarea.o
/home/dave/android/androidkernel/drivers/video/fbcmap.o
/home/dave/android/androidkernel/drivers/video/omap2/displays/built-in.o
/home/dave/android/androidkernel/drivers/video/omap2/built-in.o
/home/dave/android/androidkernel/drivers/video/built-in.o
/home/dave/android/androidkernel/drivers/video/fbcvt.o
/home/dave/android/androidkernel/drivers/video/cfbfillrect.o
/home/dave/android/androidkernel/drivers/video/fbmon.o
I'm combing through these files now to see if there's any obvious points to hack in.
bedalus said:
I'm clueless about video, but I'm digging around... These are the files that compile in /drivers/video/
Code:
/home/dave/android/androidkernel/drivers/video/backlight/lcd.o
/home/dave/android/androidkernel/drivers/video/backlight/backlight.o
/home/dave/android/androidkernel/drivers/video/backlight/built-in.o
/home/dave/android/androidkernel/drivers/video/fb_notify.o
/home/dave/android/androidkernel/drivers/video/display/built-in.o
/home/dave/android/androidkernel/drivers/video/fb.o
/home/dave/android/androidkernel/drivers/video/fbsysfs.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_nt35580.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_tl2796.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_fimd6x.o
/home/dave/android/androidkernel/drivers/video/samsung/built-in.o
/home/dave/android/androidkernel/drivers/video/cfbimgblt.o
/home/dave/android/androidkernel/drivers/video/fbmem.o
/home/dave/android/androidkernel/drivers/video/modedb.o
/home/dave/android/androidkernel/drivers/video/cfbcopyarea.o
/home/dave/android/androidkernel/drivers/video/fbcmap.o
/home/dave/android/androidkernel/drivers/video/omap2/displays/built-in.o
/home/dave/android/androidkernel/drivers/video/omap2/built-in.o
/home/dave/android/androidkernel/drivers/video/built-in.o
/home/dave/android/androidkernel/drivers/video/fbcvt.o
/home/dave/android/androidkernel/drivers/video/cfbfillrect.o
/home/dave/android/androidkernel/drivers/video/fbmon.o
I'm combing through these files now to see if there's any obvious points to hack in.
Click to expand...
Click to collapse
Great! And here I was having trouble figuring out which files were actually being used...
I'm not sure about other types of hacks but if we're talking about framebuffer rewriting (like what I've been trying to do), the following segment in s3cfb.c may be useful:
Code:
static irqreturn_t s3cfb_irq_frame(int irq, void *data)
{
struct s3cfb_global *fbdev = (struct s3cfb_global *)data;
s3cfb_clear_interrupt(fbdev);
fbdev->vsync_timestamp = ktime_get();
wmb();
wake_up_interruptible(&fbdev->vsync_wq);
return IRQ_HANDLED;
}
Assuming the system interrupt for VSYNC is enabled (which I assume to be the case otherwise the Choreographer API of JB shouldn't work), then maybe a hack there could be done to process the framebuffer just in time with the frame refresh. This is of course under the assumption that the rewrite is fast enough. I'll try sorting through those files as well to see if there's some easier hack.
Couldn't you pre-process the data before it gets to the fb? It sounds like you want to read it and rewrite it. Did i understand correctly?
bedalus said:
Couldn't you pre-process the data before it gets to the fb? It sounds like you want to read it and rewrite it. Did i understand correctly?
Click to expand...
Click to collapse
Yep, you got it right. Right now, I'm trying to read and re-write but as you said, ideally it should be pre-processed before it even arrives at the framebuffer. I'm not sure if its possible though. Applications can access the framebuffer by mmap-ing it onto shared memory which they can write directly to. I've found functions for fb_write and fb_mmap (both in fbmem.c) but I'm not sure if they're being used internally by the kernel to handle mmap and write requests. I have too little knowledge of kernel processes to know for sure.
fb_write looks fully internal to me.
It looks like the OS is given access in drivers/video/fbsysfs.c
bedalus said:
fb_write looks fully internal to me.
It looks like the OS is given access in drivers/video/fbsysfs.c
Click to expand...
Click to collapse
I'm not quite sure what you mean by internal. Does that mean that if we modify it, we can change how all data is written to the framebuffer?
As for fbsysfs.c, I can see how the OS writes the variable information pertaining to the framebuffer. However, I can't seem to find any reference to the actual data being written to the framebuffer. Did I miss something?
nightsky87 said:
I'm not quite sure what you mean by internal. Does that mean that if we modify it, we can change how all data is written to the framebuffer?
As for fbsysfs.c, I can see how the OS writes the variable information pertaining to the framebuffer. However, I can't seem to find any reference to the actual data being written to the framebuffer. Did I miss something?
Click to expand...
Click to collapse
I'm not 100% sure yet, but I think if you needed to, there is probably a way to hack in at that point.
However supercurio hacked into the gamma here arch/arm/mach-s5pv210/herring-panel.c
...and RGB: drivers/video/samsung/s3cfb_tl2796.c
Is your gamut correction totally independent of RGB/gamma?
EDIT: Oh, I see it now. You have to correct R based partly on G and B etc. Okay. I'll keep looking.
bedalus said:
I'm not 100% sure yet, but I think if you needed to, there is probably a way to hack in at that point.
However supercurio hacked into the gamma here arch/arm/mach-s5pv210/herring-panel.c
...and RGB: drivers/video/samsung/s3cfb_tl2796.c
Is your gamut correction totally independent of RGB/gamma?
EDIT: Oh, I see it now. You have to correct R based partly on G and B etc. Okay. I'll keep looking.
Click to expand...
Click to collapse
Yep... I realized that my attempt at buffer rewrites read and write from the framebuffer one byte at a time! Major I/O overheads! I totally forgot about that.
I'll try rewriting that code as well.
Here's another file:
Code:
include/linux/tl2796.h
It contains the template for the RGB multipliers.
EDIT: I'm trying to see which files use this header now
EDIT: arch/arm/mach-s5pv210/herring-panel.c
...and drivers/video/samsung/s3cfb_tl2796.c
...these are the only two files, so the matrix transformation you want to perform probably needs to happen in one of these files only.
bedalus said:
Here's another file:
Code:
include/linux/tl2796.h
It contains the template for the RGB multipliers.
EDIT: I'm trying to see which files use this header now
EDIT: arch/arm/mach-s5pv210/herring-panel.c
...and drivers/video/samsung/s3cfb_tl2796.c
...these are the only two files, so the matrix transformation you want to perform probably needs to happen in one of these files only.
Click to expand...
Click to collapse
I think the RGB multipliers you're referring to are the same ones used by supercurio and they operate on a per-color basis. In fact, those two files don't directly modify RGB values as far as I can tell. By the time the signal reaches the TL2796 AMOLED driver, they're already mapped to the GPIO_LCD_D<> ports (see /arch/arm/mach-s5pv210/include/mach/gpio-herring.h for the physical mapping).
EDIT:
I did a grep on fb_write and bumped into this code in /include/linux/fb.h:
Code:
/* For framebuffers with strange non linear layouts or that do not
* work with normal memory mapped access
*/
ssize_t (*fb_read)(struct fb_info *info, char __user *buf,
size_t count, loff_t *ppos);
ssize_t (*fb_write)(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
Since I can confirm that the framebuffers with our devices can support mmap, I suppose this means any app can directly read/write to the framebuffer without going through some intermediate function. This leaves us with framebuffer rewrites or hijacking the transfer of data from framebuffer to physical device. I like the second option better.
nightsky87 said:
I think the RGB multipliers you're referring to are the same ones used by supercurio and they operate on a per-color basis. In fact, those two files don't directly modify RGB values as far as I can tell. By the time the signal reaches the TL2796 AMOLED driver, they're already mapped to the GPIO_LCD_D<> ports (see /arch/arm/mach-s5pv210/include/mach/gpio-herring.h for the physical mapping).
Click to expand...
Click to collapse
After a lot of head scratching, I see what you mean.
I performed a search for S5PV210_GPF* and found these files:
Code:
drivers/gpio/gpio-s5pv210.c
arch/arm/mach-s5pv210/herring-panel.c
arch/arm/mach-s5pv210/setup-fb.c
arch/arm/mach-s5pv210/mach-herring.c
...all of which are compiled into the kernel.
Probably if the best place to intervene is on the GPIOs, it must be in one of these files. I'll keep looking!
EDIT: I just saw your edit in the previous post, and I agree! Option 2 seems preferable.
bedalus said:
After a lot of head scratching, I see what you mean.
I performed a search for S5PV210_GPF* and found these files:
Code:
drivers/gpio/gpio-s5pv210.c
arch/arm/mach-s5pv210/herring-panel.c
arch/arm/mach-s5pv210/setup-fb.c
arch/arm/mach-s5pv210/mach-herring.c
...all of which are compiled into the kernel.
Probably if the best place to intervene is on the GPIOs, it must be in one of these files. I'll keep looking!
EDIT: I just saw your edit in the previous post, and I agree! Option 2 seems preferable.
Click to expand...
Click to collapse
Ironically, register definitions don't seem to be in those files. They probably used a different set of defines. What I did find was this in /drivers/video/samsung/s3cfb_fimd6x.c:
Code:
int s3cfb_set_buffer_address(struct s3cfb_global *ctrl, int id)
{
struct fb_fix_screeninfo *fix = &ctrl->fb[id]->fix;
struct fb_var_screeninfo *var = &ctrl->fb[id]->var;
struct s3c_platform_fb *pdata = to_fb_plat(ctrl->dev);
dma_addr_t start_addr = 0, end_addr = 0;
u32 shw;
if (fix->smem_start) {
start_addr = fix->smem_start + (var->xres_virtual *
(var->bits_per_pixel / 8) * var->yoffset);
end_addr = start_addr + fix->line_length * var->yres;
}
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw |= S3C_WINSHMAP_PROTECT(id);
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
writel(start_addr, ctrl->regs + S3C_VIDADDR_START0(id));
writel(end_addr, ctrl->regs + S3C_VIDADDR_END0(id));
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw &= ~(S3C_WINSHMAP_PROTECT(id));
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
dev_dbg(ctrl->dev, "[fb%d] start_addr: 0x%08x, end_addr: 0x%08x\n",
id, start_addr, end_addr);
return 0;
}
Unfortunately for use, this seems to use DMA transfers. The driver sets the start and end addresses for the hardware to automatically transfer the data to the registers representing the GPIO. The only way I can think of to modify this behavior is in this sequence:
1. Create our own "framebuffer" (or double the size of the current framebuffer)
2. Mix colors from the original buffer and write it to ours
3. Repeat every new frame
4. Point the DMA transfer source to our framebuffer instead of the original
Quite a complex process I think... I'm not even sure if its worth the development effort.
nightsky87 said:
Ironically, register definitions don't seem to be in those files. They probably used a different set of defines. What I did find was this in /drivers/video/samsung/s3cfb_fimd6x.c:
Code:
int s3cfb_set_buffer_address(struct s3cfb_global *ctrl, int id)
{
struct fb_fix_screeninfo *fix = &ctrl->fb[id]->fix;
struct fb_var_screeninfo *var = &ctrl->fb[id]->var;
struct s3c_platform_fb *pdata = to_fb_plat(ctrl->dev);
dma_addr_t start_addr = 0, end_addr = 0;
u32 shw;
if (fix->smem_start) {
start_addr = fix->smem_start + (var->xres_virtual *
(var->bits_per_pixel / 8) * var->yoffset);
end_addr = start_addr + fix->line_length * var->yres;
}
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw |= S3C_WINSHMAP_PROTECT(id);
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
writel(start_addr, ctrl->regs + S3C_VIDADDR_START0(id));
writel(end_addr, ctrl->regs + S3C_VIDADDR_END0(id));
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw &= ~(S3C_WINSHMAP_PROTECT(id));
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
dev_dbg(ctrl->dev, "[fb%d] start_addr: 0x%08x, end_addr: 0x%08x\n",
id, start_addr, end_addr);
return 0;
}
Unfortunately for use, this seems to use DMA transfers. The driver sets the start and end addresses for the hardware to automatically transfer the data to the registers representing the GPIO. The only way I can think of to modify this behavior is in this sequence:
1. Create our own "framebuffer" (or double the size of the current framebuffer)
2. Mix colors from the original buffer and write it to ours
3. Repeat every new frame
4. Point the DMA transfer source to our framebuffer instead of the original
Quite a complex process I think... I'm not even sure if its worth the development effort.
Click to expand...
Click to collapse
Well, i need a new challenge
bedalus said:
Well, i need a new challenge
Click to expand...
Click to collapse
Great then! Good luck!!
...just kidding
The way I see it, it might not be that hard after all. The way the code is structured, seems to show that you can just retain most of the fb routines. They mostly describe stuff like offsets, dimensions, and the like. If you copy the ENTIRE framebuffer into another memory location and manipulate that, you won't have to concern yourself with the rest of those functions. Yeah it uses up about 17 MB more of precious RAM (if my calculations are right) but at least you only have to set the DMA addresses instead of recoding a lot of things.
Before anything, can you somehow check which files in the /drivers/gpu/ folder are being used/compiled? I think I may see something useful in those files but I'm not sure if its even relevant.