Possible Fix For Touchscreen Issues/Misses (Updated 08/29) - G4 General

SEE UPDATE BELOW
After doing some more digging on surfaceflinger, atd, and their related libs, I found some interesting entries in a "strings" analysis of libinputflinger.so. Loads of stuff on touch calibration. I noticed some repeated strings that looked like they're assigned to different properties. You can see this clearly by entering:
Code:
strings /system/lib/libinputflinger.so | grep -iE '(^touch\.|[ ][ ]touch\.)'| sed -e 's/^[ \t]*//' | sort -n | uniq
The terminal returns
Code:
touch.coverage.calibration
touch.coverage.calibration: box
touch.coverage.calibration: none
touch.deviceType
touch.distance.calibration
touch.distance.calibration: none
touch.distance.calibration: scaled
touch.distance.scale
touch.distance.scale: %0.3f
touch.gestureMode
touch.orientation.calibration
touch.orientation.calibration: interpolated
touch.orientation.calibration: none
touch.orientation.calibration: vector
touch.orientationAware
touch.pressure.calibration
touch.pressure.calibration: amplitude
touch.pressure.calibration: none
touch.pressure.calibration: physical
touch.pressure.scale
touch.pressure.scale: %0.3f
touch.size.bias
touch.size.bias: %0.3f
touch.size.calibration
touch.size.calibration: area
touch.size.calibration: box
touch.size.calibration: diameter
touch.size.calibration: geometric
touch.size.calibration: none
touch.size.isSummed
touch.size.isSummed: %s
touch.size.scale
touch.size.scale: %0.3f
touch.wake
I looked up some of strings on the net, and lo and behold, they're build.prop entries! You can see the props above that have different strings to assign to them. The ones with a "%0.3f" refer to a number value, and the one with "%s" is a boolean 0/1.
I've only done a little testing, but I found a baseline of improvement values to make our touch screens more responsive. Some of the properties I couldn't find info on, so I'm testing some values like touch.distance.scale. I feel like I have definitely noticed improvements though. I'm no longer so pissed off using my phone, and the frequency of misses overall seems significantly lower. It's acceptable now. Here's what I'm using now at the end of my build.prop:
Code:
##### touch ######
touch.deviceType=touchScreen
# (geometric, diameter, box, area)
touch.size.calibration=geometric
touch.size.scale=100
# (amplitude, physical, none)
touch.pressure.calibration=amplitude
touch.pressure.scale=0.1
touch.gestureMode=pointer
# (interpolated, vector, none)
touch.orientation.calibration=interpolated
# (box, none)
touch.coverage.calibration=box
For detailed information on these touch properties, read here(search for the property you're interested in; the page is pretty long). Some are self-explanatory and others we'll just need to test more. Check them out and see if any calibration values make a significant change. Just copy the above code and paste to the bottom of /system/build.prop with a nice file manager like Solid Explorer. Warning: Adding these entries in the build.prop will change the default touch properties. You can always change them back to stock by removing or commenting the entries from build.prop. I assume most values are aafe, but I can't be sure.
Also worth noting. I found some additional build.prop values to make Android snappier. The fling/swipe velocity make a big difference. Not sure what the others correlate to.
Code:
##### touch related #####
view.touch_slop=2
view.scroll_friction=1.5
view.minimum_fling_velocity=25
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.min_pointer_dur=8
windowsmgr.max_events_per_sec=200
EDIT: For detailed information on these touch properties, read here.
I'm gonna add some "profiles" of touch settings to use down here.
This one is for a Nexus 4 I believe. I'm trying it out now, and it seems pretty good. My goal is to emulate the touch experience I had with that phone.
Code:
##### touch ######
touch.deviceType=touchScreen
touch.orientationAware=1
# (geometric, diameter, box, area)
touch.size.calibration=diameter
touch.size.scale=10
touch.size.bias=0
touch.size.isSummed=0
# (amplitude, physical, none)
touch.pressure.calibration=amplitude
touch.pressure.scale=0.005
touch.gestureMode=pointer
# (interpolated, vector, none)
touch.orientation.calibration=none
UPDATE
Hey guys, so here's an update to what I've found out about the touch screen and its issues. I apologize for my low activity on xda. I've been real busy working on some linux projects.
First, in order for the touch.* settings to work, they need to be put in an .idc (input device configuration) file with the name of the device. For the G4, that is: /system/usr/idc/touch_dev.idc.
If you have another phone or want to check, you can get the name of your touch screen device with the terminal command:
Code:
for i in /dev/input/event*; do j="$(getevent -i $i | grep -i touch)"; j=${j#*name: }; [[ -z $j ]] || echo ${j//\"/}; done
Before you go try out the .idc file, I want to warn you that certain settings will disable the touch screen. If this happens, you'll need to use adb to delete or move /system/usr/idc/touch_dev.idc somewhere else so that it doesn't get loaded when the phone boots. These are some settings you must NOT change in the .idc file:
Code:
touch.deviceType = touchScreen
touch.coverage.calibration = box
These are the settings I'm currently using:
Code:
touch.deviceType = touchScreen
touch.orientationAware = 1
touch.size.calibration = diameter
touch.size.scale = 1
touch.size.bias = 0
touch.size.isSummed = 0
touch.pressure.calibration = physical
touch.pressure.scale = 0.001
touch.orientation.calibration = none
touch.distance.calibration = none
touch.distance.scale = 0
touch.coverage.calibration = box
touch.gestureMode = spots
MultitouchSettleInterval = 1ms
MultitouchMinDistance = 1px
TapInterval = 1ms
TapSlop = 1px
I'm not sure if the Multitouch* and Tap* settings work or if adding more values from libinputflinger will work. There's little documentation on using settings that don't begin with "touch." You might have to do some experimentation and try other entries in the "strings /system/lib/libinputflinger.so" readout. I would also try using the first settings I posted if these don't seem to help.
Another thing I found out is that this phone performs better with low entropy. You can monitor your current entropy level in the terminal:
Code:
watch "cat /proc/sys/kernel/random/entropy_avail"
It's usually around 2000+ and peaks at 4096 with high activity which is where I think lag comes in. I found that lowering it to under 1000 average cut out the lag spikes I was getting:
Code:
echo 16 > /proc/sys/kernel/random/read_wakeup_threshold
echo 16 > /proc/sys/kernel/random/write_wakeup_threshold
I went ahead and added that to an init.d script. This doesn't have any side effects I've noticed besides possible increased battery life, since the "hwrng" process that generates entropy has no work to do. In case you don't have init.d, make sure busybox is installed, run this command in the terminal, and you'll have init.d startup:
Code:
mount -o remount,rw /system; echo "sleep 300 && run-parts /system/etc/init.d" >> /system/etc/init.qcom.post_boot.sh; mount -o remount,ro /system
One last thing to mention. The touch device has a little section in sysfs under: /sys/devices/virtual/input/lge_touch. There's some interesting information you can find there, values you can change, and tests you can run. Any file with a name ending in "test" can be run by opening the file, yes sysfs files are weird like this. All tests pass for me except "abs_test":
Code:
cat /sys/devices/virtual/input/lge_touch/abs_test
> ========RESULT=======
> Absolute Sensing Short Test : RESULT: Fail
> Absolute Sensing Open Test : RESULT: Fail
I haven't seen other people with or without touch screen issues run this test, so it may or may not be an indicator that something's wrong with the touch screen or its kernel-side drivers. By the way, this doesn't require superuser. You can check this on any device and even use a good text editor like QuickEdit to open the file and generate test results.
At this point, I'm fairly content with the new improvements I've made, but my best bet on a complete fix would be upgraded touch drivers. The "Advanced In-Cell Touch" device this phone uses is pretty new. There's a good chance this technology has drivers that don't have all the bugs worked out. This is something we'll have to wait on. On the other hand, if LGE handed over a bootloader unlock method and some source files, I'd be just fine with that too.

What "issues" is this attempting to fix

kyle1867 said:
What "issues" is this attempting to fix
Click to expand...
Click to collapse
Probably the horrible touch response many users experience.

Is this something that we can copy and paste into the end of the build prop, or is it replacing stuff that is already there?
Sent from my LG-H811 using XDA Free mobile app

Wow nice job man.
Is it possible to address the swipe registering as taps through this or do you think this will also address it?

Harmtan2 said:
Is this something that we can copy and paste into the end of the build prop, or is it replacing stuff that is already there?
Sent from my LG-H811 using XDA Free mobile app
Click to expand...
Click to collapse
You'll have to add almost all of them.

Yes bro am too facing the touch problem in my intex aqua star power. The problem is when we keep the finger the screen shakes and also in 100% of my usage 20% touch mismatches . On first i irritated and now i habituated with this touch. [emoji28]
Sent from my Aqua Star Power using Tapatalk

The build.prop edits seem to be making the difference. ?
Sent From My LG G4

Rydah805 said:
The build.prop edits seem to be making the difference. ?
Sent From My LG G4
Click to expand...
Click to collapse
would you say that double tap to wake is improved as well?

esmenikmatixx said:
would you say that double tap to wake is improved as well?
Click to expand...
Click to collapse
Hmm, you know what, it is.
Sent From My LG G4

esmenikmatixx said:
would you say that double tap to wake is improved as well?
Click to expand...
Click to collapse
I would say so I have all these except the new ones he posted an an script from another post an I do see some improvements defiantly double tap to wake

GUGUITOMTG4 said:
You'll have to add almost all of them.
Click to expand...
Click to collapse
Soooo... can you run through this with me? I'm not a novice but I'm trying to figure out how to add them? I can't simply text edit the build.prop on my phone or pull/push from my computer?

This post is the reason why I'm glad we now have root.

Akomack said:
Soooo... can you run through this with me? I'm not a novice but I'm trying to figure out how to add them? I can't simply text edit the build.prop on my phone or pull/push from my computer?
Click to expand...
Click to collapse
Yes, you can manually edit it and or push pull it, but sometimes it causes bootloop when edited as a plain text. I would suggest using a build prop editor app from Play Store (I use Build Prop Editor by JRummy. It's Also built in in Rom Toolbox). You will have to copy-paste line by line. I'm gonna try those settings, but in my case, my screen sometimes misses when the phone gets hot. I attribute my touchscreen issues to the Lag LG injected on thermal files.

GUGUITOMTG4 said:
Yes, you can manually edit it and or push pull it, but sometimes it causes bootloop when edited as a plain text. I would suggest using a build prop editor app from Play Store (I use Build Prop Editor by JRummy. It's Also built in in Rom Toolbox). You will have to copy-paste line by line. I'm gonna try those settings, but in my case, my screen sometimes misses when the phone gets hot. I attribute my touchscreen issues to the Lag LG injected on thermal files.
Click to expand...
Click to collapse
Do you have to be rooted to do that?

Hendrycks said:
Do you have to be rooted to do that?
Click to expand...
Click to collapse
Yes you do
Sent from my LG-H811 using Tapatalk

Hi,
yesterday I bought a G4 H815.
I have the following problem: If my phone is on the bed next to me, or lying on a table, the touchscreen response is terrible. If I'm holding it in my hand, there's no problem. If it's charging and so lying on the bed, there's no problem either.
I took a few photos with my Optimus Black, since I could't take any screenshots of the issue:
this is with my phone lying on the bed:
and here holding it in my hands, producing no problems at all.
what is this? It's bloody annonying and totally unacceptable from a phone of this level, And yes... I would use it without holding it, just placing it on my bed next to me, but you can see how it is performing like so...
is my display faulty, or what?

Thanks man.
It's indeed more responsive. Especially double tap to wake is working good now.

*justintime* said:
Thanks man.
It's indeed more responsive. Especially double tap to wake is working good now.
Click to expand...
Click to collapse
I didnt feel a difference can you post a screenshot of your buildprop? Thanks in advance
Maybe im doing it wrong
Sent from my LG-H811 using Tapatalk

Just edit with es file Explorer.
And get the build.prop in the system folder. Not the other one.
{
"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"
}

Related

[CM7]KANG discussion

This is the place where you can post and talk about your own personal cm7 builds, aka KANGS, experimental ideas and such.
PURPOSE: keeping the main CM7 thread clean.
THIS
Subscribed although I can't build myself. This matter is too interesting not to follow. I think bk201 his posts are the ones that I pay most attention to and I hope he will not be discouraged by this 'ban' but will keep us informed here.
Taptalked u see
Taptalked u see
Zatta said:
Subscribed although I can't build myself. This matter is too interesting not to follow. I think bk201 his posts are the ones that I pay most attention to and I hope he will not be discouraged by this 'ban' but will keep us informed here.
Taptalked u see
Taptalked u see
Click to expand...
Click to collapse
yep, love those posts too
Zatta said:
Subscribed although I can't build myself. This matter is too interesting not to follow. I think bk201 his posts are the ones that I pay most attention to and I hope he will not be discouraged by this 'ban' but will keep us informed here.
Taptalked u see
Taptalked u see
Click to expand...
Click to collapse
Setting up a build environment isn't that hard. If you need help, please let me know.
siky_dude said:
This is the place where to talk about your own personal cm7 builds, aka KANGS.
PURPOSE: keeping the main CM7 thread clean.
THIS
Click to expand...
Click to collapse
sorry for all the trouble.
currently testing:
I426982b3, I16a40854, Idb544452
feedback: have to test this some more, but didn't work when i tried the first time. there could be a popup informing user that bootanim was imported sucessfully or not, also fps rate dropped quite a bit after 1 or 2 seconds previewing chosen bootanim. that worked, but when i rebooted bootanim was still the default. don't know if i did something wrong though.
If0476af0, If5485caf
feedback: no errors on output, but icon on statusbar doesn't show. profiles feature keeps working fine, with this on or off.
Idf1cb09f, I89bdbc11
feedback: working flawlessly. 3 or 4 seconds less on boot process.
I52fcd648
feedback: downloaded Third Blade from market (~49mb), no issues downloading or installing. internal/external sdcard unaffected. no more need for this maybe?
I4427e3f2
feedback: working without issues; from what i understand this a function that gets string lenght (for example from a user input, not so sure here); any way to get a more technical comparison? a math test to cpu perhaps?
I92569aa2
feedback: also working, and solved original issue.
Ic0b39c23
feedback: no compile errors, no issues until now, seamless.
Id3e68a75, I2e365a33
feedback: working; does what's described. will test further for conflict with HSPA setting introduced by pawitp.
{
"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"
}
I461e90ac, I70d846ab, I76632c87
feedback: working; need more time to check for improvements on battery runtime.
Very good work. Have you been commenting on gerrit also? That would useful for the peer reviewers.
jose.celestino said:
Very good work. Have you been commenting on gerrit also? That would useful for the peer reviewers.
Click to expand...
Click to collapse
I haven't, the devs said i shouldn't if i didn't have anything to contribute.
more in testing
I5cb28b08
feedback: no issues to report, seamless
Ic395fae3
feedback: fixes skewed preview on camera when launching it from lockscreen custom app starter, with auto-rotation/90º active.
I985c4573
feedback: looks good, seamless on the end user i guess
I923fa5aa
feedback: still working fine, that nice terminal
just saw this, will test later:
I7ccd5e2c
Jens1969 said:
Setting up a build environment isn't that hard. If you need help, please let me know.
Click to expand...
Click to collapse
Do you think we should get a little bit more constructive/extensive (based on the wiki, sure) on build tips? setting up the buildenv isn't hard at all (just bandwith/time consuming), but 'repo' cannot be trusted for anything else than 'repo sync', and git can be a bit overwhelming. I've been practicing, so i'm getting better at git, branching, merging and fixing conflicts when they occur.
and another one up for testing
I412f9bba - benchmark fans, let's go
For me the limit is my hardware. A notebook /w ubuntu (yeah!), but also 2 years old, 512 mb ram, 160 gb hd. Don't think that will do.
Taptalked u see
Zatta said:
For me the limit is my hardware. A notebook /w ubuntu (yeah!), but also 2 years old, 512 mb ram, 160 gb hd. Don't think that will do.
Taptalked u see
Click to expand...
Click to collapse
hmm, i used to build on a p4 with 2gb ram. linux holds its ground, it will not give up on you, even if you're browsing (don't watch flvs though ) or listen to music... i hope.
still, if you find something you want to see tested, write it down, someone will test it (if it doesn't get approved before that ) and share feedback.
---------- Post added at 10:06 PM ---------- Previous post was at 09:13 PM ----------
Received call, screen didn't wake up. pressed home once, no reaction, pressed power button twice, screen woke up and i was able to awnser the call.
http://pastebin.com/4PuAd31R
I/power ( 208): *** set_screen_state 0
D/SurfaceFlinger( 208): About to give-up screen, flinger = 0xeb108
D/KeyguardViewMediator( 208): wakeWhenReadyLocked(26)
I/power ( 208): *** set_screen_state 1
I/power ( 208): *** set_screen_state 1
Click to expand...
Click to collapse
i'm curious, what's KeyguardViewMediator?
quote from cm forums, user danielck78
Try this. Press on the sensor or somewhere near it. Try to press harder for about 2 seconds. Try if the screen turn back on.
Click to expand...
Click to collapse
edit: i'm with ring lockscreen. never happened before, but i've merged a couple of commits which are related to lockscreen stuff, note that i'm not saying that they are the cause. i'll try with vanilla kernel too (merged a couple of commits from zach 2.6.35.x towards battery runtime, although i don't think they're to blame since i had them for like 3 builds, that makes at least a week and a half using it)
bk201doesntexist said:
Do you think we should get a little bit more constructive/extensive (based on the wiki, sure) on build tips? setting up the buildenv isn't hard at all (just bandwith/time consuming), but 'repo' cannot be trusted for anything else than 'repo sync', and git can be a bit overwhelming.
Click to expand...
Click to collapse
Trying to get into CM7/SGS development, there seems no way around git. But git doesn't like me.
ATM I manage to 'sync repo' and cherry-pick commits. But get lost often. As you said: git is not easy.
So, I'd like this to be a place to talk about (maybe) upcoming changes and also to get some help with development related tasks.
On the long run, this could be a starting point to attract (or grow!) more SGS programmers.
I461e90ac: looks very promising. Switched to UMTS only and lost only 5% in two hour. Will see what I lose overnight.
bk201doesntexist said:
i'm curious, what's KeyguardViewMediator?
Click to expand...
Click to collapse
* Mediates requests related to the keyguard. This includes queries about the
* state of the keyguard, power management events that effect whether the keyguard
* should be shown or reset, callbacks to the phone window manager to notify
* it of when the keyguard is showing, and events from the keyguard view itself
* stating that the keyguard was succesfully unlocked.
At wakeWhenReadyLocked(26), the keyguard was notified that it may need to do something about a keypress, 26 is the keycode of the pressed key, KEYCODE_POWER = Power Key (http://developer.android.com/reference/android/view/KeyEvent.html).
jose.celestino said:
* Mediates requests related to the keyguard. This includes queries about the
* state of the keyguard, power management events that effect whether the keyguard
* should be shown or reset, callbacks to the phone window manager to notify
* it of when the keyguard is showing, and events from the keyguard view itself
* stating that the keyguard was succesfully unlocked.
At wakeWhenReadyLocked(26), the keyguard was notified that it may need to do something about a keypress, 26 is the keycode of the pressed key, KEYCODE_POWER = Power Key (http://developer.android.com/reference/android/view/KeyEvent.html).
Click to expand...
Click to collapse
thanks for the link (xda limit ) this whole section of the website looks like a nice place to learn.
anyways, another question while we follow the trail: at line 27 of the pastebin, set_screen_state 1 comes in, and this should have waken the screen, right?
as it didn't, then i pressed HOME, and WindowManager says there's a ringing incoming call already (because call Notification already has a fullScreenIntent right, that's why we can't leave the incoming call screen), so it can't pass that button press request further. i still don't get why power
set_screen_state 0 at line 43, without me pressing it, that's the thing.
edit: just now, phone was sleeping, and screen came up fine for a phone call. no issue. lol
Jens1969 said:
Trying to get into CM7/SGS development, there seems no way around git. But git doesn't like me.
ATM I manage to 'sync repo' and cherry-pick commits. But get lost often. As you said: git is not easy.
So, I'd like this to be a place to talk about (maybe) upcoming changes and also to get some help with development related tasks.
On the long run, this could be a starting point to attract (or grow!) more SGS programmers.
I461e90ac: looks very promising. Switched to UMTS only and lost only 5% in two hour. Will see what I lose overnight.
Click to expand...
Click to collapse
i'll try to get something going on the git side, although surely i need to improve as well. i now think cherry-picking/branches is easier than fixing conflicts. i'm managing myself through, you'll see, it's actually not that hard. it definately is easier for someone who knows how to code, but that's a given, i guess.
definately, i agree with you about the objective of this thread. i would add as well help improve users so that they can help themselves, maybe we'll turn into the devs of tomorrow (pretty utopic schedule that is, but still), maybe not, but we all learn something more out of it - knowledge has no place - while helping out the community, and making some more mistakes along the way.
I461e90ac looks promising indeed. i'll give one more cycle to it.
edit: i was bored so... in Ie259e6da, if we edit:
device/samsung/aries-common/AriesParts/res/values/arrays.xml to:
Code:
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<string-array name="backlight_timeout_entries">
<item>Off</item>
<item>Default (1.6 seconds)</item>
<item>2 seconds</item>
<item>5 seconds</item>
<item>10 seconds</item>
<item>15 seconds</item>
<item>30 seconds</item>
<item>Never</item>
</string-array>
<string-array name="backlight_timeout_entries_values" translatable="false">
<item>0</item>
<item>1600</item>
<item>2000</item>
<item>5000</item>
<item>10000</item>
<item>15000</item>
<item>30000</item>
<item>-1</item>
</string-array>
</resources>
would it be enough to turn off the leds entirely from AriesParts, while still having led notif, of course? or do we need to go kernel level, (i noticed drivers/input/keyboard/cypress-touchkey.c, like pawitp did here)?
i think only editing the xml doesn't do the trick like it should, does it? maybe if we changed this:
Code:
static void bl_set_timeout() {
if (bl_timeout > 0) {
mod_timer(&bl_timer, jiffies + msecs_to_jiffies(bl_timeout));
}
}
to
Code:
static void bl_set_timeout() {
if (bl_timeout ≥ 0) {
mod_timer(&bl_timer, jiffies + msecs_to_jiffies(bl_timeout));
}
}
no good? or would it still need something else? or is it completely way off and would make my phone melt
this doesn't look promising.. Void, seems to me that's the same as 'we don't need this'?
Code:
static void bl_off(struct work_struct *bl_off_work);
i think i will start doing some serious e-learning on coding.. once i get more "comfortable" at work and can relax a bit.
guys,i have been on cm7.1 from the day cm7.1 stable released and now Im on nightly 165,and i keep facing a problem (so do my 4friends)-the google framework service forcing problem
First i know a data wipe or wiping all the gapps and those apps that regard to account syncing ,but it sometimes work for a period(1day or less)and sometimes dun even works
can someone give me some helps ?
I'm on nightly 165 with stock kernel
Changed dpi with nitrality to 182dpi
leejack218 said:
guys,i have been on cm7.1 from the day cm7.1 stable released and now Im on nightly 165,and i keep facing a problem (so do my 4friends)-the google framework service forcing problem
First i know a data wipe or wiping all the gapps and those apps that regard to account syncing ,but it sometimes work for a period(1day or less)and sometimes dun even works
can someone give me some helps ?
I'm on nightly 165 with stock kernel
Changed dpi with nitrality to 182dpi
Click to expand...
Click to collapse
this is definitely the wrong thread for this. Answer in the q&a thread.
Edit: link to that is in my sig.
Taptalked u see
bk201doesntexist said:
edit: i was bored so... in Ie259e6da, if we edit:
device/samsung/aries-common/AriesParts/res/values/arrays.xml to:
Code:
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<string-array name="backlight_timeout_entries">
<item>Off</item>
<item>Default (1.6 seconds)</item>
<item>2 seconds</item>
<item>5 seconds</item>
<item>10 seconds</item>
<item>15 seconds</item>
<item>30 seconds</item>
<item>Never</item>
</string-array>
<string-array name="backlight_timeout_entries_values" translatable="false">
<item>0</item>
<item>1600</item>
<item>2000</item>
<item>5000</item>
<item>10000</item>
<item>15000</item>
<item>30000</item>
<item>-1</item>
</string-array>
</resources>
would it be enough to turn off the leds entirely from AriesParts, while still having led notif, of course?
Click to expand...
Click to collapse
No, that's the screen timeout.
or do we need to go kernel level, (i noticed drivers/input/keyboard/cypress-touchkey.c, like pawitp did here)?
Click to expand...
Click to collapse
You need this patch to get BACKLIGHT_TIMEOUT from userspace as it is hardcoded to 1600 (ms). Then you need another patch to set the value in CMParts or, in this case, AriesParts.
Don't know if 0 would turn it off though.
this doesn't look promising.. Void, seems to me that's the same as 'we don't need this'?
Code:
static void bl_off(struct work_struct *bl_off_work);
Click to expand...
Click to collapse
void means you don't care for the function return
EDIT: "Then you need another patch to set the value in CMParts", failed to see that that was the one you posted and included the arrays.xml. Disregard everything I said before that.
Yes if you edit that array, you will control the led backlight timer. Lowest you can go is 1. (0 is always on)
To test values do : echo 1 > /sys/class/misc/notification/bl_timeout
To turn it off however, some kernel "hacking" will be required
Oh, so that array is actually for the touchkeys backlight timeout. My bad.
And that's were it is read from userspace then, nice.
Daneshm90 said:
Yes if you edit that array, you will control the led backlight timer. Lowest you can go is 1. (0 is always on)
To test values do : echo 1 > /sys/class/misc/notification/bl_timeout
To turn it off however, some kernel "hacking" will be required
Click to expand...
Click to collapse
I'm confused. If 0 is always on, what's -1?
edit: Or did you mean -1 is always on?
edit2: (follow up on the next page) actually anything below 1 (since bl_timeout needs to be greater but not equal to 0) will make touchkey bl stay on forever.

[Q] newbie help

hi, ive tried cm, but it wont let me controll it from my keyboard, (aosp crash) and i rly want to use it stock, now im rooted, i can go back to stock, i can even have a launcher on it, as long as i can keep its stock purpose, to play my music and look awesome while doing it, but i cant get past the welcome screen, now, is there any way to bypass that?
meldalinn said:
hi, ive tried cm, but it wont let me controll it from my keyboard, (aosp crash) and i rly want to use it stock, now im rooted, i can go back to stock, i can even have a launcher on it, as long as i can keep its stock purpose, to play my music and look awesome while doing it, but i cant get past the welcome screen, now, is there any way to bypass that?
Click to expand...
Click to collapse
Not really. I'm thinking about how to make the ring dance using setting persist, but I'll have a lot to learn before then.
animal24 said:
Not really. I'm thinking about how to make the ring dance using setting persist, but I'll have a lot to learn before then.
Click to expand...
Click to collapse
nice, when u do, pls post a guide, i would rly love being able to use the leds, ure running cyan?
animal24 said:
Not really. I'm thinking about how to make the ring dance using setting persist, but I'll have a lot to learn before then.
Click to expand...
Click to collapse
Pro-tip: using setprop is really slow, IIRC. There is a program called avrlights that is used via a shell that allows you to change the ring faster with more granularity. If you're looking to get some dancing going on, avrlights is probably what you want (just know that it's kind of janky). On the other hand, if you just want to change the whole ring color, setprop will work, but it's still kinda slow.
mcsaucy said:
Pro-tip: using setprop is really slow, IIRC. There is a program called avrlights that is used via a shell that allows you to change the ring faster with more granularity. If you're looking to get some dancing going on, avrlights is probably what you want (just know that it's kind of janky). On the other hand, if you just want to change the whole ring color, setprop will work, but it's still kinda slow.
Click to expand...
Click to collapse
I like you already.
---------- Post added at 09:56 PM ---------- Previous post was at 09:53 PM ----------
mcsaucy said:
Pro-tip: using setprop is really slow, IIRC. There is a program called avrlights that is used via a shell that allows you to change the ring faster with more granularity. If you're looking to get some dancing going on, avrlights is probably what you want (just know that it's kind of janky). On the other hand, if you just want to change the whole ring color, setprop will work, but it's still kinda slow.
Click to expand...
Click to collapse
Is this in the play store? I can't find it.
animal24 said:
I like you already.
---------- Post added at 09:56 PM ---------- Previous post was at 09:53 PM ----------
Is this in the play store? I can't find it.
Click to expand...
Click to collapse
Happy to help out.
It's not in the Play Store. avrlights is not an Android app. It is a compiled binary that exists on CyanogenMod-enabled Q's.
Here's how it works:
Open the Terminal Emulator app
Type "su -" (without quotes) and press enter
Give Terminal Emulator root access when prompted
Type "avrlights <ARGUMENTS>" (without quotes and see the arguments section below) and press enter again
So, you only need to do steps 1 through 3 when you open up a Terminal Emulator session. After all, once you're at a root shell, you don't need to get a root shell again.
So, let's talk arguments. If you just run "avrlights", it should set your LEDs to the default color (whatever is stored in persist.sys.ringcolor). If you run "avrlights <COLOR>", you change the ring color. If you run "avrlights <COLOR1> <COLOR2> <COLOR3> <COLOR4> <COLOR5> ... <COLOR32>" you can change each LED to a color.
How does this work? Well, first things first. Let's talk about encoding color. Color for a RGB LED on the Q (we have 32 around the ring of the Q) is 24-bit, with 8 bits per channel. This is fairly common. The strength of each channel is represented by a value ranging between 0 and 255 in base 10, or 0x00 and 0xff in hexadecimal, where 0 (0x00) is completely off and 255 (0xff) is full force.
With me so far? You can make a lot of different colors by combining these 3 component colors. I'd recommend Googling for a RGB color wheel and playing around with one of those if you want to get a better grasp.
You can combine these primitive colors using pretty simple math to represent more complex colors. For example, solid yellow would be (r,g,b) -> (255, 255, 0). If you mash these 3 values together using (r * 256 * 256 + g * 256 + b) to get a single number for your color, you can now update your ring with avrlights! It would be really nice if you could just use hexadecimal to update avrlights (that way it's just 0xRRGGBB and you don't need to do math on the fly), which is why I included that feature in my rewrite. In the mean time, you can kind of update with hex. Just do the following: "avrlights $( printf '%d' 0xRRGGBB ) ..." The printf statement converts your hex to base 10 on the fly, making it an acceptable workaround.
TL;DR: open up Terminal Emulator and run `avrlights $( printf '%d' 0xRRGGBB )` where RR, GG, and BB are your component colors in hex. You can specify multiple colors in a single call. To do so, just add them to the list of arguments.
mcsaucy said:
Happy to help out.
It's not in the Play Store. avrlights is not an Android app. It is a compiled binary that exists on CyanogenMod-enabled Q's.
Here's how it works:
Open the Terminal Emulator app
Type "su -" (without quotes) and press enter
Give Terminal Emulator root access when prompted
Type "avrlights <ARGUMENTS>" (without quotes and see the arguments section below) and press enter again
So, you only need to do steps 1 through 3 when you open up a Terminal Emulator session. After all, once you're at a root shell, you don't need to get a root shell again.
So, let's talk arguments. If you just run "avrlights", it should set your LEDs to the default color (whatever is stored in persist.sys.ringcolor). If you run "avrlights <COLOR>", you change the ring color. If you run "avrlights <COLOR1> <COLOR2> <COLOR3> <COLOR4> <COLOR5> ... <COLOR32>" you can change each LED to a color.
How does this work? Well, first things first. Let's talk about encoding color. Color for a RGB LED on the Q (we have 32 around the ring of the Q) is 24-bit, with 8 bits per channel. This is fairly common. The strength of each channel is represented by a value ranging between 0 and 255 in base 10, or 0x00 and 0xff in hexadecimal, where 0 (0x00) is completely off and 255 (0xff) is full force.
With me so far? You can make a lot of different colors by combining these 3 component colors. I'd recommend Googling for a RGB color wheel and playing around with one of those if you want to get a better grasp.
You can combine these primitive colors using pretty simple math to represent more complex colors. For example, solid yellow would be (r,g,b) -> (255, 255, 0). If you mash these 3 values together using (r * 256 * 256 + g * 256 + b) to get a single number for your color, you can now update your ring with avrlights! It would be really nice if you could just use hexadecimal to update avrlights (that way it's just 0xRRGGBB and you don't need to do math on the fly), which is why I included that feature in my rewrite. In the mean time, you can kind of update with hex. Just do the following: "avrlights $( printf '%d' 0xRRGGBB ) ..." The printf statement converts your hex to base 10 on the fly, making it an acceptable workaround.
TL;DR: open up Terminal Emulator and run `avrlights $( printf '%d' 0xRRGGBB )` where RR, GG, and BB are your component colors in hex. You can specify multiple colors in a single call. To do so, just add them to the list of arguments.
Click to expand...
Click to collapse
So to set the mute color we still use setprop i imagine.
animal24 said:
So to set the mute color we still use setprop i imagine.
Click to expand...
Click to collapse
I believe so. There is some weird stuff that can go down due to the use of uninitialized memory, IIRC. Looking at the code, the mute LED looks to be set to the first color you give it.
Code:
color = prepare_leds(colors[0]);
ioctl(fd,AVR_LED_SET_MUTE,&color);

WatchMaker formula and help Thread

Hi,
watchmaker (Link) is a great tool and simple faces are created quickly, but we need more.
with formulas is much more possible and I want to collect them here.
regards
starbase64
example clock > http://facerepo.com/app/faces/details/chronograph-by-starbase64-iv-14a70b5fa2b
rotate "WA" battery:
Code:
-{bl}*360/100
WA battery icon:
Code:
'{bc}' == 'Charging' and 7 or {bl} >= 90 and 1 or {bl} >= 70 and 2 or {bl} >= 50 and 3 or {bl} >= 30 and 4 or {bl} >= 10 and 5 or 6
rotate "PH" battery:
Code:
-{pbl}*360/100
PH battery icon:
Code:
'{bc}' == 'Charging' and 7 or {pbl} >= 90 and 1 or {pbl} >= 70 and 2 or {pbl} >= 50 and 3 or {pbl} >= 30 and 4 or {pbl} >= 10 and 5 or 6
rotate seconds circle:
Code:
-{drss}
rotate minutes circle
Code:
-{drm}
rotate minutes circle
Code:
-{drh}
{
"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"
}
example clock > http://facerepo.com/app/faces/details/summer-time-14acd7a68f6
watch battery in percent
Code:
{blp}
wacht battery in percent with opacity > if lower 15 percent (copy this code to opacity setting)
Code:
{bl} < 15 and 100 or 0
wacht battery in percent with opacity > if lower 50 percent (copy this code to opacity setting)
Code:
{bl} < 50 and 100 or 0
wacht battery in percent with opacity > if charger connectet (copy this code to opacity setting)
Code:
'{bl}' == 'Charging' and 100 or 0
works also with phone battery {pbl} and {pbc}
you need 4 battery in percent letters with various opacity formula.
example clock > http://facerepo.com/app/faces/details/mechanic-v-14ad47f4ec5
this formula show or hide a pic in a defined time:
Code:
{dh23}<=18 and {dh23}>= 6 and [COLOR="Red"][B]50[/B][/COLOR] 0 or
example: a black square with this formula in opacity setting, will dim your clock at night.
The red number is the opacity setting, higher = stronger
example clock > http://facerepo.com/app/faces/details/night-and-day-ii-14adcd8cb74
change background automatically with sunrise and sunset...
copy formula to opacity from the second image (opacity for the first image =100):
Code:
{wsrp}>={dtp} and 100 or {wssp}<{dtp} and 100 or 0
thanks to Klaus Koehler (G+) for helping to find the right formula
Help creating formula in watchmaker:
1) formula for showing wind chill . Formula for metric wind chill calculation:
Twind_chill = 13.12 + 0.6215*T - 11.37*(v0.16) + 0.3965*T*(v0.16)
T=temp, V= windspeed.
2) Formula, showing arrow up when rising temp (or barometric pressure), arrow down, falling temp/barometric pressure. No ide how to create this....if possible...
example watch > http://facerepo.com/app/faces/details/night-and-day-iii-14ae9343b9c
blinking text for temperature lower than 4C°
Code:
{ds}%2 == 0 and 100 and {wt}< 4 and 100 or 0
Copy code to opacity setting!
@espenjoh
no idea at the moment
To show a Different Day of the Week
This code will show tomorrow's day of the week in 3 letter day of the week form.
{ddw0}==0 and 'Mon' or {ddw0}==1 and 'Tue' or {ddw0}==2 and 'Wed' or {ddw0}==3 and 'Thu' or {ddw0}==4 and 'Fri' or {ddw0}==5 and 'Sat' or 'Sun'
Copy code into text field.
This piece of code is very useful at rotating a sun/moon cycle indicator. But this does not simply imply the sun rises at a quarter of the day and sets at 3 quarters, in stead the sun rises and sets just like in real life.
Code:
{dtp} < {wsrp} and (-180 + ({dtp}/{wsrp})*90) or {dtp} <= {wssp} and (-90 + (({dtp} - {wsrp})/({wssp} - {wsrp}))*180) or {dtp} <= 1 and (90 + (({dtp} - {wssp})/(1 - {wssp})*90))
This can be used at indicators where at 0° the sun is at his highest point.
Some self-made examples are:
http://facerepo.com/app/faces/details/epic-sun-moon-cycle-clock-14b06fdac8c
http://facerepo.com/app/faces/details/steampunk-2-14ad939e2b3
http://facerepo.com/app/faces/details/steampunk-14aaa686824
---------- Post added at 12:09 PM ---------- Previous post was at 11:48 AM ----------
This rotates objects according to gravity, but it doesn't work a hundred per cent and needs improvement. Anyone any ideas?
Code:
{say} > 0 and ({sax}+10)/20*360/2+270 or {say} <= 0 and 360-({sax}+10)/20*360/2+270
Example: http://facerepo.com/app/faces/details/andy-with-moving-arms-14ae3ad326a
Probably not correct place to post but haven't had any luck elsewhere. I would like to use the Style Clock 1 on my gear s but use my own background. cant find location of that clock to do so. Can someone please point me in right direction
@lusciousbeard
open watchmaker tap on the clock an choose "Customize Copy"...
starbase64 said:
@lusciousbeard
open watchmaker tap on the clock an choose "Customize Copy"...
Click to expand...
Click to collapse
I want to use the stock clock that comes with gear manager. Its called Style clock 1. I just want my own background with that clock.
Don't know if this is a a forumla but trying to change the watch face based on a variable.
In tasker have WM Change Watch plugin selected, select which watch face and If %Batt <65%
The attempt is that when the battery is 65% or less the watch face changes
I'd like to add a second location and the current forecast for that location.
formula for celsius and fahrenheit in same clock.
F = ({wt}/5)*9+32
C = (({wt}-32)/9)*5
Is it possible to display active tasker profiles etc. ?
Can someone help, I want to make a few different sub dials. How can I change the rotational value for the watch and phone battery to be 160 or so degrees instead of following a full 360. I want to split the dial with two hands, have each devices battery on the dial, once for each side. The left side having and Full down to Empty running from the 11 Oclock spot down to 7, then mirroring the other side for the other battery
The second dial I wanted a 360 - 7 point where the hand changed each day (for day of week dial)
I am not the best at writing code and was having trouble figuring out how to write this
I realize your post is 4 months old, but . . .
mikeschevelle said:
Can someone help, I want to make a few different sub dials. How can I change the rotational value for the watch and phone battery to be 160 or so degrees instead of following a full 360. I want to split the dial with two hands, have each devices battery on the dial, once for each side. The left side having and Full down to Empty running from the 11 Oclock spot down to 7, then mirroring the other side for the other battery
Click to expand...
Click to collapse
It's a math problem. x/160 = y/360.
y is the rotational value based on a full circle ({drs}, {drm}, or {drh} in watchmaker)
x is the rotational value based on your 160 degree arc. If you solve for x, you get x=.444y
so you can enter the following in a rotation field to get any object to show seconds over your 160 degree arc:
Code:
.444 * {drs}
The second dial I wanted a 360 - 7 point where the hand changed each day (for day of week dial)
Click to expand...
Click to collapse
360/7 = 51.429, so each day would be 51.429 degrees. Set your rotation value to:
Code:
{ddw0} * 51.429
In the Watchmaker Reddit, I posted about saving battery life https://www.reddit.com/r/WatchMaker/comments/3liwww/tips_to_improve_battery_life/
I noticed that I was losing 5-6% battery life per hour with a watchface I made. When I switched to a very simple face with no bells and whistles, I lost closer to 3% per hour. I did some experimenting to figure out how to reduce battery usage with my more complicated face. Here's what I learned:
- Watchmaker still executes positioning code for elements that are not visible. For example, if you enter "{ds}+2" as the rotation for an element that is only visible in bright mode, watchmaker will still do the math once a second while it's in dim mode.
- How frequently an object updates is determined by what watchmaker tag is in the object properties. If no tag is in the properties, it will not update. So if you set the rotation of a hand to "{ds}+2" watchmaker will do the math every second and the hand will move every second. Now lets say you create a function called var_ds() that returns the {ds}+2. Setting the rotation of the hand to "var_ds()" will cause the hand not to rotate. There is no watchmaker tag in the rotation field, so the function is never called and the rotation value never updates. Setting rotation to "var_ds({ds})" will cause the function to be called and the hand to rotate every second. Setting rotation to "var_ds({dm})" will cause the function to be called and the hand to move once a minute - even if the function is still returning values based on {ds}.
Using this info, I was able to come up with some possible optimizations to improve battery life:
1) If you're using lots of math or code to place an object, add "if is_bright" to your code so that it won't be executed while the screen is dim. If you do this, you should initialize the variable is_bright to 1 to prevent weirdness.
2) To control the frequency of updates, stick your code in a function and call it with a tag that represents the frequency you want. For example, I wanted my minute hand to stop on minute marks rather than move smoothly. I wrote a function:
Code:
function var_rotation (r)
return 6*math.floor({drm}/6)
end
The "r" variable is never used in the function, but it lets me control how often the function is called. Previously when I used "6*math.floor({drm}/6)" directly as a rotation value, the expression was evaluated whenever {drm} updated - I'm guessing at least once a second - even though the hand was only actually moving once a minute. Now, my rotation value is var_rotation({dm}). The {dm} causes my function to be called only once a minute which makes a lot more sense for a hand that's only moving once a minute
3) If I had multiple objects using var_rotation() to rotate, I might add a conditional statement to make sure the bulk of the code only runs once a minute:
function var_rotation (r)
Code:
if not (var_lastran == {dm}) then
var_result = 6*math.floor({drm}/6)
end
return var_result
end
If there is a recent result, this simply returns that result instead if recalculating it. If the result is older than a minute, it calculates a new result.
For the particular watchface I was working on, only optimization #2 applied, but based on my initial testing, I'm down to around 3% battery/hour. Hopefully this info helps someone else
Click to expand...
Click to collapse

