Related
So my only complaint so far is the screen sensativity.
I know this doesnt use a capacitive screen, so it needs physical pressure, but it seems to me the glass on the top of the screen makes it need alot more pressure than i'm used to. The middle of the screen seems to be more sensative, and the outside less sensative.
You can test this by putting your finger down on HOME in touchflo, then scrolling to programs and back again. If you pres hard, it will go back and forth. If you use less pressure at home and programs it will load the programs or home screen, as if you released your finger.
So i know there's two reg keys for this:
HKEY_LOCAL_MACHINE\Drivers\TouchPanel
By doing a screen slignment and pressing hard with the stylus i get a lower value here, and by pressing lightly i get a higher value here.
So high value = detects lighter press, low value - needs harder press
HKLM\Software\OEM\TFLOSettings\fingurepressure
This i'm confused about. I tried setting it to 0, 2, 14, 200, 255, 600, and there's not noticable difference as far as i can see.
Is there some sort of program that can read the the pressure from the screen and display it? This would help make the tests alot more scientific!
Someone posted this tip in the tips and tweaks thread above...maybe useful to you??
One tip for changing the sensitivity if you don't want to mess around in the registry:
- run the Align Screen setting (under Settings/System/ Screen)
- when you press on the 'targets' with the stylus, use VERY light pressure...just enough that the tap is accepted
- I usually tap a few times on each target, starting too lightly, and then gradually increasing the pressure until the tap is taken
- do this for each of the 5 targets
I found this seems to make the Diamond calibrate a higher sensitivity for its touch-screen, so finger touches can be much lighter.
This is probably a safer way to change the sensitivity, as you don't risk putting an invalid number into the registry.
Thanks, i already tried that.
Can someone tell me their value for this key?
HKLM\Software\OEM\TFLOSettings\fingurepressure
Screen sensitivty
Spawn12 said:
Someone posted this tip in the tips and tweaks thread above...maybe useful to you??
One tip for changing the sensitivity if you don't want to mess around in the registry:
- run the Align Screen setting (under Settings/System/ Screen)
- when you press on the 'targets' with the stylus, use VERY light pressure...just enough that the tap is accepted
- I usually tap a few times on each target, starting too lightly, and then gradually increasing the pressure until the tap is taken
- do this for each of the 5 targets
I found this seems to make the Diamond calibrate a higher sensitivity for its touch-screen, so finger touches can be much lighter.
This is probably a safer way to change the sensitivity, as you don't risk putting an invalid number into the registry.
Click to expand...
Click to collapse
Tried that, and its really works. Thank a lots.
someone1234 said:
Thanks, i already tried that.
Can someone tell me their value for this key?
HKLM\Software\OEM\TFLOSettings\fingurepressure
Click to expand...
Click to collapse
the value is 19 in uk device rom.
vijayvasa said:
the value is 19 in uk device rom.
Click to expand...
Click to collapse
19 decimal?
I've just about had enough of this touchflo.. pretty but soooo anoying to use
Today on about 3 ocasions i was navigating through it and got a call.. the lights on the touch wheel were flashing and it was playing the ringtone, but the whole phone was frozen for about 4 seconds. Eventually the call popped up and i was able to answer!
I think i'm going to diable it and do my best to make the rest pretty.
You just have to be patient...the roms are not mature yet...
In 3 months you'll see that Diamond will be the best phone out there
I also am trying to find out the best way to configure the finger sensitivity.
HastaSSSS
s1rl4ncel0t said:
In 3 months you'll see that Diamond will be the best phone out there
Click to expand...
Click to collapse
yeah but 3 months is a long time... i have to do something to stop myself smashing the phone on the floor on frustration!
for now i'm going to disable touch flow, and i'll come back to it when a new rom comes out.
Have you tried the new rom 1.37.XXX ?
Bye
I have a UK diamond.. so it came with 1.37.405.1
I've just done the "light tap" trick, and now it's perfect...
Could it be that you have a defective device?
Bye
Its better with that 'trick' but still anoying. I have a feeling i'm just too used to a capacitive screen.
The wierd thing is with the light tap the key HKEY_LOCAL_MACHINE\Drivers\TouchPanel ends up back to 30 to 50 decimal.
i only bought it today yet im seriously thinking of taking it back. The iPhone is just the better product, and always will be, unless Microsoft and the software developers get as passionate as those at apple.
Its Laggy
Its un-intuative
The touch screen isnt as sensitive as it should be. (why are they still using resistive touchscreens)
And the opera browser isnt all that either, it doesnt redraw quick enough for the full page display thing to really be all that impressive on zoom in/out and leaves chessboard squared at it struggles and chuggs to redraw.. . .not great, not when the comptetition is as good as it is. . . . .im thinking 3G Iphone, ****ty camera or not.
Loose the 6.1 and stop trying to polish that turd with TouchFlo's. Yeah good effort, but it just aint good enough
J
WM is just a huge resource hog. The touchflo is slow because its a plugin for the today screen, which then calls on windows API's to draw onto the screen.
Its such a long long way round to get to the hardware that its just slow no matter how well u code.
I just hope someone ports android to the diamond, because the hardware is amazing, the OS is a pile of ****!
BTW they use resistive touchscreens to have increased touch resolution. Also a stylus wouldnt work with a capacitive screen.
I prefer to work with resistive LCD than capacitive...
The capacitive have better sensibility, but are less precise...
Although the Diamond LCD is not as sensitive as a capacitive, it's sensitive enough to work well with the fingers...
It's just a matter of tweaking.
HastaSSSS
Resistive screens use a grid of conductive material, sandwitched between the glass and a conductive layer. They alternatly pass an electrical current on each line of the grid along the x and y axis. When you press the screen you touch this grid onto the conductive layer and the current passes through it, which is detected. You can make resistive screen that have a very high resolution of detection, and the resolution is always what you design it to be.
Resistive screens are pressure sensative, and by design can't handle multi-touch.
Capacitive screens use glass coated with a conductive coating. The edges of the screen are connected to conducters. Each conducter has a different frequency oscilator connected.
The capacitance of a human finger changes the impedance of the screen, and so changes the frequency of the oscillator circuit. This gets converted to distance from each oscillator and so a co-ordinate.
The resolution is limited by how acuratly you can detect changes.
Typically in electronics very small changes are hard to measure because they are indistiguishable from noise.
Capacitive screens can handle multi-touch, but the resolution of each touch is decreased in that case.
Capacitive screen resolution is not absolute and can change with increased noise in the system, or by multiple capapcitive effects on the screen - like multiple touches.
Seriously consider donating something like $1 if you want software from me to continue, as johnpatcher had suggested.
This was originally built to flatten the brightness levels between AC and BATT on the Kaiser, but since lacking a workable front-camera API access, this works out better on devices with a light sensor.
/// new Acer m900 support
Since this device has only 3 auto-brightness settings, a full sensor-to-backlight curve is used -- configurable in HKCU/SOFTWARE/Creative 'Ware/LevelSight/0-a -- to map the 11 brightness settings actually available.
Brightness levels to about 4 have been hand-tuned and then it's a linear scale to max brightness.
Currently, the settings are loaded only on service startup, restart the service (through dotfred TaskMgr) if you want it to reload the registry settings
///
1.0.3.x: <HTC>Remember to CLICK OFF your auto-backlight setting.<HTC>
Uses HKCU\SOFTWARE\Creative 'Ware\LevelSight\offset to adjust the native backlight setting. It defaults to -1 so it'll pick a setting 1 less than what the system would've automatically set. If you set it to 0, it'll pick the same as auto, and so on. Behavior is the same as pre-1.0.3.x when backlevels fall below low_wm, but switches to offset mode when levels rise above high_wm.
More gui ability to adjust these settings is coming.
/// pre-1.0.3.x
<HTC>All this does is TURNS OFF the auto-backlight whenever reported light levels drop below low_wm using a custom 1st order low-pass algorithm. When turned off, the backlight falls back to whatever you have your AC/BATT light levels set to in your control panel. This solves the issue of the auto-backlight not dimming below backlight level 3.
When light levels rise above what the light sensor API thinks should be backlight level high_wm, it uses the auto-backlight settings again, and lets it auto-adjust as was usual.<HTC>
///
It is however not perfect due to the low accuracy of the sensor at low light levels, but does try to ignore the random unexplainable surges in the sensor readings when light levels are constant. It's probably a reason why ODMs don't bother to try to make auto-backlight work any lower.
Thanks originally to Koush for his LightSensor SDK reference as well as Scott Seligman for the C++ reference.
Advantages:
works with native OEM backlight without extra .NET layer
history-less sensor-data filtering
Native C++ and assembly, floating-point-less DSP/SIMD-accelerated math, and extra optimization analysis in Ida Pro.
No CPU/power-sucking .NET, nor the standard/default software floating-point emulation used.
takes 1K of ram, 22K of storage
0 process slots (runs as a service)
no notable power-draw (same amount of power ~53mA with service on/off on Fuze)
polls every ~2000 milliseconds
no HTCSensorSDK sensor-data lag (~200-300 ms) nor cpu load -- directly accesses the sensor driver
dll and supporting code are compressed independently of .cab and use cpu's smaller Thumb (16-bit) code when advantageous
mostly lockless multi-threading
HKCU/Software/Creative 'Ware/LevelSight:
offset: adjusts backlight levels positive or negative of oem-pick
low_wm: fuzzy point where it low-light auto-backlight (2 is default recommendation)
high_wm: fuzzy point where offset auto-backlight will turn on (5 is recommendation)
Tested with stock Fuze rom, and Acer m900 160-lite rom.
Release Notes:
-current(1.1.0.x series)
1.1.0.2: fix bug where max backlight was clamped to level 5. It now uses the full 1-10 (10 levels) range. Level 0 disabled because not useful.
1.1.0.1 2009.09.04: full-backlight enhancement for Acer m900 ONLY!! Backport to FUZE whenever.
Acer 900s version abandoned because of Clove Technology.
-stable(1.0.3.x series)
1.0.3.2 2008.02.19: full-backlight replacement
-obsolete(1.0.2.x series)
1.0.2.1 2008.12.03: reset hysteresis on backlight power-state edge
1.0.2.0 2008.12.03: hysteresis now using first-order low-pass filter with a medium α; math and power-state optimizations
obsolete (1.0.1.x series) LevelSightSvc.1.0.1.1.CAB (11.8 KB, 132 views)
1.0.1.1 2008.11.24: work-around for service not starting up when device is rebooted; tweaked hysteresis
1.0.1.0 2008.11.21: converted into a service with registry configurable water marks
1.0.0.3: better hysterisis
1.0.0.2 2008/11/16: Previous version tended to like it dark and resisted turning it up.
Adjusted dark/light sensitivity so it switches auto-off at light sensor 3::3, and switches it back on at 3::5. Still playing with this to get a better hysteresis.
Thank you Sir! That's exactly the kind of app I was waiting for. From what it sounds like I much prefer your solution over G-Light! I will test it right away!
NuShrike, the app doesn't seem to work for me. I've installed it and did a soft reset afterwards (just to make sure) but the backlight still never falls below level 3. In my AC/Batt settings I have the backlight auto configuration enabled and did also try to disable this with the same result.
Am I making some mistake?
I'm really looking forward to get this sorted out because I love the idea of your app!
same here! tried it with duttys rom
Same issue with stock fuze rom. Definitely looking forward to this app.
I just analyzed the running processes after soft reset and the app is not running even tough it is placed in startup. so I just tryed starting the process manually but even when it's running it is not working
Great idea, but does not work consistently. I've tried to narrow it down to a repeatable scenario, but have not been successful. I can see the LevelSight.exe process running (BTW, it takes approx 2.4% of my cpu every three seconds, then idle for three seconds.) LevelSight initially appears to work as designed, but after a few light cycles, it stops enabling the auto adjust setting.
Just did some more testing. If I go in and manually enable auto adjust (in Power settings) it will work as long as the light level is high. Then when light level is low, LevelSight will disable auto adjust (setting backlight level to what I have it set to) but never reenable auto adjust (no matter how bright the ambient light.) So it seems to half way work, it does consistently disable auto adjust but it never enables it.
More testing. Seems that if I let the phone dim the backlight all the way to dark setting (30 seconds) and hit it with bright light before it goes to sleep, LevelSight will enable the auto setting and the light will come up. This might cause a problem with the auto dim. Hmm, still playing.
Okay, I've tried playing with the turn-on trigger a bit to see if that helps. It was programmed in the dark with a flash-light and now just tested in the sun today.
Version 1.0.0.2 is a little better at turning auto-back on, but may be still be not quite "right" in my experience.
Here's an interm version to get it more usable while I try to find the better "fuzzy" logic for the trigger.
TheMostToys: How are you measuring CPU usage? I'm using TaskManager and it's showing cpu in the range I described.
DeepThought: do you have HTCSensorSDK.dll in your \Windows? I assume a Raphael rom is built mostly the same as a Fuze's so I'm not sure why else it's not running for you. It will refuse to run more than one at a time also, and soft-reset may clear up the self-lock if that's the problem. If not, I'll post up a debug app to see what's going on.
My Fuze did get all app security turned off so I may not be properly triggering the needed security dialogs.
NuShrike said:
TheMostToys: How are you measuring CPU usage? I'm using TaskManager and it's showing cpu in the range I described.
Click to expand...
Click to collapse
I'm using Memmaid. Also tried SKTools with similar results.
BTW, I'm not overly concerned with the current CPU usage, just noticed a difference and thought I'd let you know, in case it helped narrow down the problem.
Much better hysteresis with 3-point history.
Resists going dim, but will still do so in ~9 seconds if ambient stays dark.
Does not work
Hi, NuShrike, nice app, but does not work for me.
The problem is that in the full darkness the signal level from light sensor on my TP is falling under 7, but then slightly increasing till 7.26 (according to G-Light measurement) and stay constantly at 7.26 forever!
Since screen is dimmed and then lighting up to the level 3 again!
Is it possible to change the bound from 7 to 8 or make an ability to adjust it personally through some config file or command line parameter?
I suppose it might be useful to the people who have very little sensor signal in the darkness, too.
Vladimyr said:
Hi, NuShrike, nice app, but does not work for me.
The problem is that in the full darkness the signal level from light sensor on my TP is falling under 7, but then slightly increasing till 7.26 (according to G-Light measurement) and stay constantly at 7.26 forever!
Since screen is dimmed and then lighting up to the level 3 again!
Is it possible to change the bound from 7 to 8 or make an ability to adjust it personally through some config file or command line parameter?
I suppose it might be useful to the people who have very little sensor signal in the darkness, too.
Click to expand...
Click to collapse
I think your 7.26 is the calculated lumen value that G-Light may be using out of the .net SDK.
I'm not using that SDK, but basing off the raw values coming from the light sensor almost directly. I can add build some registry entries to allow some tweaking because maybe each TP reads differently.
So holding your thumb over the light-sensor and the backlight still goes back up to 3?
NuShrike said:
So holding your thumb over the light-sensor and the backlight still goes back up to 3?
Click to expand...
Click to collapse
Yes, right. Right now after my thumb covered light sensor it is dimming to 1, then after a few seconds it's back again on 3!
G-Light is deactivated this time, but when I start it showing 4.52 immediately after covering sensor, and 7.26 a few seconds later.
NuShrike said:
I can add build some registry entries to allow some tweaking...
Click to expand...
Click to collapse
Yep!!! Please! Do it!
download it and will try .
Okay, I've verified that LevelSight stops running after a full-night's sleep. I'll see if the conversion to a service will keep it running.
Vladimyr said:
Right now after my thumb covered light sensor it is dimming to 1, then after a few seconds it's back again on 3!
Click to expand...
Click to collapse
Exactly the same for me.
NuShrike said:
Okay, I've verified that LevelSight stops running after a full-night's sleep. I'll see if the conversion to a service will keep it running.
Click to expand...
Click to collapse
I look forward to the next version, thank you for your efforts!
Now converted into a Service and runs under service.exe.
Registry configuration for fuzzy low and high water marks for turning auto-backlight on/off in
HKCU/Software/Creative 'Ware/LevelSight:
low_wm: ambient level where auto-backlight turns off
high_wm: ambient level that triggers auto-backlight on
Also, light sensor I2C device driver is now directly accessed so HTCSensorSDK is no longer used nor required removing a battery/cpu sucking layer.
The problem did not exist in fact
It seems i understood the reason of program "malfunction".
It was caused that i did not read decription carefully:
NuShrike said:
When turned off, the backlight falls back to whatever you have your AC/BATT light levels set to in your control panel.
Click to expand...
Click to collapse
But i had default backlight level set on 4! Thus, when ambient illumination was dropping under level 3, auto-backligh was turned off and backlight was increased to 4
Not i set default level to 2 and all is working well!
Is there a setting in Andorid to make the touch pressure more sensitive. I recall do registry edits in WinMo that accomplished this. The screen in Android just seem to require more pressure then what I remember having WinMo set to.
It also could be that I'm just use to capacitive screens.
Thanks
gedster314 said:
Is there a setting in Andorid to make the touch pressure more sensitive. I recall do registry edits in WinMo that accomplished this. The screen in Android just seem to require more pressure then what I remember having WinMo set to.
It also could be that I'm just use to capacitive screens.
Thanks
Click to expand...
Click to collapse
ADB/Terminal:
echo "3072" > /sys/module/tsc2003/parameters/sensitivity
I've tried it and I could mess it up enough for it to noticeably lower sensitivity but I could never tell if it actually increased it (but it probably did).
Edit: One thing I noticed is that I could never get the settings to stick beyond a reboot.
lightly touching during screen calibration seems to work.
I was having a similar issue with "touching like you mean it" to get things to work. I tried re-running the calibration tool and pressing with the stylus as light as i could and still get a reading. its not like my incredible, but it is silky smooth.
Last week I have released the Screen Dimmer kernel modification. While the feedback was very positive, it became clear that this mod had the limitation that the FLAG_KEEP_SCREEN_ON (set in apps, which prevents the screen lock from activating) was not preventing Screen Dimmer from blanking the screen. So if you wanted to watch a movie and did not want the screen to be dimmed all the time, you had to manually deactivate the Screen Dimmer for this period and re-enable it afterwards. Also the battery drain while the screen was dimmed was much higher compared to a proper screen lock, since only the display and the access to the framebuffer was disabled - the other hardware was still enabled and most importantly the Android OS and the apps were still running.
I thought that I could do better than that and tried to find a way to achieve the same what Screen Dimmer was doing without running into its limitations. Since the Android OS power manager handles the FLAG_KEEP_SCREEN_ON and also suspends the OS and running apps on a screen lock, I thought why not letting the power manager do its jobs and just prevent the touch controls (screen and keys) from suspending. Then one could wake the device from screen lock by emulating a power button press on touch. After a user defined delay after screen off the touch controls also get suspended. The only complication was to monitor the power button, so one can differentiate between screen timeouts, for which the touch controls should be kept enabled for a certain time, and a screen lock manually triggered by the user by pressing the power button, for which the touch controls should be disabled right away.
So with Touch Wake, one can wake the device from suspend (for a certain user-defined time after screen off) by touching the touchscreen or the touchkeys. Combined with a OS level tweak which disables the lock screen on timeout for a certain time or altogether (for example in CM 7.03, but also available as standalone apps from the Market), one can achieve the same functionality as Screen Dimmer. Compared to Screen Dimmer, Touch Wake has the advantage that the screen will not be blanked as long as the FLAG_KEEP_SCREEN_ON is set and also the battery drain while the screen is off will be significantly less because only the touch controls are kept enabled and the Android OS and running apps are properly put to sleep. For the record, with Touch Wake, while the touch controls are still enabled, the kernel is kept in a wake lock, so the battery drain will still be a little higher than for the normal stock screen lock, however it is a significant improvement over Screen Dimmer.
To enable (disable) wake on touch pass 1 (0) to 'enabled' in /sys/class/misc/touchwake. Pass the delay (until the touch controls will be disabled after screen off) in ms (this is milliseconds; 1000ms = 1s) to 'delay'; a value of 0 for the delay means the touch controls will be kept enabled indefinitely. The default state is disabled and a delay of 45000 = 45s.
Changes to the source (based on kernel with BLD 3 and Screen Dimmer 1):
http://www.pastie.org/2445282
BUGFIX:
Fixed BLN not working properly anymore.
Bug fix: http://www.pastie.org/2446398
BUGFIX #2:
Fixed the problem with the proximity sensor not reactivating the screen when making calls. Also, since I was in the neighborhood I also fixed the problem with BLD on the i9023.
Bug Fix: http://www.pastie.org/2457092
BUGFIX #3:
I cleaned up the code a bit for all three mods BLD, Screen Dimmer and Touch Wake.
Bug fix: www.pastie.org/2488785
BUGFIX #4:
Fixed the BLD problem for the i9023 of the touchkey backlights not being re-enabled on touchkey press.
Bug fix: http://www.pastie.org/2499956
BUGFIX #5:
Fixed the problem of the touch controls misbehaving after the proximity sensor has blanked the screen during a call.
Bug fix: http://www.pastie.org/2528577
BUGFIX #6:
Fixed the problem with BLD on the i9023 of the touchkey backlights getting activated when the bottom of the touchscreen was touched.
Bug fix: http://www.pastie.org/2544546
BUGFIX #7:
For Touch Wake, call the suspend function a bit earlier to prevent a rare hiccup happening when the touch controls are pressed in exactly the same moment the screen is disabled.
Bugfix: http://www.pastie.org/2641540
BUGFIX #8:
For BLD, Screen Dimmer and Touchwake, use mutex_trylock instead of mutex_is_locked/mutex_lock combo to avoid race conditions.
Bugfix: http://www.pastie.org/2710096
No further patches will be published here. I have set up a git repo for all my tweaks. Each mod has its own branch to keep the tweaks cleanly separated and one can simply pull the latest patches from the corresponding branch.
https://github.com/Ezekeel/GLaDOS-nexus-s/tree/touchwake
Get Jonathon Grigg's 'Spark Mod Manager' GUI for controlling Touch Wake: http://forum.xda-developers.com/showthread.php?p=17291034
I do not accept donations and since I reached my 50GB limit of free space on SpiderOak, thanks to all of you kind people who got an account using my referral link, I could not ask for more.
Instead if you really want to donate your hard earned money to someone who deserves and needs it, consider donating to the Free Software Foundation at fsf.org: These guys are at the frontline when it comes to keeping Linux free and fighting these greedy bastards who think they are entitled to collect royalties and other fees from Linux users due to some silly patents - and if Linux falls, Android will be next.
Does this depend on screen dimmer code? Cause I'd like to maybe remove screen dimmer and just have this mod.
Also, thanks for putting all this time on these mods. Love your work.
Sent from my Nexus S using xda premium
The patch file I have provided is for a kernel already including BLD 3 and Screen Dimmer 1 (+ all bugfixes), but the code of Touch Wake does not depend on either Screen Dimmer or BLD - so you can enable BLD, Screen Dimmer and Touch Wake independently from each other in the kernel config and also could remove one tweak entirely from the kernel source if you want.
Can you stop copy pasting this "couldn't reach morfic"
That would be awesome.
Sent from my Nexus S using Tapatalk
Fixed BLN not working properly anymore.
Bug fix: http://www.pastie.org/2446398
This sounds amazing.
Probably the biggest "mod" to our phones since BLN.
If the battery drain isn't terrible with this mod, I think you have a winner on your hands.
Goodjob.
EDIT: Think you should make an app that allows users to easily change the values. I could see this catching on as much as BLN has.
Bump sounds ballin
Sent from my Nexus S 4G using xda premium
works great!
pinned a shortcut to the on/off script onto my homescreen using gscripts. one press turns it on, second press turns it off..
expr "(" $(cat /sys/class/misc/touchwake/enabled) - 1 ")" \* -1 > /sys/class/misc/touchwake/enabled
Click to expand...
Click to collapse
morfic said:
Can you stop copy pasting this "couldn't reach morfic"
That would be awesome.
Sent from my Nexus S using Tapatalk
Click to expand...
Click to collapse
I think those are deleted already. lol.
cool stuff.
so... I presume, when the screen dimmed. the crt animation will appear as well ?
and to mr simms and mr reddv1 , can i have ur test kernel included this TouchWake MOD for any ROM since i used MIUI ROM
Sounds like an awesome mod
Sent from my Nexus S using XDA App
what is this kernel??? the file touchwake there isn't in my rom.
please help me.
tonno16 said:
what is this kernel??? the file touchwake there isn't in my rom.
please help me.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=17104132
Fixed the problem with the proximity sensor not reactivating the screen when making calls. Also, since I was in the neighborhood I also fixed the problem with BLD on the i9023.
Bug Fix: http://www.pastie.org/2457092
Ezekeel said:
Fixed the problem with the proximity sensor not reactivating the screen when making calls. Also, since I was in the neighborhood I also fixed the problem with BLD on the i9023.
Bug Fix: http://www.pastie.org/2457092
Click to expand...
Click to collapse
Thanks for the quick fix. Is this a combined bugfix for proximity sensor and i9023 bld?
Sent from my Nexus S using xda premium
Yeah, they both needed modifying of include/linux/input.h and instead of having two patch files in two different threads which would need to be applied in a certain order I decided to simply make one patch for both problems and put it in this thread. It does not make a difference for you guys and if later people want to include this in their kernel they probably simply pull the up-to-date files from my git instead of applying these gazzilion patches one after each other.
Hope this really fixes the problem with the i9023. I had to guess what the problem was and if this does not solve it, I am all out of ideas. Unfortunately, I do not know anyone with a i9023 I could borrow. The next best thing would be to get someone on gtalk or similar with a i9023 who is willing to go through a painful process of flashing a test kernel with debug statement and passing the logs on to me, then wait until I have compiled the next test kernel... rinse and repeat - lets say about ten times. Not really looking forward to this.
If it will be nessecary I can help on Google Talk. But I'm not capable to compile kernel. If we go for this, you have to send me flashable zip
Using Touch Wake right now with the Lucid kernel and it works perfectly.
Not sure if this is possible, but here's my idea:
Is it possible to somehow wake the phone through touching the touch keys when BLN is active (as in touch keys are on)?
I thought of this as you said that the touch keys (and screen) are not suspended when Touch Wake is active. So now I'm going further to assume that maybe the touch keys are also not suspended when BLN is active so that maybe it can be coded to allow touching the keys to wake the phone?
I know nothing about programming so I may be talking out of my ass here but just an idea.
Thanks!
I think I found a bug with Touch Wake. I'm on 9020, with latest touch wake bugfixes.
After the screen goes off and the touch wake timer has passed, if I touch the soft keys they light up and stay lit while the phone sleeps. I tried to grab a logcat with the phone plugged in to my PC, but the bug can't be replicated while the phone is plugged in.
Sent from my Nexus S
reddv1 said:
I think I found a bug with Touch Wake. I'm on 9020, with latest touch wake bugfixes.
After the screen goes off and the touch wake timer has passed, if I touch the soft keys they light up and stay lit while the phone sleeps. I tried to grab a logcat with the phone plugged in to my PC, but the bug can't be replicated while the phone is plugged in.
Sent from my Nexus S
Click to expand...
Click to collapse
It seems having bln installed (and disabled for me) solves this
Enhanced said:
Using Touch Wake right now with the Lucid kernel and it works perfectly.
Not sure if this is possible, but here's my idea:
Is it possible to somehow wake the phone through touching the touch keys when BLN is active (as in touch keys are on)?
I thought of this as you said that the touch keys (and screen) are not suspended when Touch Wake is active. So now I'm going further to assume that maybe the touch keys are also not suspended when BLN is active so that maybe it can be coded to allow touching the keys to wake the phone?
I know nothing about programming so I may be talking out of my ass here but just an idea.
Thanks!
Click to expand...
Click to collapse
I would be possible, however this could lead to the possible problem of accidentally unlocking the device when you carry it around in a pocket and get a notification. I do not think it is worth the trade-off
reddv1 said:
I think I found a bug with Touch Wake. I'm on 9020, with latest touch wake bugfixes.
After the screen goes off and the touch wake timer has passed, if I touch the soft keys they light up and stay lit while the phone sleeps. I tried to grab a logcat with the phone plugged in to my PC, but the bug can't be replicated while the phone is plugged in.
Sent from my Nexus S
Click to expand...
Click to collapse
I cannot reproduce the problem with my reference kernel. Does it happen every time you try it?
Is there any possible way to increase the sensitivity of the htc one's capacitive screen? I have used the S3 until now and the screen was much easier to run my fingers on. I tried playing with the calibration tool but I can't tell any differences. Help me out guys. Thanks!