Related
. . . .
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
. . . . (current version 1.0 FINAL)
More control. More battery. More comfort.
Lumos is fully customizable automatic backlight level changer developed as a complete replacement for stock HTC auto-backlight service. A wide range of HTC branded devices is supported starting from HTC Diamond/Touch Pro up to the current WM flagship HD2.
Lumos focuses on minimal CPU usage, maximum battery saving, low memory footprint while maintaining maximum backlight change smoothness and responsiveness. Lumos combines the best from all available auto-backlight solutions and adds many extras for your tweaking needs
Features:
- simple and clean installation and uninstalation
- extremely low CPU usage when working, 0.05-0.3% on polling
- NO battery and CPU overhead (drainage) unless you actively use your device's display
- low memory profile considering all the options
- simple and reliable configuration GUI with easy step-by-step calibration process
- many options that let you change every aspect of how your backlight works
- program exceptions to set different backlight for any application
- relative excaptions allow you to amplify/attenuate the automatic backlight for specific applications
- ability to force display ALWAYS ON for certain application
- integrated tool to detect all active application names, leave it running in the background and it will log all application names you use
- configuration failsafe. No matter what you do, Lumos won't crash, just tell you what is wrong and use defaults.
- supports vast majority of HTC branded devices since HTC Diamond
- many supported languages
Just install the CAB, start LumosWizard from programs or soft reset and you're all set!
- Lumos always installs to the device (no matter what you chose)
- Installer will create auto-start entry (Lumos will start after a soft-reset)
- Installer will create a shortcut to LumosWizard in your programs
- should any problem arise after first installation, try to soft-reset your device before consulting our FAQ below
Program installs to \Program Files\Lumos\
Lumos.exe = starts/stops auto backlight service, accepts commandline switches
LumosWizard.exe = graphical tool to configure all aspects of Lumos
settings.txt = configuration file is not included in the package, it will be automatically generated by LumosWizard after successful calibration, you can edit it manually in your PC or by using LumosWizard, text edits in device are probably no longer possible because of unicode encoding.
LumosStarter.exe = (re)starts Lumos service without any visual feedback (used for startup after soft-reset and for special issues)
TROUBLESHOOTING:
You can take these simple steps to troubleshoot any problem, perform both steps and if your device reacts differently than described try fixes marked ">" one by one starting from the top. Please restart your device before you start, your problem might fix itself.
1) Run LumosWizard, start Calibration and proceed to second step (max sensor), Lumos should report positive values as you move the device near to light source.
> move the damn finger! xD
> another application exclusively locked the sensor, try to disable other apps using light sensor
> sensor drivers or sensor SDK is missing, try if different application like G-Light works, report the problem if it does, update your ROM if it doesn't
> your sensor may be defective, try some 100% compatible ROM like Energy just in case and consider RMA if unsuccessful
2) Run LumosWizard, start Calibration and proceed to third step (minimum and maximum backlight setting). The backlight should actually change as a preview when you move the slider.
> check if windows built-in auto backlight is disabled in power settings
> another application may be forcing the backlight level, try to soft reset and disable other apps that can change backlight level or manage backlight in user profiles
> original HTC backlight utility DLLs may be missing in certain early WM6.5 ROMs, try to install BacklightHotfix.CAB attached to this post and reboot. If it just won't work, try another program like G-light, if you're still out of luck, try to contact your ROM chef about this.
Click to expand...
Click to collapse
You can send a symbolic DONATION if you with to reward me for my efforts.
Show that you care
There have been over 22500 downloads for RC2 version - just from XDA.
Donations will be used solely to buy muffins and pizza for late-night coding sessions... mmm
READ THE FAQ IN POST #2 BEFORE ASKING QUESTIONS
New files in additional languages pack:
none
DOWNLOAD:
FAQ:
What exactly is the calibration for, backlight is still the same after calibration?
The calibration ensures Lumos can detect the detection range of your light sensor properly and lets you set minimum and maximum possible backlight easily.
It has 4 steps:
1) Minimum value the sensor can read (probably 0 on all devices)
2) Maximum value the sensor can read (expect this to be something around 1400), you need to use a light bulb tor this step.
3) Minimum brightness you want. Lumos will calculate everything with minimum value reported by your device, but it will not let the backlight go below this value. (like if you want to have backlight 2 in shade because 1 is too dark for you)
4) Maximum brightness you want. Lumos will calculate everything with maximum value reported by your device, but it will not let the backlight go above this value. (You may notice that backlight level 7 and 10 is a little difference and can be both read in direct light, however if you limit the maximum to only 7 here, you will save a lot of battery)
5) After you are done with the calibration, you can review your setting on the settings tab and click 'Apply+Save' to exit LumosWizard and actually start Lumos service. There is no auto-backlight while the configuration Wizard is open, it defaults at level 6!
How program exceptions work?
- Switch to the Windows tab and start for example TomTom, leave TT and click it's name in the window list, then specify the backlight you want for this app and tap Add.
- If you disable "Exc. for active window only" on settings tab, you need to specify exact window name and exception will be triggered even for inactive application (minimized for example).
- If you activate "Exc. for active window only" on settings tab, you only need to specify part of the window name in exception settings (useful in case part of the window name changes). If the window name is "AdobeReader - document.pdf", only add exception "AdobeReader -". Be aware enabling this option increases CPU requirements of Lumos by about 20% (means roughly 0.06% total for slow diamonds).
Note that you will probably need to enable "Exc. for active window only" on settings tab for exceptions to work on WM6.5.
How to set a program exception step by step?
1. run lumos wizard
2. switch to the tab "windows" (the last one) and let the wizard run in background
3. run your program(s) you want to add
4. close the program(s)
5. switch back to lumos wizard -- voila, all the window names you visited are there!
6. tap the program name you want in the window list, it will switch you to the "exceptions" tab and fill the form for you
7. set the backlight level you want (1-10) and tap add to exceptions
What is a Relative Exception?
- relative exception does not force one specific level but rather amplifies and attenuates normal auto-backlight behaviour for the application in question.
Consider this scenario:
Code:
- my allowed backlight ranges in levels 2-7
- I want to use a navigation app in car and it is kind of difficult to see on sunlight, shades in car would read for level 3 or 4 and that is not bright enough
- I can either create an exception and force backlight all the way to 7, but that might not be optimal on battery
- therefore I create a Relative Exception of +2
- for the navigation application if the backlight would normally be set to 3 by Lumos, it will be amplified by two to 5. What would normally be level 6 will get amplified to 7, since that is my maximum level.
- You can also use negative values in Relative Exception to decrease the backlight for certain app by certain amount to save battery for example.
How backlight modes work?
- Backlight modes are individual equations used to determine proper backlight level from current sensor value.
- Linear - this mode is equally sensitive in dark and light environment.
- Root - this mode is more sensitive in dark environment and is best suitable for human eye and therefore default.
- Quadratic - this mode is more sensitive in light environment.
- Custom - this mode features customizable graph, you can draw a graph yourself with stylus or click on the blue area under each level number to input border sensor value manually.
Levels outside your min-max boundaries are hidden.
- Note that using custom mode do not affect CPU requirements in any way.
Commandline switches?
- There are 4 switches that can be used
"+" will increase backlight by one
"-" will decrease backlight by one
"s" will run normal Lumos operation without restart prompt after +/- tasks are completed
"q" will quit Lumos after +/- tasks are completed
Example to increase backlight by 3 and disable automatic:
Code:
"...iles/Lumos.exe" +++q
My *insert a game using G-sensor* is lagging strangely, can I fix it?
- guys from HTC thought it would be a cool idea to tie all sensors together in a framework, unfortunatelly it appears that when one program locks a sensor for read, other sensors may get locked as well on some devices. There is only one solution that will de-lag such game - not to use the sensor while it runs.
- Create a non-relative exception for the game in question and your lag should go away.
Backlight is not changing at all, it's the same all the time?
1) go to Start - Settings - System tab - Power - Backlight tab and DISABLE the 'Auto adjust backlight' feature.
2) close the configuration Wizard with "Save+Apply" button, auto-backlight service is disabled when you are configuring Lumos or when there is no configuration specified.
Program won't start at all?
You NEED .NET 3.5 Compact Framework Redistributable. It is faster and more stable and offers more stuff for developers than the 2.0 you probably have. It is rumored it may even make your device work faster (or at least .NET based apps).
Download it HERE (only about 3MB on device, don't be scared by the installer size as it contains support for more processors)
LUMOS CHANGES TRACKER:
(changes prior to RC1 version dropped)
! non linear backlight in the GLight style for people all over the net who are demanding this
! exceptions now need only part of the window name in "detect only active windows" mode
! recalibrated sensor readings for more sensitivity
! fixed bug in custom graph mode
! faster loading
! dropped DIM_TO_MINIMUM_PLUS_ONE_BELOW option
(below only in RC2 version)
! fixed custom mode alignment
(below in 1.0 Final)
! add support for relative level in exceptions
! add support to keep alive only as exception
! add command line support (change level & quit, +, -)
(below ideas for future development)
- add support for alternative backlight handling (WM default without HTC drivers)
WIZARD CHANGES TRACKER:
(changes prior to RC1 version dropped)
! support for setting linear, quadratic and root/logaritmic backlight
! support for custom backlight mode with interactive graph
! support for changing keyboard backlight delay on RAPH
! improved max/min detection in wizard
! forcing consistency between settings and graph plotting
! switching language in flight
! faster loading times
! support for language packs
! smaller text to allow better translations
! bigger tabs for better finger friendliness
! dropped DIM_TO_MINIMUM_PLUS_ONE_BELOW option
! fixed minor flaws from beta2 connected with translations
! improved settings tab scrolling redraw speed
! settings tab will back off from deploying soft keyboard
! added new languages: Bulgarian, Czech, Francais, Japanese, Nederlands
(below only in RC2 version)
! fixed Window detector taking you to the Mode tab instead of Exceptions
! fixed settings tab layout width
! added another failsafe mechanism against saving invalid min/max backlight and polling interval
! added warning message for options with potentially negative effect on battery
! added new languages - currently Bulgarian, Czech, French, German, Greek, Japanese, Dutch, Polish, Russian, Sim./Trad. Chinese
(below in 1.0 Final)
! set "BL=1 below" option to be relative to the sensor minimum
! set calibration to disregard sensor minimum 0 until the driver is initialized
! add support to release sensors on active exception
! add wizard warning if built-in auto backlight currently overrides Lumos control
! ability to recognize missing sensor drivers and the need for Backlight Hotfix package
! add support for relative level in exceptions
! add support to keep alive only as exception
(below ideas for future development)
- support for forced "on wakeup" backlight level
- = bug / missing part
? = possible bug/not able to reproduce/not verified/idea
* = in development
+ = fixed bug / completed part
! = fix/feature included in released version
NOTES:
Please disregard the hacks from previous versions and always set your sensor minimum and maximum to real values (0-xxxx)! Some sensors might have different minimum than 0 - this is a hardware defect and you need to use the defected value for Lumos to work correctly.
To admit it, I haven't installed it yet, but I'm tempted. Just one question which might also be of interest for others:
What's the advantage of your app compared with G-Light?
And not to forget:
Thank you for your work! I still find it amazing that many xda-devs are building programs for free just for a "thank you" by the community.
Well I tried G-Light and LevelSight but will only compare it to G-Light as LevelSight does things a bit differently IMO. I set G light to 3s polling interval to make the comparsion accurate. I don't like to put dirt on someone elses app, G-Light is a fine piece of software and I encourage the developer to implement some of my ideas to match mine and make it even better
- G-Light can behave competely unpredictably, it pumps up the backlight when you're in shade (this is because of the luminosity spikes)
- Lumos eliminates any spikes by the 4-read interpolation keeping your backlight more comfortable and smooth
- Lumos uses a tolerance which further prevents the backlight to unexpectedly changing (and causing a CPU spike)
-G-light rarely reaches below 1% of CPU usage (1-7%usage is common) which can drain your battery as a side effect
- Lumos rarely crosses above 0.5% CPU usage on default settings (0.05-3% usage is common) (NOTE: this will even improve in future versions)
- in G-Light You cannot change how fast the luminance values are read from sensors, they are read on change = further battery drain. You can only change how often to set backlight
- In Lumos you can set sensor read interval and backlight change in its multiplies to save CPU and power while retaining smoothness.
- Memory usage: GLightRunner 595.43KB , Lumos 311.53KB (but this will get a bit more later)
- No noticable memory leak in either applicaiton
- G-Light has a frontend app to set up
- Lumos has none yet but you can change the configuration file
- Neither Lumos nor GLightRunner can be completely shut down without using task manager (Lumos will once it has frontend GUI).
- G-Light can exclude applications
- Lumos can't yet
-G-Light settings is pretty much still limited compared to Lumos
To sum up it's definitely worth trying
nik3r said:
To sum up it's definitely worth trying
Click to expand...
Click to collapse
Thank you for your long and precise answer, You definitely convinced me!
I'll try it right away!
Lumos v02
Lumos Version 02 has been released, all the changes are logged as (!) in the bug tracker above.
Default settings response time is shorten to 2s, while CPU usage is pretty much the same as v01 with 3s refresh.
Memory usage: 339.53KB
CPU usage: 0.05-0.25% on scan, 3.15% on backlight change
Power consumption is 2mA better than v01
If you want to achieve more sensitivity of backlight transition without CPU overhead, set tolerance to 0 (CPU usage bug is fixed now).
Configuration file is now idiot-proof, program will tell you what is wrong on syntax/logical error
EDIT: 02b contains one more bugfix, the auto backlight range cap finally works 100%
Enjoy
nik3r
Quick question; does you app let the backlight go to 0% in full darkness, like LevelSight?
Yes it in fact goes to 1 (backlight disable) as lowest on default. You may want to increase it to 2 in the config file if it's too dark for you.
The point of this app is YOU set how it should behave, there are virtually no limitations unless you enter a complete nonsense to the config. And even then the program should just notify you about the incorrect settings and not crash, so don't worry and edit!
The program needs to be restarted in order to apply new settings. Either kill it via process/task manager or soft reset if you don't have one. Note that this acts like a program, it won't start again automatically if you kill it or soft reset. And also it won't store anything in your registry or enywhere else on the device, so it's perfectly safe to "just try". I will make a manager app later that will let you setup and control this underlying process.
But FIRST we need to make sure the service is bug free and does everything we need before I even start building the front-end app
Also you may share your custom settings you find best with me and if it's performing well I can select that one as default for future.
Thank you Niker! V2 is working great for me. Only one thing:
The lightlevel changes linear as you've explained and that's basically working fine (and much more smoothly than G-Light for example). But it tends to get to dark. I've now changed the minimum setting to "3" to get the average backlight-level I prefer. BUT: I like to read late at night in bed and it would than be nice to have the backlight at level "1". So would it be possible to exclude light level 1 & 2 from the linear alignment and to only use those levels if it's "really dark"?
PS
Just to give you a bit more information about my personal preferences and what I want to achieve:
I actually like the default HTC auto-backlight. It more tends to bright than to dark backlight and it's making the level changes very smoothly so you almost don't notice them.
The only thing i don't like about it is that the minimum level is hardcoded to level 3 which is too bright for me when I read in bed with no additional light in the room.
Of course those are my personal preferences and that of course doesn't necessarily mean that your app is meant to handle that way!
Well I have an idea, I wonder if .NET CF 3.5 supports external scripting as the PC version does. Basically that might allow you to replace the backlight algoritm without compiling the program yourself. You could quite easily make exceptions binded to really low lumen values or time of day with just 2-3 lines of code.
EDIT: I fear this is not possible, System.CodeDom.Compiler is awfully stripped down, I would have to make up my own scripting language for this to work and that would be very difficult.
But I think I can add this as a setting to the configuration file.
DIM_TO_MINIMUM_BELOW = 0
- disabled (default)
DIM_TO_MINIMUM_BELOW = 25
- below 25/750 lumens
very simple and I think this would do about what you want
Expect this in the new version.
nik3r said:
I'll report back whether this is possible in mobile version...
Click to expand...
Click to collapse
Thank you mate, I really appreciate it!
Thanks for your suggestions.
Lumos v02c is out, it contains your 2 desired options (for backlight 1 and 2 separately). You will however be disappointed by the sensitivity of raphael sensor, it reports 0 like all the time.
This change theoretically lets you set lumen values for the 2 lowest values manually and once the sensor reads larger values, the MIN/MAX_BACKLIGHT kicks in. It's possible to have 4-8 auto and dim to 1 or 2 on low light, so you can kinda simulate the behaviour of LevelSight if you want to.
Oh and as the cherry on top I disabled tolerance by default, for more smoothness, the impact on CPU and battery should be minimal < 0.05%
The next version should include a tool to easily restart Lumos to apply settings, it will be needed for the graphical user interface later.
Enjoy
Major version released:
Lumos v03
- all bugs connected with dynamic backlight should be fixed now
- changing settings.txt is even safer (program should never crash, just tell you where is problem and use defaults)
- includes LumosKiller.exe that can start/restart/shutdown Lumos easily
In case no bugs are found until friday, I will start building GUI.
Could you integrate special brightness normally only used when starting the camera? You'd probably need to debug the camera application to find out about the special ICOTLs for that. I did that with my Magician back in the days.
Program-specific exceptions will be added after the GUI is done, I still need to figure out how to list running windows by name. If you have any experience with this using C# or C++ I'd be happy if you PM me, but I guess uncle google knows how to do this, just refuses to share it with me right now
Uz to testujem, zatial to vali krasne a v pohode ;-)
I just wrote that I'm currently testing it, no problems so far.
Thank you and please keep up the good work ;-)
Great application Nik3r!!
i like so much, because don´t touch my registry, It´s light,and also have minimal resources consumption
But, i need your help with the configuration file,
i have htc diamond, and the battery of this device drain fast
how can set the settings to obtain best battery duration?
Thanks a lot!!
You can increase the polling interval, enable some tolerance and lower the maximum brightness.
Try to make these changes:
MIN_BACKLIGHT = 1
MAX_BACKLIGHT = 6
POLLING_INTERVAL = 1500
EXTRA_POLLS_BEFORE_SET = 1
BACKLIGHT_TOLERANCE = 1
set minimum backlight to whatever is reasonably visible in shade
.. this will set your polling interval to 1,5s and make your brightness change every 3s instead of 2. The tolerance prevents brightness changess less than 2 units. It's the brightness change that eats most CPU (up to 3% spike) and thus battery and the tolerance makes sure it's not changing until a larger change is required.
And make sure you killed the old v01/02x version or soft reset before using 03 because older versions can't be killed by LumosKiller and two of them running may ruin your battery.
... hmm by the way I wonder why I didn't call it "Nox" instead of LumosKiller (any similarity with HP books is completely unintentional )
Good luck
Thanks for your quick and detailed reply!! i did those changes you suggest,
I´m really fan of your app!!
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.
Hey guys,
well known topic, but I'm still left with questions.
I go with ARHD and Sense (Android 4.3 and Sense 5.5 atm, 4.4 KK might be soon) and the minimum volume levels are too loud IMHO (regarding my taste), therefore I want to readjust them or have to increase the number of volume steps as this also redefines the array and the fraction of each step.
I use ZeroInfinity's PureXAudio (now ProjectEra) if that counts. Also Xposed framework.
I'm aware of Volume steps mod (HTC One) and I checked {Mod & Tuto} 30/45 Steps Volume Project (framework.jar), so I might do editing hex-values soon.
1. can I readjust the volume levels to my needs somewhere, if this is the simpler way: step x [1-15] - level y [0-1] (e.g.) ?
2. does changing the number of steps definitly means changing framework.jar? best file, best approach. If so I will go for it..
3. does sth. has to be taken into account, sth. changed with 4.3 or KK 4.4, or Sense 5.5,.. someone told about the master-volume with 4.2.2 (http://forum.xda-developers.com/showpost.php?p=47668094&postcount=310)?
Thanks for helping !
edit: details
Volume step mods are completely broken in 4.3 and onwards. Jonny has already explained everything you need to know, the master volume is locked at 15 steps of volume, no more no less. Whilst you CAN get 30 steps, you'll only have 15 volume changes meaning the volume will simply go up like this
1-1-2-2-3-3-4-4-5-5-6-6-7-7-8-8-9-9-10-10-11-11-12-12-13-13-14-14-15-15
30 Steps, only 15 volume changes. A shame really
Thx Galactus.
Hmmm, if the known mod is resulting in 15 levels at the end there must be some different, maybe additional place (lines in the code, file,..) where to modify an array, a number, levels,..
We have to find the hole where to put the dynamite..
xfish said:
Thx Galactus.
Hmmm, if the known mod is resulting in 15 levels at the end there must be some different, maybe additional place (lines in the code, file,..) where to modify an array, a number, levels,..
We have to find the hole where to put the dynamite..
Click to expand...
Click to collapse
Indeed we do lol, but I am not skilled in that area and I have no idea if any devs can, or will attempt to fix it
http://forum.xda-developers.com/showthread.php?t=2565559
Hello, some one please guide me so i can reduce the min brightness in lollipop, even the lowest is too bright and hurts my eyes at night,
I want to change settings in the rom and dont want to use apps
Take a look at this thread: http://forum.xda-developers.com/showthread.php?t=2893061 is for KK but I think is almost the same for LP
DorianX said:
Take a look at this thread: http://forum.xda-developers.com/showthread.php?t=2893061 is for KK but I think is almost the same for LP
Click to expand...
Click to collapse
Thabks, i tried it already and searched all what i could get from google, still nothing works and most mods need custum kernel or patching service jar which is a bit of a head ache of steps
If i could mod build prop or a sys file
My other phones where already dim at low or i could mod their brightness throu build prop or lcd min value but none is possible on this phone
Gamer4Life said:
Hello, some one please guide me so i can reduce the min brightness in lollipop, even the lowest is too bright and hurts my eyes at night,
I want to change settings in the rom and dont want to use apps
Click to expand...
Click to collapse
#!/system/bin/sh
#night mode
echo 1 > /sys/class/leds/wled:backlight/max_current
Can be used as script or via terminal emulator
If you need more brightness change value after echo
My value>
1 for lowest
3 for normal
25 for max
Yenkazu said:
#!/system/bin/sh
#night mode
echo 1 > /sys/class/leds/wled:backlight/max_current
Can be used as script or via terminal emulator
If you need more brightness change value after echo
My value>
1 for lowest
3 for normal
25 for max
Click to expand...
Click to collapse
Explain little more please?
Okay, fir now i lowered the max current, now the display is really nice and dim how just how i like it
But max brightness is very low now, only if i could only changr thr min value
You can use apktool to decompile framework-res.apk and change the lcd backlight related numbers in /res/values/ files. The lowest setting that I can still see my screen was 2. The lowest manual setting changes but the adaptive brightness doesn't go to the new minimum. But sometimes the framework-res.apk doesn't rebuild properly and you need to restore with recovery and ADB.
Gamer4Life said:
Okay, fir now i lowered the max current, now the display is really nice and dim how just how i like it
But max brightness is very low now, only if i could only changr thr min value
Click to expand...
Click to collapse
Just change value to 25
But you need change this value every time each reboot.
Not a permanent, but a handy solution :3
For me, I made 3 script as widget (in small app), so I can change brightness value as I like.
Yenkazu said:
Just change value to 25
But you need change this value every time each reboot.
Not a permanent, but a handy solution :3
For me, I made 3 script as widget (in small app), so I can change brightness value as I like.
Click to expand...
Click to collapse
I will be grateful if you share with us how to make these shortcuts in small app menu.
Also which setting do you use for night?
For me i tried 3 and i like it. My eyes are very sensitive to light and will make them dry and bit sore
I am experiencing low sound in calls after latest update 4.0.3 . Any fixes available ?
Guys after looking into some threads , i got something useful . my call volume is fixed .
Download BuildProp Editor by JRummy on the Google Play Store and open it up. Tap on the “pencil” icon in the top right to bring up the manual editing mode. Scroll all the way to the bottom and add either of the build.prop lines mentioned above and set it equal to the number of volume steps you want to have. For example, entering these two commands at the end will double the number of in-call volume steps and media volume steps respectively.
ro.config.vc_call_vol_steps=14
ro.config.media_vol_steps=30
Once you’ve entered these commands, reboot your phone. If it worked, you should now have as many volume steps as you specified in build.prop.
Vaibhunk786 said:
Guys after looking into some threads , i got something useful . my call volume is fixed .
Download BuildProp Editor by JRummy on the Google Play Store and open it up. Tap on the “pencil” icon in the top right to bring up the manual editing mode. Scroll all the way to the bottom and add either of the build.prop lines mentioned above and set it equal to the number of volume steps you want to have. For example, entering these two commands at the end will double the number of in-call volume steps and media volume steps respectively.
ro.config.vc_call_vol_steps=14
ro.config.media_vol_steps=30
Once you’ve entered these commands, reboot your phone. If it worked, you should now have as many volume steps as you specified in build.prop.
Click to expand...
Click to collapse
Thanks for this post. I suffered from annoying low in call volume on my previous device so know how irritating it can be, especially when making calls in busy areas, like a road with heavy traffic. I've only had this device for a few days and since getting it have been away in an area where there is next to no mobile signal so I have not taken or received any calls.
Question
What you have written would seem to suggest that the prop changes would increase the number of volume steps that are applicable for each volume type, but, does does this really alter the actual maximum volume setting? if not then I can't see that this is a fix.
ben_pyett said:
Thanks for this post. I suffered from annoying low in call volume on my previous device so know how irritating it can be, especially when making calls in busy areas, like a road with heavy traffic. I've only had this device for a few days and since getting it have been away in an area where there is next to no mobile signal so I have not taken or received any calls.
Question
What you have written would seem to suggest that the prop changes would increase the number of volume steps that are applicable for each volume type, but, does does this really alter the actual maximum volume setting? if not then I can't see that this is a fix.
Click to expand...
Click to collapse
The code is like this
// Initialize volume
int maxVolume = SystemProperties.getInt("ro.config.vc_call_vol_steps",
MAX_STREAM_VOLUME[AudioSystem.STREAM_VOICE_CALL]);
if (maxVolume != MAX_STREAM_VOLUME[AudioSystem.STREAM_VOICE_CALL]) {
MAX_STREAM_VOLUME[AudioSystem.STREAM_VOICE_CALL] = maxVolume;
AudioSystem.DEFAULT_STREAM_VOLUME[AudioSystem.STREAM_VOICE_CALL] = (maxVolume * 3) / 4;
}
maxVolume = SystemProperties.getInt("ro.config.media_vol_steps",
MAX_STREAM_VOLUME[AudioSystem.STREAM_MUSIC]);
if (maxVolume != MAX_STREAM_VOLUME[AudioSystem.STREAM_MUSIC]) {
MAX_STREAM_VOLUME[AudioSystem.STREAM_MUSIC] = maxVolume;
AudioSystem.DEFAULT_STREAM_VOLUME[AudioSystem.STREAM_MUSIC] = (maxVolume * 3) / 4;
}
i think it alters the max volume but i am not sure but my low call volume is definitely fixed . I just added the lines which i mentioned above.
Testing on my Mi A1, now I have to wait to receive a call. (*Insert a Forever Alone Meme)
EDIT: It changes the number of incremental steps, but the maximum volume remains the same.
Does this fix work on latest OxygenOS betas? There was a TWRP flashable zip before but not sure if it works still.
just clean the speaker grill.
Already cleant the speaker grill. Need the volume to be boosted
volume fix
TheQuarterMile said:
Already cleant the speaker grill. Need the volume to be boosted
Click to expand...
Click to collapse
Flashable zip worked on nugatt but not work in oreo since tasha mixer files are in different localization, you need to manual change values in tasha_miser_paths.xml in system/vendor/etc root folder.
I can send you my edited file.
Deleted by Moderator.
magisk module named "low in call volume fix oneplus 3/3t for RR" not sure if the name is exactly the same but just type "low in" and the module should show up. Tho its for RR i use it on beta 25 and the issue is fixed ! :good:
Increasing the volume steps in root\System\build.prop didn't change the output volume for me.
I solve this issue by modifying a single parameter in "root"\system\vendor\etc\mixer_paths_mtp.xml
(https://forum.xda-developers.com/mi-a1/how-to/how-to-modify-ear-speaker-volume-mi-a1-t3779866)
Best regards.
Fixed it by editing the RX0-RX8 Digital Volume values from 84 to 94 in mixer_paths_tasha.xml file found in /vendor/etc folder and it works! Now I keep the call volume 1-2 levels lower than full. Tried it on OxygenOS beta 24. Thanks for the help everyone.