[Camera][MOD][2.2.2016][MORE DETAIL, MORE LIGHT][MM base][AROMA][ONLY OP DISCOUNTED]

First of all, I would like to thank all those guys from "Photos Taken With M9" thread.
HUGE GREAT BIG AWESSOME THANKS go to @starbase64 ; @defcomg ; @hamdir !!!
SO THANK YOU MATES!!!!​
{
"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"
}
Since HTC made a bad software, that compress data from chip and creates jpeg, many of us hoped for something new, something better. With every update we prayed for better noise control. Some prays were heard, some were not. Theese hard times a few heroes, that see thru codes and hacks found a way how to make our photos better. Enough talks, lets go for it!
DISCLAIMER: I AM NOT RESPONSIBLE FOR ANY DAMAGE YOU DO TO YOUR PHONE USING SOME OF THIS HACKS
SINCE I HAVE NO MORE M9 DEVICE AND NO TIME FOR TESTING AND SO, I AM FORCED TO DO LAST UPDATE HERE IN THIS THREAD. I WOULD BE PLEASED, IF SOMEONE TAKE THIS AFTER ME AND MAYBE START A NEW, CLEAR THREAD FOR MM. ANYWAY I ADD HERE NEWEST MOD FOR MM. THANK YOU GUYS, IT WAS A PLEASURE WORKING WITH YOU! YOU ARE THE BEST
CAMERA MOD LIBS FOR HTC ONE M9 ON MARSHMALLOW
FLASHABLE ZIP HERE!! HIT THANX OR DIE!
http://forum.xda-developers.com/showpost.php?p=65083400&postcount=458
DOWNLOAD HERE! DONE FORGET TO HIT THANX!!!:
http://forum.xda-developers.com/showpost.php?p=65075578&postcount=434
PREVIEW HERE! ALSO HIT THANX!!!:
http://forum.xda-developers.com/showpost.php?p=65037806&postcount=431
VIDEO HOW TO INSTALL VIA ROOT EXPLORER HERE!! HIT LIKE ON YOUTUBE!!! ITS FREE!!!
OLD MOD FOR LAST LOLLIPOP
HW DENOISE AND 9 SECONDS OF EXPOSURE TIME
COMPATIBILITY:
This mod is TESTED on base 2.10.401.1
and it works on that base
INSTALATION:
Download attached HTCOneM9_CameraMods_v1.04.zip attached below.
Reboot to recovery
FLASH the mods that you want.
Reboot
Enjoy!!!
@hamdirs HUGE TEST FOR DENOISE HERE!!!---->CLICK!!!
HIT THANX on his post
My camera settings:
10:7 ratio
big resolution
contrast +0,5
saturation +0,5
sharpeness -1
Since we have new awessome HW denoise mod, I dont use to use any of build.prop tweaks.
@defcomg THANK YOU FOR YOUR HUGE CODE RESEARCH!!!
@hamdir THANK YOU FOR YOUR HUGE TEST RESEARCH!!!
@starbase64 THANK YOU FOR YOUR OVERALL SUPPORT!!!
@jsaxon2 THANK YOU FOR CREATING AROMA INSTALLER FILE TO MAKE INSTALL MORE EASIER
THANK YOU GUYS. IT WAS A PLEASURE.​
@m4jkee great thread mate but are we sure we can disable both htc denoise and apply denoise persist in the same time?
actually i am not sure if these work at all on the 2.10 pure base
hamdir said:
@m4jkee great thread mate but are we sure we can disable both htc denoise and apply denoise persist in the same time?
Click to expand...
Click to collapse
I dont know exactly but I guess denoise persist dont aply on recorded videos. Disabling htc denoise made my lowlight videos more noisy. I will test it later today and post results. thank you for reply
Is that zip flashable?
Ok I see its not. Where do the files go?
Or could u even make flashable zip?
Huge thanks for your efforts mates @hamdir @m4jkee @starbase64 @defcomg :good:
Mostafa Wael said:
Huge thanks for your efforts mates @hamdir @m4jkee @starbase64 @defcomg :good:
Click to expand...
Click to collapse
Guys the settings all together create a conflict, especially the sub pixel setting
The persist.camera.snap.format = 1 creates terrible color noise in low light and destroys what we are trying to achieve here so I don't think this line should be added
I am doing some tests to figure out the best combo and will share my conclusion, but so far I am seeing very definite Improvement by simply removing the sub pixel line
hamdir said:
Guys the settings all together create a conflict, especially the sub pixel setting
The persist.camera.snap.format = 1 creates terrible color noise in low light and destroys what we are trying to achieve here so I don't think this line should be added
I am doing some tests to figure out the best combo and will share my conclusion, but so far I am seeing very definite Improvement by simply removing the sub pixel line
Click to expand...
Click to collapse
try this
Code:
persist.camera.HAL3.enabled=1
Dload
freedcam
Settings > camera api > camera2
check by info overlay if it says legacy , limited or full?
defcomg said:
try this
Code:
persist.camera.HAL3.enabled=1
Dload
freedcam
Settings > camera api > camera2
check by info overlay if it says legacy , limited or full?
Click to expand...
Click to collapse
Added the Line, camera and freedcam force close on me. Camera fv-5 viewfinder hang. Check on manual camera compatibility it says Full.
xunus said:
Added the Line, camera and freedcam force close on me. Camera fv-5 viewfinder hang. Check on manual camera compatibility it says Full.
Click to expand...
Click to collapse
install this version https://drive.google.com/file/d/0B5NJTB9bLPdsQmdKR2NIZkdEUEU/view?usp=sharing clear data
make a folder named DEBUG in /DCIM/FreeDcam it should log the crash alternative normal logcat should suffice then we can see why camera 2 api crash
defcomg said:
install this version https://drive.google.com/file/d/0B5NJTB9bLPdsQmdKR2NIZkdEUEU/view?usp=sharing clear data
make a folder named DEBUG in /DCIM/FreeDcam it should log the crash alternative normal logcat should suffice then we can see why camera 2 api crash
Click to expand...
Click to collapse
Here it is.
xunus said:
Here it is.
Click to expand...
Click to collapse
Crash todo with MF lemme disable it quick and rebuild
EDIT: Added updated apk @xunus try this apk
defcomg said:
Crash todo with MF lemme disable it quick and rebuild
EDIT: Added updated apk @xunus try this apk
Click to expand...
Click to collapse
I renamed to .apk due to file size.
xunus said:
I renamed to .apk due to file size.
Click to expand...
Click to collapse
what happend on last try apk from logcat it seems camera started
defcomg said:
what happend on last try apk from logcat it seems camera started
Click to expand...
Click to collapse
no preview for me, and crash on press shutter
starbase64 said:
no preview for me, and crash on press shutter
Click to expand...
Click to collapse
i see lets call @troopii to look at http://forum.xda-developers.com/showpost.php?p=63189969&postcount=12
i don't know much about camera 2 part of freedcam from the log seem to be looping on
Code:
Line 161680: 2015-10-08 08:41:15:E/freedcam.BaseCameraHolderApi2(25357): Couldn't find any suitable previewSize size
hopefully he will know whats up
defcomg said:
try this
Click to expand...
Click to collapse
my interest is currently focused on the HTC camera app and these tweaks, tested in low light on pure 2.10 base
persist.camera.qcwnr.enabled=0
This is essential if we want any control over the way the M9 deals with noise, if we don't use this line denoise will remain the same and the persist.denoise.process.plates below will not have any effect, this is the line with the most clear change, once we use it, HTC's famous smudging will disappear and will get much more detailed images instead at the cost of apparent color and luma noise especially in low light
camera.eis.enable=0
Well this will disable HTC's weird EIS effect and instead we will have motion blur, without OIS the M9 is very weak in getting stable shots in low light, so either way it's a loss, disabling EIS however can be beneficial for shots with better light
persist.camera.snap.format=1
This has little effect unless we disable HTC's denoise using persist.camera.qcwnr.enabled=0, once we do persist.camera.snap.format=1 will cause a clear change, however the results of the value 1 and disabled HTC smudging are terrible, it creates extreme color noise even in medium light plus unstable pixel patterns, we should not use this line, it also cause color damage to the thumbnails
persist.denoise.process.plates=0
once we disable HTC denoise using persist.camera.qcwnr.enabled=0, these controls will work but the change is minimal, naturally 0 or 1 are the better values since they prioritize quality but they do at the cost of speed which the M9 already suffers from in low light (the image will take a longer while to be saved in gallery), so i suggest going to 0 or 1 only if we are using locking at least ISO400 and not 200 (to keep the shutter a little faster), 0 seems to use Android's built-in general quality denoise, while 1 will only deal with the color components without touching the grey scale image more here, result is that you will have higher amount of dark noise but will look slightly more detailed, you can really use any of the values to your preference (quality vs speed, full denoise vs color denoise) but keep in mind Android's built-in denoise is not that great either, in extreme low light we will still see terrible color noise due to the tiny pixel nature of our sensor (which explains why HTC went so insane with their own smudging)
in fact the denoise plates are actually exaggerating the fine nature of the tiny pixel noise! does anyone know how to disable them completely?
currently this combo works:
persist.camera.qcwnr.enabled=0
camera.eis.enable=0
# persist.camera.snap.format=1 (not using this line)
persist.denoise.process.plates=0
but it still doesn't match Freedcam's pre 5.1 denoise disable (which gave us pure noise from the sensor like RAW), we need a way to disable both HTC denoise and the plates together if we want match that
finally we should remember both ISO and Sharpness settings have direct effect into the pixel quality as well, since the sharpness code also have some denoise of it's own and naturally the higher ISO the more noise, anything higher than 400 becomes crazy in noise, thankfully the M9 sensor is low ISO friendly (i mean you can take bright low light images even with ISO400)
my current settings are middle ground:
- Sharpness -1
- Max ISO400
essentially my recommendation is this:
persist.camera.qcwnr.enabled=0
camera.eis.enable=0
persist.denoise.process.plates=0
Sharpness -1
Max ISO400
Click to expand...
Click to collapse
DO NOT add the line persist.camera.snap.format=1 or persist.camera.snap.format=0
we end with something similar or even better than the OP2 auto mode
color noise is evident the higher the ISO (at 1600 it becomes extreme) but around ISO200/400 we will get great image with faint apparent noise, which is much better than HTC's default smudge fest
samples and comparison photos here
I still think @Almalence post process tech like the OP2 clear image is lot more beneficial than all this non sense:
http://forum.xda-developers.com/showpost.php?p=63176700&postcount=30248
I may be a bit rude with this request @hamdir
But can we have some comparing samples?!
EDIT: Never mind, i just applied the tweaks
Looking obviously improved already in daily light :good:
Mostafa Wael said:
I may be a bit rude with this request @hamdir
But can we have some comparing samples?!
Click to expand...
Click to collapse
the problem is that late night yest i did like a hundred test and i didnt organize them in any way for me today to use in a comparison
now that i know the results, i will try to take samples later tonight
---------- Post added at 10:46 AM ---------- Previous post was at 10:33 AM ----------
Mostafa Wael said:
EDIT: Never mind, i just applied the tweaks
Looking obviously improved already in daily light :good:
Click to expand...
Click to collapse
that's more like it
can you supply some samples
it basically saves you the bother of relying on RAW mode for better shots all the time, plus it actually improves HDRs the most (since the merge effect was most harmed by the smudging)
@m4jkee why did you improvise mate i said dont use the line, not set it to 0 originally this commit was added by Google for test reason
i tested it with 0 and it still does the same damage, without the line at ISO400 there is no color noise
can someone help here?
https://android.googlesource.com/platform/hardware/qcom/camera/+/1c6f92e
QCamera2: set snapshot format to YUV422 when system prop is set
Per test request, when system prop "persist.camera.snap.format" is
set to 1, snapshot format should be set to YUV422.
CRs-Fixed: 462490
Change-Id: Idd353f90338b595096622bebbeda59a46e578693
Click to expand...
Click to collapse
Change-Id: Idd353f90338b595096622bebbeda59a46e578693
diff --git a/camera/QCamera2/HAL/QCameraParameters.cpp b/camera/QCamera2/HAL/QCameraParameters.cpp
index 91f01cf..0b8c17e 100644
--- a/camera/QCamera2/HAL/QCameraParameters.cpp
+++ b/camera/QCamera2/HAL/QCameraParameters.cpp
@@ -4730,7 +4730,16 @@
if ( mPictureFormat == CAM_FORMAT_YUV_422_NV16 ) {
format = CAM_FORMAT_YUV_422_NV16;
} else {
- format = CAM_FORMAT_YUV_420_NV21;
+ char prop[PROPERTY_VALUE_MAX];
+ int snapshotFormat;
+ memset(prop, 0, sizeof(prop));
+ property_get("persist.camera.snap.format", prop, "0");
+ snapshotFormat = atoi(prop);
+ if(snapshotFormat == 1) {
+ format = CAM_FORMAT_YUV_422_NV61;
+ } else {
+ format = CAM_FORMAT_YUV_420_NV21;
+ }
}
break;
case CAM_STREAM_TYPE_VIDEO:
Click to expand...
Click to collapse
as i understood it, it returns then always a yuv frame.
--edit;
im wrong when that flag is set the output yuvformat is forced to yuv422 nv16. thats for preview
if not its set to nv21. but not sure whats the big difference is. only thing i know is that it must set to nv21 for 4kuhd on g3.
when its set to nv21 the thumb images returned from cam have crazy colors. but full size image is normal.
public static final int NV16
Added in API level 8
YCbCr format, used for video.
For the android.hardware.camera2 API, the YUV_420_888 format is recommended for YUV output instead.
Whether this format is supported by the old camera API can be determined by getSupportedPreviewFormats().
Constant Value: 16 (0x00000010)
public static final int NV21
Added in API level 8
YCrCb format used for images, which uses the NV21 encoding format.
This is the default format for Camera preview images, when not otherwise set with setPreviewFormat(int).
For the android.hardware.camera2 API, the YUV_420_888 format is recommended for YUV output instead.
Constant Value: 17 (0x00000011)
Click to expand...
Click to collapse

touchscreen calibration and some other (related?) things

Backstory (because context is always nice)
Before I got my ZenFone2 I was using a samsung galaxy s2 as my main phone.
It was a really nice phone and became even better after some small modifications such as attaching a bluetooth keyboard to it and converting the touchscreen to a touchpad (like those things on laptops). With a chroot linux installation it actually felt like a pocket computer. However it had rather low processing power and very little ram and a small screen with a low resolution. The zf2 with its good specs and x86_64 would be much better suited to be truly a pc in the pocket....
So I wanted to make the touchscreen on the zf2 behave like a touchpad.
According to this, I only need to change 1-2 lines in an .idc file.
This worked well on the sgs2 (filename:sec_touchscreen.idc) but on the zf2, there is no such file.
After looking through a bit of kernel code, I found out that the file should be called "ftxxxx_ts.idc".
After creating the file you can start to calibrate the behaviour of the touchscreen.
This might be helpful: https://source.android.com/devices/input/touch-devices.html
touchscreen --> touchpad
Here are the basic steps of making the touchscreen behave like a touchpad.
Simply run these commands in a root shell
Code:
echo "touch.deviceType = pointer" >> /system/usr/idc/ftxxxx_ts.idc
echo "touch.gestureMode = spots" >> /system/usr/idc/ftxxxx_ts.idc
echo "touch.orientationAware = 1 " >> /system/usr/idc/ftxxxx_ts.idc
chmod 544 /system/usr/idc/ftxxxx_ts.idc
chown 0:0 /system/usr/idc/ftxxxx_ts.idc
or add these three lines manually to the file (also create if it doesn't exist).
Code:
touch.deviceType = pointer
touch.gestureMode = spots
touch.orientationAware = 1
Make sure the permissions are correct (544 or rwrr).
ALSO IMPORTANT: Make sure that there are no mistakes in the code before running it (because I might have mistyped something....but I don't think so).
(Soft-)Reboot for the changes to take effect.
touchscreen <-- touchpad
To revert the changes, you can delete the file or change
Code:
touch.deviceType = pointer
to
Code:
touch.deviceType = touchscreen
You can also comment out the line.
Code:
#touch.deviceType = pointer
This should make it behave like a touchscreen again.
What next:
I still need to find a way to change between touchscreen and touchpad mode on the fly without doing the editing and rebooting.
Maybe an xposed module could do this, but I have not found one and I have no idea how to write one.
Therefore.....If anyone knows how to do this, please help.

Categories

Resources