This is for kernel devs only. The patch itself is useless to those who do not/can not compile their own kernel.
This was a pretty big hit on some other devices so I figured I'd give it a shot for you guys. This allows one to force AC charging for any charger that is detected as USB (e.g. many car chargers) and pull the full current the charger can support. It also provides additional security when connecting to public charging stations because by forcing AC charging, USB/adb data transfers are disabled, protecting your data.
It is essentially a software version of the modified charge only usb cables.
Fast charge can be toggled by issuing:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
and off:
echo 0 > /sys/kernel/fast_charge/force_fast_charge
In addition I have created a toggle fast charge widget that may be used to toggle fast charge on and off right from your home screen:
https://play.google.com/store/apps/details?id=com.incredicontrol.fastchargewidget
I have also implemented a toggle in IncrediControl (free) that will allow you to turn it on and off.
https://play.google.com/store/apps/details?id=com.incredicontrol
For the widget (or any fast charge toggle) to work, you MUST be running a kernel that has this patch implemented.
As a good gesture to support a fellow dev, I ask that if you implement the patch into your kernel, please link to my widget as one means to toggle it. You are of course free to provide other ways to toggle it as well if you so desire.
Kernel devs, if you would like to test the widget yourself to confirm its working, and for convenience of testing, please contact me and I will provide you with a copy. You must show that you are a kernel dev though (i.e. link me to your kernel post so I can match your username).
Good luck have fun!
http://www.incredikernel.com/wp-con...wnload.php?id=shooter_force_fast_charge.patch
Thank you to those who tested for me.
chad0989 said:
This is for kernel devs only. The patch itself is useless to those who do not/can not compile their own kernel.
This was a pretty big hit on some other devices so I figured I'd give it a shot for you gys. This allows one to force AC charging for any charger that is detected as USB (e.g. many car chargers) and pull the full current the charger can support. It also provides additional security when connecting to public charging stations because by forcing AC charging, USB/adb data transfers are disabled, protecting your data.
It is essentially a software version of the modified charge only usb cables.
Fast charge can be toggled by issuing:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
and off:
echo 0 > /sys/kernel/fast_charge/force_fast_charge
In addition I have created a toggle fast charge widget that may be used to toggle fast charge on and off right from your home screen:
https://play.google.com/store/apps/details?id=com.incredicontrol.fastchargewidget
I have also implemented a toggle in IncrediControl (free) that will allow you to turn it on and off.
https://play.google.com/store/apps/details?id=com.incredicontrol
For the widget (or any fast charge toggle) to work, you MUST be running a kernel that has this patch implemented.
As a good gesture to support a fellow dev, I ask that if you implement the patch into your kernel, please link to my widget as one means to toggle it. You are of course free to provide other ways to toggle it as well if you so desire.
Kernel devs, if you would like to test the widget yourself to confirm its working, and for convenience of testing, please contact me and I will provide you with a copy. You must show that you are a kernel dev though (i.e. link me to your kernel post so I can match your username).
Good luck have fun!
http://www.incredikernel.com/wp-con...wnload.php?id=shooter_force_fast_charge.patch
Thank you to those who tested for me.
Click to expand...
Click to collapse
woot! this will come in very handy, has this been compiled into your Anthrax kernels?
bitslizer said:
woot! this will come in very handy, has this been compiled into your Anthrax kernels?
Click to expand...
Click to collapse
Wrong Chad. Haha.
Chad.goodman does have a type of fast charge support in his Anthrax kernels to answer your question.
Hey buddy! I was pretty hell bent on flashing beta 6 to my Rezound but Wolf just informed me that it may have been for Gingerbread.. Which would explain why I can't make it work lol. I look at the Incred. site but couldn't find any more info regarding the Kernel. Is there a way I can make this work with them latest ICS leak? Neo < Tiny < Chad so I don't have the know how.
Tossed you some coin (literal pocket change) for the fast charge widget btw Thanks for that
- Neo
IAmTheOneTheyCallNeo said:
Hey buddy! I was pretty hell bent on flashing beta 6 to my Rezound but Wolf just informed me that it may have been for Gingerbread.. Which would explain why I can't make it work lol. I look at the Incred. site but couldn't find any more info regarding the Kernel. Is there a way I can make this work with them latest ICS leak? Neo < Tiny < Chad so I don't have the know how.
Tossed you some coin (literal pocket change) for the fast charge widget btw Thanks for that
- Neo
Click to expand...
Click to collapse
Haha, yeah, rezound beta6 is GB only. Waiting on the ICS source to drop. I'm pretty confident I could make a working ICS kernel for the rezound by using the vivid ICS kernel as a base, but I haven't had the time to really work on it. Hopefully soon though.
I'm not personally of the ability to incorporate this into anything, but I would appreciate any ROM/Kernel that does. This is something I desperately need for my car.
Felnarion said:
I'm not personally of the ability to incorporate this into anything, but I would appreciate any ROM/Kernel that does. This is something I desperately need for my car.
Click to expand...
Click to collapse
PM me with the name of the kernel you currently use and I'll send you something for the time being while you wait.
Sent from my ADR6425LVW using XDA
I think most people are rocking the anthrax kernel.
chad0989 said:
PM me with the name of the kernel you currently use and I'll send you something for the time being while you wait.
Sent from my ADR6425LVW using XDA
Click to expand...
Click to collapse
I appreciate the offer.
I'm currently bouncing between two ICS ROMs, and touching anything within those is probably a bad idea, since they already have enough issues. I'm speaking more in a general sense that, if this is a good mod and definitely works, then it'd be awesome to see all kernel devs incorporate it into their builds.
wachalookinat said:
Read the post above mine dumbass.
Click to expand...
Click to collapse
He said for you to PM him therefore you were somewhat in the wrong. By the way not everybody runs the Anthrax kernels cause I don't.
Also name calling won't get you anywhere except a step towards getting banned from XDA.
私のEVO 3Dから送信される。
Hi i've ported fast_charge to my kernel but
how it is made adds this "/sys/kernel/fast_charge" directory to the kernel?
if itry to change the value with
echo 1 > /sys/kernel/fast_charge/force_fast_charge
in the terminal, but the terminal output this error: sh: cannot create /sys/kernel/fast_charge/force_fast_charge: No such file or directory
how it is made?
Guys my kernel, MAC kernel, has this.
I'm actually testing my next release with fast charge v3.1
http://forum.xda-developers.com/showthread.php?t=1767568
Nice work Chad :thumbup:
CastagnaIT said:
Hi i've ported fast_charge to my kernel but
how it is made adds this "/sys/kernel/fast_charge" directory to the kernel?
if itry to change the value with
echo 1 > /sys/kernel/fast_charge/force_fast_charge
in the terminal, but the terminal output this error: sh: cannot create /sys/kernel/fast_charge/force_fast_charge: No such file or directory
how it is made?
Click to expand...
Click to collapse
I think he ask for learning build kernel...
Sent from my PG86100
MikeC84 said:
Guys my kernel, MAC kernel, already has this.
Click to expand...
Click to collapse
Thanks, but that has nothing to do with the OP's release. Unless, of course, your thread gives me a similar adaptive patch; and if that's the case, sweet.
found myself the solution,
in the fastchg.c missing this include:
#include <linux/module.h>
Related
I have no idea if this will be of any use to anyone or not, but I figured I'd share anyway. I came up with a seemingly functional replacement for the Fascinate Atlas [ED01] Broadcom BCM4329 wireless driver that is 100% certain not to have the "Hotspot Monitoring" feature, and should eliminate any issues with the /lib/modules/dhd.ko module as it's in-built as part of the kernel now.
Unlike what I did for EC10, which worked but took a lot longer to do, this is a pretty quick and easy source mod. It's stock i500 ED01 for everything but the hotspot (wlioctl.h/wl_iw.h/wl_iw.c) code, which is stock i9000-update2, sans a certain "roaming" feature. The end result seems to work. Support for the actual VZW 3G hotspot app is all but guaranteed to be dead and buried, but the latest android-wifi-tether 3.0pre12 in infrastructure mode worked great, so I think it's pretty close to good, if not actually there.
Application:
- Remove the insmod lib/module/hotspot_event_monitoring.ko from init.rc
- Remove the hotspot_event_monitor.ko from lib/modules in your INITRAMFS
- Remove the dhd.ko from lib/modules in your INITRAMFS
- In your xxxxx_defconfig, remove (or comment out) CONFIG_BROADCOM_WIFI_ATLAS=y and make sure CONFIG_BROADCOM_WIFI is set to "m"
- Replace drivers/net/wireless/Makefile and drivers/net/wireless/bcm4329 with the contents of the linked .TAR below
- This should generate a dhd.ko instead of hotspot_event_monitoring.ko in drivers/net/wireless/bcm4329. Put that in your INITRAMFS::lib/modules instead of whatever stock dhd.ko you have. [Having the dhd.ko to include with a build is quite nice compared with using some stock driver IMO]
- Let me know if it doesn't work ... and what you tried ... I can always go ahead and do another manual merge like I did for EC10
edit: You'll also want to strip the debug symbols from the dhd.ko that's generated, it's huge. I've been doing a make modules then copying out/stripping the .ko files for initramfs before finisihing with the regular make.
MOD Source Download (.TAR)
Link to my GitHub commit for this particular change (don't trust my GIT, look at jt1134's or imnuts' GIT for things that matter!)
Anyway, if this helps you out, awesome. If you apply it and your WiFi gets boned up, please let me know and I will try to recreate. If you apply it and your phone catches on fire and dies a slow and painfull death I have no idea who you are or what you're talking about
Cannot seem to get this working for me.
make: Warning: File `drivers/net/wireless/bcm4329/Kconfig' has modification time 1.8e+04 s in the future
error repeats
Didn't Adryn or someone else fabricate a fake version of the 3G Hotspot event monitoring file that basically is still there but doesn't actually monitor our hotspot or tethering usage?
I've been using that and been wireless tethering using that recent app in the Themes section. Hopefully im pretty safe because ive been using that app a decent bit and its been working perfect.
nemesis2all said:
Cannot seem to get this working for me.
make: Warning: File `drivers/net/wireless/bcm4329/Kconfig' has modification time 1.8e+04 s in the future
error repeats
Click to expand...
Click to collapse
I'd guess that whatever you extracted the archive with, also updated the files with what their modification time when they were archived. 1.8e+04 seems to be 5 hours, so it's likely due to you and djb having different timezones (or, one of you not knowing how to set your clock with NTP ).
Whatever you used should have an option to not preserve the timestamps, so you could just redo with that option... alternatively, you could wait 5 hours.
Syn Ack said:
Didn't Adryn or someone else fabricate a fake version of the 3G Hotspot event monitoring file that basically is still there but doesn't actually monitor our hotspot or tethering usage?
I've been using that and been wireless tethering using that recent app in the Themes section. Hopefully im pretty safe because ive been using that app a decent bit and its been working perfect.
Click to expand...
Click to collapse
He did, so you can be 'safe', but you still got parts of that monster in the wireless driver's code & the dummy monitor as well (no doubt that samsung's modifications to the wireless driver are quite low quality, like everything else they seem to do in the kernel).
I'm not sure what app you're using, but, using Wireless Tether or anything else not from Verizon should be safer (not to imply that using the 3G Hot Spot with the monitor removed is dangerous- but from what I've heard, take with a grain of salt, doing the hack to get free tethering with the verizon app puts some possible traces on your account that might suggest you're doing it).
I use a combo of that dummy monitor and the Wireless Tether app.
is this a full kernels or just a mod for which ever kernel you are using
evilclosetmonkeynate said:
is this a full kernels or just a mod for which ever kernel you are using
Click to expand...
Click to collapse
This is a mod for kernel developers.
Yeah, just a modification to the existing code base for developers. Looking at everyone else's stuff it seemed that the norm was to remove the nasty bits from the existing driver. I tried using the i9000 wireless driver as-is and it worked fine, so my concept was just to replace the access point stuff completely but keep any changes made to the core driver code.
Sorry about the timestamp thing nemesis! My Linux experience is extremely limited (you should see me struggle with Git, it's almost laughable the bad things I've done to myself)
While I am "working on" a full kernel, it's primarily just for my own education. If I want to be able to contribute to these efforts I have a LOT of catching up to do. My personal goal is a "Stock+" kernel that works but doesn't include all the little tweaks and modifications available from the main developer's kernels. I'll put it this way -- at the end of the day I flash somebody else's kernel back onto my phone
djp952 said:
Yeah, just a modification to the existing code base for developers. Looking at everyone else's stuff it seemed that the norm was to remove the nasty bits from the existing driver. I tried using the i9000 wireless driver as-is and it worked fine, so my concept was just to replace the access point stuff completely but keep any changes made to the core driver code.
Sorry about the timestamp thing nemesis! My Linux experience is extremely limited (you should see me struggle with Git, it's almost laughable the bad things I've done to myself)
While I am "working on" a full kernel, it's primarily just for my own education. If I want to be able to contribute to these efforts I have a LOT of catching up to do. My personal goal is a "Stock+" kernel that works but doesn't include all the little tweaks and modifications available from the main developer's kernels. I'll put it this way -- at the end of the day I flash somebody else's kernel back onto my phone
Click to expand...
Click to collapse
It is all good still appreciate your work. I have never seen anything like that. Just thought it included some bits needed for my DeLorean to go back to the future.
so, i am just speculating here, but does this imply that bluetooth (and other) drivers could be pulled from i9000 sources as well (say that GB drop that just hit) and backported to i500 kernels?
or is this simply wishful thinking?
Thank you for your hard work hope to see this in future Kernels
Sent from my SCH-I500 using XDA App
godihatework said:
so, i am just speculating here, but does this imply that bluetooth (and other) drivers could be pulled from i9000 sources as well (say that GB drop that just hit) and backported to i500 kernels?
or is this simply wishful thinking?
Click to expand...
Click to collapse
Anything is possible, as long as the hardware is actually the same (or close enough) on the i9000 and it doesn't need anything unique to the GB kernel. It certainly won't hurt to diff the code when it's available to see how close it is.
Have you been doing any more testing on this. I am interested in putting it in my kernels just want to make sure it won't cause any issues.
nemesis2all said:
Have you been doing any more testing on this. I am interested in putting it in my kernels just want to make sure it won't cause any issues.
Click to expand...
Click to collapse
Yes, as of android-wireless-tether 3.0pre14 I haven't had any issues at all with it. 3.0pre12 was throwing a fit every now and again, but apparently that was a common malady with that version. Note also that I have NOT tested the Verizon 3G hotspot app with this driver, my assumption is that it will not work. Which leads me to ...
I also have a less aggressive solution that may allow the VZW app to work you could have if you want, it's basically the same thing with the updated SOFTAP changes from the i500 applied to the i9000 driver as well. (This basically makes it amount to just carving out the hotspot and producing a new dhd.ko during a build so we don't have to use the pre-compiled one from the ramdisk)
You can find the alternate version of the driver on my github, in the src/wip directory of the sch-i500-kernel repo:
https://github.com/djp952/sch-i500-kernel.git
LMK if you run into problems
UPDATE
Due to unforeseen issues with this build and a plethora of people incapable of reading even simple notes, this release is being pulled while we work out some issues with our own internal testers.
Thank you.
Kernels. The final pain in the arse. These are the voyages of the dev team Ninphetamine. Our continuing mission, to break strange new code. To seek out new bugs and strange implementations. To boldly go where no phone has gone...before.
*cue musical score*
It's been some time since I last graced the Android community. Draped in the success of FroydVillain 1.5, empowered from my victories over Froyo's poor (and non existent) AOSP implementation for the HTC Hero, onward I charged into the task of dragging the ancient kernel of the Hero into the 21st century. However, after seeing how HTC are as likely to stick to recommended kernel practices as I am likely to win a Miss Universe contest, (This is highly unlikely and the least significant reason is that I am not female.) I buckled like a jet fighter made from tin foil and surrendered faster than an agoraphobic Frenchman. There has been some advances into more modern kernels for the Hero but as I predicted they're still plagued with issues, all of which can be blamed squarely on HTC.
It took some major rehabilitation to get me back into the Android development scene, a key factor in that rehab being the ownership of a Samsung Galaxy S. A delightful phone, still in my opinion the best single core Android phone that money can buy. Beautiful screen, fast, elegant and excellent on battery. It nursed me through those dark days of waking up in cold sweats with github commits circling through my head, kernel debug symbols blinking in the dark of the night like Vietnam flashbacks, breaking down into incoherent rants on IRC development channels ending eventually with "YOU WEREN'T THERE MAN, YOU JUST DON'T UNDERSTAND, HTC WILL COME AND GET YOU EVENTUALLY, THEN YOU'LL KNOW". Oh how I longed to find a high up HTC developer in a bathroom to blow them away before ending my own bitter misery. Alas, it was not to be.
After a successful tour of duty as a regular non developing user on the Samsung Galaxy S, I treated myself to a brand new and shiny Samsung Galaxy S II. As soon as I used the device and checked out the available source code for it, I knew I was ready, I knew I was fully recovered to be able to break free from the oppression of HTC, I knew that I was capable to step once more unto the breach and step back into Android development. The stage set, the orchestra struck...all that remained was to see if the Samsung Galaxy II could dance.
And dance it can. Accompanied by my trusty partner in crime netarchy (because this time if I go down in a gibbering wreck I'm damn sure taking someone with me) there is at last another phone with the magic, capabilities and horsepower to endure the test of time and upgrades, that like the Hero has carved out a niche of not only being the good of its generation but being the very best of its generation. Such hardware deserves only the best development efforts and here we are.
The best kernel for a phone that any human hand is capable of producing at this very moment in time. This will of course be rendered moot with the next release BUT RIGHT NOW, this is it boys and girls. Download it, flash it, use it with whatever ROM you wish (VillainROM of course for those with an IQ north of my shoe size) and enjoy the liberated freedom, speed and stability that those whoever owned a HTC Hero became accustomed to.
After much arguing with Samsung's inane practices, lack of logic, bizarre design decisions and enough harrassment via their support interface that I confidently expect a restraining order any day now, I bring you...
Ninphetamine version 1.0, the beginning.
Features:
Overclocking up to 1.6GHz. The phone is blisteringly fast at stock 1.2GHz so be happy you can push it to 1.6GHz. We will not provide higher, if you want higher then make your own.
Full voltage control interface. Via SetCPU you can set voltage as low as 800mV or as high as 1500mV for each speed in the database. If you're possessed with the intelligence of a baboon and destroy your phone as a result, do not come crying to us. All you'll get is a quote in this thread with much mocking from myself and your peers.
Patches and bug fixes up to and including 2.6.35.11. We're working on going up to 2.6.35.13 however the important fixes are in already. As well as some that never made it to 2.6.35.y -at all-.
Fully tested performance optimisations. This kernel comes with BFQv2-r1 IO scheduler enabled as default along with some tweaked parameters for this scheduler. These were painstakingly tested over many many many many many MANY different benchmark tests. These are the best. Anyone who claims otherwise or says that noop or deadline or CFQ is better, they're wrong. Why? Because I say so and I'm right.
A customised and trimmed down initramfs, including Clockworkmod. Many thanks to ogdobber for this who kindly gave me the template including ClockWorkMod that I took and further improved upon. All storage mounts are optimised for performance and data throughput, busybox is included as well as a much improved shell that by default provides tab completion even via adb shell. Please note that by default, adb is insecure, this means that adb shell, adb remount etc all work and give root access immediately.
So there you have it. Please download, flash, test and report any issues/bugs in this thread. I'll then either completely ignore the dumb posts or take on board constructive ones and use those reports/suggestions, incorporate them into the next version and then take all the credit.
Thanks to:
This release would not have been possible without the awesome and tireless work of netarchy, of Nexus S and Asus Transformer fame. Thanks also to ogdobber and supercurio for their assistance. Also thanks to mattgirv, Lenny, Rawat, Obihoernchen, geko95gek and Ante0 for being my guinea pigs for the many many test builds that were made before this final release, no doubt without them there would be a lot more bugs in this release than there already are. Also not forgetting of course, the everlasting patience of my wonderful wife, without which I never would have bothered picking Android up again at all.
Bugs/Issues:
Please of course report them in this thread, however before doing so, please:
Wipe dalvik.
Ensure you have no other OC software installed such as Tegrak. The only OC software supported by this kernel is SetCPU (or setting manually via command line of course).
Are you using a custom ROM? See if you still get issues with stock Samsung firmware or VillainROM. I cannot test with every single custom ROM out there, so I test with stock Samsung (naturally) and my ROM of choice.
If you're still having issues such as random hangs/crashes/reboots and if these issues still occur at stock speeds/voltages then please do the following:
Install the Android SDK if you have not already done so.
In a command window, do the following:
Code:
adb logcat > USERNAME-logcat.log
Then in another window:
Code:
adb shell cat /proc/kmsg > USERNAME-kmsg.log
Naturally replacing USERNAME with your name and make these logs available either via attachment or pastebin or whatever. Please do not paste them directly into posts as these logs can become quite large quite quickly.
Known Issues:
adb install <package> currently does not work.
Version 1.1
Changelog:
Some minor edits to the initramfs to fix adb install <application>.apk and a few other path issues. Loses the nice adb shell with tab completion, but fixes some issues. Download links updated.
Version 1.2
Changelog:
More initramfs changes to fix an issue with nandroid backups.
Making nandroid backups work again may have broken the "adb install" package install method, but I figure working nandroid and needing to push the apk to the phone to then install with Application Manager beats broken nandroids. I'll look further into the adb install issue later today.
Version 1.4
Changelog:
Some configuration changes to try and track down the random hangs/reboots people are experiencing.
Support for startup scripts in /system/etc/init.d added should ROM makers wish to use them.
Added debugging code, which prevents deep sleep in version 1.4, but makes crashes easier to diagnose.
FAQ/General Points
I hate Odin. It is a giant buggy piece of ****. Things can inexplicably go wrong for no other reason than Odin is a big heap of proprietary fail. Before reporting issues with the kernel, please either flash it with CWM or Heimdall. I highly recommend Heimdall, it will flash a jpeg to your kernel filesystem if you tell it to and somehow it'll boot anyway. I do all my testing with Heimdall so it's safe to assume that if I'm posting it, Heimdall will flash it. Heimdall also has the advantage of being open source and completely cross platform. Please take the time to download it and get used to using it, it will save you a lot of pain in the future.
This kernel has been tested with 2.3.3 KF2 and 2.3.4 KG1. There is no reason it shouldn't work with any ROM revision.
Somewhat amazing that I need to point this out, but you MUST FLASH THE KERNEL FOR THE VOLTAGE TAB TO APPEAR IN SETCPU.
Don't use tegrak with this kernel. DO. NOT. USE. TEGRAK. WITH. THIS. KERNEL.
The voltage that's adjusted is the CPU core voltage.
Major_Sarcasm said:
Just a FYI for those people that can't make logical connections; if you have Tegrak OC installed when you flash this kernel, you might end up with a boot loop. Go back to default settings in the app, then uninstall it before flashing.
Click to expand...
Click to collapse
More will be added to this post as the need arises.
pulled for now
SUPER !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you !!!
netarchy said:
Use the voltage interface in SetCPU.
Click to expand...
Click to collapse
OOOO who is here!!! famous netarchy
Hacre said:
Reserved
Click to expand...
Click to collapse
Welcome. Will give it a try.
2.3.3, 2.3.4 ... all ok w this universal kernel?
EDIT: Great... I see you edited Post #2, and the answer is yes.
Thanks for the kernel. Does this have the multi-touch fix included?
jlevy73 said:
Thanks for the kernel. Does this have the multi-touch fix included?
Click to expand...
Click to collapse
I've not noticed an issue with multi-touch, of what do you speak?
*subscribes to thread*
netarchy said:
Use the voltage interface in SetCPU.
Click to expand...
Click to collapse
Okay maybe this is a dumb question, how do you undervolt using setcpu? I know I use it to underclock, and AFAIK it's different from undervolting. I've check the interface of setcpu just now trying to find undervolting options
mach0boi said:
Okay maybe this is a dumb question, how do you undervolt using setcpu? I know I use it to underclock, and AFAIK it's different from undervolting. I've check the interface of setcpu just now trying to find undervolting options
Click to expand...
Click to collapse
Make sure you're using the latest version, and use the voltages tab.
mach0boi said:
Nice! So how will you do the undervolting here?
Click to expand...
Click to collapse
Ummm...
Hacre said:
Full voltage control interface. Via SetCPU you can set voltage as low as 800mV
Click to expand...
Click to collapse
If only I'd mentioned it in the OP...
netarchy said:
Make sure you're using the latest version, and use the voltages tab.
Click to expand...
Click to collapse
Ooh okay i didn't knew there was such feature! thank you!
Hacre said:
Ummm...
If only I'd mentioned it in the OP...
Click to expand...
Click to collapse
I'm sorry maybe I'm just using an outdated version and never knew you could actually do that. Forgive my ignorance
sorry i am new to android so i do not know about undervolt or overclock, can anyone please tell me best combination of voltages on 1.6ghz that does not effect battery life?
ravian29 said:
sorry i am new to android so i do not know about undervolt or overclock, can anyone please tell me best combination of voltages on 1.6ghz that does not effect battery life?
Click to expand...
Click to collapse
The stock max voltage of the CPU is 1275-1300mV. Anything under this improves battery life, anything over this harms battery life from the standard "stock" expectations. Just like with a PC, not all processors are created equal. There is no setting for 1.6GHz that will not affect battery life as at best you'll need to increase voltage from the standard max setting. If you're not sure, use our defaults, these have been tested on two different handsets. There isn't even a guarantee that 1.6GHz will even work on your handset.
If you're not sure or are not confident, don't touch it. Any settings you set past 1.2GHz/1300mV are at your own risk, may damage your handset or even rip a hole in the space-time continuum, then you'll not only look an idiot with a broken handset but Stephen Hawking will be really pissed and you really don't want him trying to crush your toes in that tank he calls a wheelchair.
Best case scenario, try our defaults and only increase voltage in 25mV steps. If you find yourself a 1450mV and your phone still isn't stable then 1.6GHz isn't going to work for you. If battery life is your concern, then consider undervolting in 25mV increments at 1.2GHz or even 1GHz or 800KHz.
mach0boi said:
Ooh okay i didn't knew there was such feature! thank you!
Click to expand...
Click to collapse
I am using the latest version 2.24, i don't see a voltage tab there..I only see Main, Profiles, Advanced, Info, About
@hacre cheers mate
umair9001 said:
I am using the latest version 2.24, i don't see a voltage tab there..I only see Main, Profiles, Advanced, Info, About
Click to expand...
Click to collapse
In Settings -> About Phone what does the Kernel version show?
umair9001 said:
I am using the latest version 2.24, i don't see a voltage tab there..I only see Main, Profiles, Advanced, Info, About
Click to expand...
Click to collapse
Yeah also checked it and I'm also using the latest version. Was about to ask this. Another question, is that voltage tab option kernel related? I'm using cfroot kernel and cannot find that damn voltage tab I'm using tegrak to undervolt. If I knew there's a feature like this in SetCPU, I should've not bought tegrak
Hi there,
This is a development thread.
Don't ask for ETAs. Don't ask what's working. Don't ask how to use.
It is not yet in an usable state.
INFORMATION
Click to expand...
Click to collapse
This is an attempt to make a homemade 3.x kernel for our beloved Galaxy S II. I'm targetting the GT-I9100 only for now, if you wish to get it running on other variants (I9100G for instance), feel free to port it to your device and do a pull request.
I started it off Origenboard 3.0.4 kernel patched to 3.0.24, so that we get the most up-to-date opensource drivers, removing the need of porting Samsung drivers from 2.6 (gingerbread) kernel.
We'll be able to merge proprietary stuff from Samsung when they release it (audio and modem mainly), but thanks to what we'll already have we'll have a proper 3.x kernel without any Samsung crap (such as their MTP implementation that is borked it seems).
GIT REPOSITORY
Click to expand...
Click to collapse
http://github.com/xplodwild/android_kernel_samsung_galaxys2
WHAT'S WORKING
Click to expand...
Click to collapse
Keys GPIOs
Regulator and battery (it loads well but Android doesn't show it's charging)
Screen/framebuffer
Touchscreen
MFC (untested but should work from Origen)
RTC Clock
Touchkeys
MAJOR ISSUES
Click to expand...
Click to collapse
Phone never wakes from deep sleep (<== We definitely need experts on this one)
ADB works only after unplugging and replugging USB cable (issue almost located)
HOW TO HELP
Click to expand...
Click to collapse
Well, start forking, do stuff and make pull requests so I merge it and everyone enjoys. I'd need some help for the major issues above (especially the deepsleep issue).
If you're not a developer, well, buy me a coffee, there's a donation button on the left of this post
I'll keep you informed when it'll be ready for "public" use.
Phone never wakes from deep sleep
cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Entropy512 said:
[*]Phone never wakes from deep sleep
[*] cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I was just thinking that Iirc it puts the device into 800 when waking, or something like that...
Entropy512 said:
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I had the same issue when I haven't enabled the governors, so the CPU was stuck at 1200MHz but won't wake up either from a deep sleep.
I'll have a try with the voltage, but my guess is more that there's some steps missing (the default 2.6 kernel seems to have a "low power mode" in which the board gets before waking up, if I understood it correctly).
At the same time, I'm giving a try with the 3.3 branch at Linaro (check android-3.3 branch at my github). It's harder than 3.0 because there's no more s3c framebuffer, it seems to go directly to FIMD, and the LCD panel has to be setup through SPI.
Some update:
- Touchkeys, clock and various things added/fixed
- Patched to 3.0.24
Edit:
- Added sdcard mounting
Cool stuff should come very quickly
Good work...
---deleted some post----
Sorry u can delete this post as it making thread very ugly..
_____________________
Sent From My Phone
just buy u a expensive coffee! Work hard!
Yeah do you smell sources?
Sent from my GT-I9100 using XDA
boba23 said:
Does this mean you are smelling Samsung source code somewhere? ;-)
boba
Click to expand...
Click to collapse
We'll do our best without them.
True enough.
This kernel is the most exciting thing I'm watching lately.
Really excited about the outcome. Samsung Kernel is just not the way to go if you get an alternative like this, which is far more promising.
Here comes your coffee:
33P346290U8160844
Keep it up!
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
sam razzy said:
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
he already know it...pretty sure xplod and codeworkx will bring some state of art kernel to us
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Isn't 3.3 bleeding edge?
Sent from my GT-I9100 using XDA
awesome, man
despite not owning a sgs2 I like your work! Samsung should definitely review their way of development, way cook your. own soup, when it. Is. already done by someone else
they should just stay compatible and release the damn hardware drivers ;-)
Sent from my Nexus S using XDA Premium HD app
XpLoDWilD said:
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Click to expand...
Click to collapse
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase? https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Entropy512 said:
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
Click to expand...
Click to collapse
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Entropy512 said:
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase?
Click to expand...
Click to collapse
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Entropy512 said:
https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Click to expand...
Click to collapse
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
XpLoDWilD said:
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Click to expand...
Click to collapse
Makes sense, although unfortunately, some things are clearly backports of newer code, see below.
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Click to expand...
Click to collapse
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
Click to expand...
Click to collapse
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Entropy512 said:
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
Click to expand...
Click to collapse
My bad, after checking it must be codeworkx that merged it wrong (he put samsung on top of "stock" 3.0.15 to check the differences), I guess files weren't deleted.
Entropy512 said:
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Click to expand...
Click to collapse
I'm not talking specifically about mach-exynos implementation, but more all the other things that got touched around it.
Entropy512 said:
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Click to expand...
Click to collapse
If copyright header is right, Samsung's one is 2009-2010 whereas 3.3 is from 2011. One example is that the Samsung driver uses mutexes and locks, which are not needed anymore and are not present anymore in mainline. This causes deadlocks everywhere when trying to use them in a "clean" kernel.
All ICS kernel updates can go here. This is for Entropy, LipShitz, Task and any other who is actually working on the ICS kernel.
If you post here, it will be deleted on the spot so just fair warning...
First!
These are always my latest *unsupported* builds:
i9100 Touchwiz Based Roms: http://www.cheatersedge.org/android/i777/TWzImage.tar
AOSP Based Roms: http://www.cheatersedge.org/android/i777/AOKPzImage.tar
Red5 said:
If you post here, it will be deleted on the spot so just fair warning...
Click to expand...
Click to collapse
Come at me bro!
j/k..
Seriously guys.. No fooling around!
Fenny maybe I missed it but do you have a thread to discuss this tw kernel. So far so good. I had already converted OmegaRom 5.1 with everything and was just waiting on a kernel. So far so good. I am gonna look through my notes on how/where to fix the home haptic feedback but other than that all 4 buttons seem to working perfectly. I have sent a pm to the des of OmegaRom to see if they wanted it ported (help porting it to our phones) but i have heard back from them so far. Will continue playing with it with your kernel and test it out. I have run the OmegaRom for about three days already and have had any issues so testing with your kernel is now upon me. Thanks for your work on this. Rich
Fixed: All keys and home haptic working now, though home haptic seems lighter than the other keys.
Sent from my SGH-I777 using xda premium
Until things are cleaned up better, there aren't going to be threads. There's enough to be done and enough things are still not working right that new threads aren't justified yet.
https://github.com/Entropy512/initramfs_galaxys2_ics
https://github.com/Entropy512/kernel_galaxys2_ics
used to build the attached zImage. If you don't know what to do with a raw zImage, this isn't ready for you yet. Simple as that - there is a lot of things missing (like, don't set any profiles in SetCPU with reduced clock frequencies, bad things will happen) - I still haven't tested flashing zips in CWM. nandroid backup/restore seems to work but no guarantees.
You still need to disable Samsung Noise Reduction or use a hacked Phone.apk along with a hacked /system/usr/keylayout/sec_touchkey.kl (see Hellraiser on github) for it to work in a reasonable way. There's probably a large pile of **** still broken. Don't pester me with bug reports - there's a pile of stuff I KNOW I still need to address.
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Entropy, not stating a fact and you KNOW a heck a lot more than I so take this with a grain of salt. I have been playing with lots of different files on a ported/converted i9100 ICS Rom (Omega Rom 5.1) and used these for the usr files and have seen the screen wake issue. http://db.tt/DUe4afdh Maybe it has nothing to do with these though. I have changed many other things like csc folder, csc other files, many other things also. Also I am using the kernel posted by Fenny if that matters or is much different than yours a I have tested it out yet. I only replied here because one of the files I removed was the gpio file completely as other files inside seemed to have the same configurations. Maybe I am WAY off base here. If you want to try the Rom i converted already to see if anything helps let me know and I will send a link to you. Thanks for all your hard work.
Sent From My KickAss ATT SGS2 SPORTING my CobraRom
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Better off doing how its being done... if use another developers ... you just mirror same issues...if build yourself you know whats what.
Tap-Tap Talking
Entropy512 said:
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Click to expand...
Click to collapse
Isn't 4.0 a total new build from Sammy? Honestly.... from what I'm looking at...I don't see ginger GPIO being compatible..but should be if all they used was duct-tape and staples to parse another kernal together.I'm buying a laptop. You guys use sdk? Entropy..what program are you using for kernal popping? Give me area you want help....will do
Tap-Tap Talking
LipShitz said:
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
Click to expand...
Click to collapse
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Entropy512 said:
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Click to expand...
Click to collapse
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Fenny said:
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Click to expand...
Click to collapse
Ill make sure it stays at the top.
LipShitz said:
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Click to expand...
Click to collapse
I'll catch up on your PMs soon.
I think I've found the screen wake bug: I misread the #ifdefs in the Gingerbread kernel, and realized they unmap the HOME key GPIO.
There was no such unmapping in the ICS kernel - so the GPIO was left mapped to HOME but left floating, which explains both random wakes and spurious HOME presses. It's also why the patch I posted this morning caused guaranteed screen wakes on resume - GPX3(5) is the HOME GPIO and was set to pulldown by that patch - it's an active-low GPIO.
Attached is a test kernel zImage and two patches - if these solve screen wake for those experiencing it, I'll push the patches to github and probably release the first Daily Driver ICS tonight even though I still haven't fixed SetCPU hangs.
This kernel is for Touchwizz firmwares only - if it solves the problem for everyone I'll work with the CM9 maintainers on integrating the attached patches, which apply to the current state of my github repo.
Let me know when you get to test point. Shoot it over if you want.
I have started writing a new program that will enable you to do parcing of 2 total diff Kernals,full factory and custom ROMs., yank out APK's and cook me dinner. What It will prob be 2gig in size..will streamline it. But when done--- WE WILL RULE THE WORLD!.. yea ok.
Tap-Tap Talking
Here is a kernel I compiled to work with MIUIv4 for this weeks update 2.3.23:
http://www.mediafire.com/?5bm1l4t1bmbd8bm
All good... little laggy(prob CPU hang) 200-1200 CPU set? No wake issue yet. I'm on 1.5 hours.
Tap-Tap Talking
I restarted phone and stuck on startup logo(samsung bla bla bla) i need to hook it up to laptop and flash it. Will not go into cwm with power and both volume. Im on my infuse.
Sent from my SAMSUNG-SGH-I997 using Tapatalk
Sorry Double Post
Testing done. Source up. Happy picking.
I wrote this for the Sensation and mdeejay did harass me to port it over to the shooteru (I don't own an EVO), well:
Challenge accepted!
Download: Don't click me anymore...
Source: Click me...
I ported my work from the Sensation and modified it quite extensively to work with the atmel driver instead of the cy8c one from the Sensation.
The first version had some problem with the capacitive leds (null pointer dereference ), thanks to the logs of @teihoata this could be fixed.
bricked.de
Hi,
Let me clarify that I am not a DEVELOPER, or LOGGER or TESTER of any sorts
I just want to put forth that a similiar thing called Slide2Wake, which was developed by bponury on our XDA forums was released somewhere ealrier this year. It was actually coded much earlier but wasnt released. I remember coming across it during Kamma's kernel time, which is in October or November 2011.
This is his thread ;
http://forum.ponury.net/viewtopic.php?f=14&t=354&sid=837533d86c47eac9495375908d131899
In his thread, he allowed us to port in certain kernel module, which allows any kernel developer to include. This inclusion will allow us to do "Slide 2 wake"
Once the kernel code is included, users of the HTC EVO3D are to download an app called ;
Ponury Gesture Mod (currently version 1.4)
https://play.google.com/store/apps/details?id=net.ponury.pgm&hl=en
This app allows an interface to configure the "Slide 2 wake" feature, which if you watch his Youtube here;
http://www.youtube.com/watch?v=GswWnvxuCXk
You will find out its the similiar thing with your "Sweep 2 wake" function
However, Ponury's one is kernel module and app, based only for EVO3D.
The app allows you to turn it off, and on, and separately if you only need 1 part of it to work.
Some kernels currently that definitely support it are Leedroid's latest, Anthrax latest and Anryl's latest, while some other kernels like Unity3b by Mdeejay doesnt
I noticed capacitive buttons LED bugs exist, depending on the ROM and the Tweaks.apk settings and Autobrightness, etc. Overall, it works almost most of the time.
What I would like to know is how different is your "Sweep 2 wake" compared to "Slide 2 wake" for us to give this a whirl ?
I remember battery drain issues with screen off present due to the fact that the screen is consistently trying to register touches in a particular fashion, and if you touch the screen for 30 minutes non stop (like I did once in a meeting), these touches are still being recorded and using battery. The screen didnt turn ON (because I was randomly touching everywhere else besides the buttons), yet when I checked some logs and task monitors, it showed that I kept interacting with the kernel and CPU was busy. This did drain battery. The only way it did drain actually.
Apologize in advance for this post if it messes up your thread, and effort.
I can dwell into the testing of this , once some things are clarified
Much thanks for your effort, and Mdeejay of course
jcsy said:
Hi,
Let me clarify that I am not a DEVELOPER, or LOGGER or TESTER of any sorts
I just want to put forth that a similiar thing called Slide2Wake, which was developed by bponury on our XDA forums was released somewhere ealrier this year. It was actually coded much earlier but wasnt released. I remember coming across it during Kamma's kernel time, which is in October or November 2011.
This is his thread ;
http://forum.ponury.net/viewtopic.php?f=14&t=354&sid=837533d86c47eac9495375908d131899
In his thread, he allowed us to port in certain kernel module, which allows any kernel developer to include. This inclusion will allow us to do "Slide 2 wake"
Once the kernel code is included, users of the HTC EVO3D are to download an app called ;
Ponury Gesture Mod (currently version 1.4)
https://play.google.com/store/apps/details?id=net.ponury.pgm&hl=en
This app allows an interface to configure the "Slide 2 wake" feature, which if you watch his Youtube here;
http://www.youtube.com/watch?v=GswWnvxuCXk
You will find out its the similiar thing with your "Sweep 2 wake" function
However, Ponury's one is kernel module and app, based only for EVO3D.
The app allows you to turn it off, and on, and separately if you only need 1 part of it to work.
Some kernels currently that definitely support it are Leedroid's latest, Anthrax latest and Anryl's latest, while some other kernels like Unity3b by Mdeejay doesnt
I noticed capacitive buttons LED bugs exist, depending on the ROM and the Tweaks.apk settings and Autobrightness, etc. Overall, it works almost most of the time.
What I would like to know is how different is your "Sweep 2 wake" compared to "Slide 2 wake" for us to give this a whirl ?
I remember battery drain issues with screen off present due to the fact that the screen is consistently trying to register touches in a particular fashion, and if you touch the screen for 30 minutes non stop (like I did once in a meeting), these touches are still being recorded and using battery. The screen didnt turn ON (because I was randomly touching everywhere else besides the buttons), yet when I checked some logs and task monitors, it showed that I kept interacting with the kernel and CPU was busy. This did drain battery. The only way it did drain actually.
Apologize in advance for this post if it messes up your thread, and effort.
I can dwell into the testing of this , once some things are clarified
Much thanks for your effort, and Mdeejay of course
Click to expand...
Click to collapse
Yes, and since we never saw the source of the slide2wake and it was made into a money making machine, I wrote it myself from scratch and opensource
It completely works with interrupts, meaning: As long as you don't constantly touch your screen with capacitive material (like your finger) there will be no additional battery drain and the phone will sleep as usual.
Additionally this is completely kernel side, so no other apps or anything else "bloating" is required. (and is has a on/off switch)
This also lights up the capacitive buttons as soon as you start sweeping so that you can see the buttons in total darkness. (not shown in the video because it was not in there at that time)
A lot of bugfixes and work went into the sensation version and I don#t expect anything else to be needed here. So it is more than likely that the zImage above will not even work remotely like what I just described.
It's great.
Chad had ported showp's mod to the CDMA evo 3d, but removed it - worked great while it lasted.
Testing done, source is up, op edited. Happy picking.
Awesome work!
How can I test this ? I am using anryl's kernel. Can the zImage be integrated somehow ?. I am not an expert to go into source code territory
sdeft said:
How can I test this ? I am using anryl's kernel. Can the zImage be integrated somehow ?. I am not an expert to go into source code territory
Click to expand...
Click to collapse
Code:
adb reboot-bootloader
fastboot boot C:\Path\to\shooter_sweep2wake_zImage_v2
This will only boot the kernel once, a reboot will reset it to your installed kernel and since there are no modules delivered, wifi will be broken.
is it safe or will brick my phone ?
sdeft said:
is it safe or will brick my phone ?
Click to expand...
Click to collapse
This is a dev thread, though this should be safe there will be no guarantee. Just like any other kernel in the whole Dev section.
I think, this is very them same as slide2wake.
The bad think on slide2wake was, that the touch interface was always online, what resulted in a abnormal battery consumption. I hope this is not so in this Mod...
e3d said:
I think, this is very them same as slide2wake.
The bad think on slide2wake was, that the touch interface was always online, what resulted in a abnormal battery consumption. I hope this is not so in this Mod...
Click to expand...
Click to collapse
Didn't the creator say some stuff about how the screen only woke up when it was pressed?
That didn't really work because if you have chinos on and the phone is in your pocket then the screen just stays on :L
Sent from my HTC EVO 3D X515m using Tapatalk 2
e3d said:
I think, this is very them same as slide2wake.
The bad think on slide2wake was, that the touch interface was always online, what resulted in a abnormal battery consumption. I hope this is not so in this Mod...
Click to expand...
Click to collapse
Read this:
http://forum.xda-developers.com/showpost.php?p=24951715&postcount=3
thre3aces said:
Didn't the creator say some stuff about how the screen only woke up when it was pressed?
That didn't really work because if you have chinos on and the phone is in your pocket then the screen just stays on :L
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Touchscreen#Capacitive
As long as the cloth is not so thin that you can look through it and it is made out of a non capacitive material there will be no problem. But who does put his/her smartphone in the trouser-pocket without having it in the phones bag? (or: who does not have a bag for his/her 600 Euro++ phone? )
btw, awesome handy-bags: http://www.fitbag.de/
show-p1984 said:
Code:
adb reboot-bootloader
fastboot boot C:\Path\to\shooter_sweep2wake_zImage_v2
This will only boot the kernel once, a reboot will reset it to your installed kernel and since there are no modules delivered, wifi will be broken.
Click to expand...
Click to collapse
I didn't really understand how to install this, can you explain it one more time? Thanks.
crimmylol said:
I didn't really understand how to install this, can you explain it one more time? Thanks.
Click to expand...
Click to collapse
Connect phone to pc and type those commands in cmd(assuming adb and fastboot are in PATH)
Sent from my HTC EVO 3D X515m using Tapatalk 2
pedja1 said:
Connect phone to pc and type those commands in cmd(assuming adb and fastboot are in PATH)
Sent from my HTC EVO 3D X515m using Tapatalk 2
Click to expand...
Click to collapse
Will it replace my kernel or just integrate some modules in it?
upd. It stucked on HTC logo and thats all.
gonna wait for this till i see a succesfull flash, idea is great tough..
phikal said:
gonna wait for this till i see a succesfull flash, idea is great tough..
Click to expand...
Click to collapse
This is not meant as a release, it was meant as a development post to help getting debug output for a port (since I don't own the device). I gathered enough debug output to fix up the remaining issues, mdeejay confirmed that it works on his phone flawless and I put up the source. Because I don't own an EVO and I only develop for devices I own, I will not maintain a separate kernel. You should be able to get this sweep2wake port @ mdeejays kernels soon.
As long as the cloth is not so thin that you can look through it and it is made out of a non capacitive material there will be no problem. But who does put his/her smartphone in the trouser-pocket without having it in the phones bag? (or: who does not have a bag for his/her 600 Euro++ phone? )
http://www.fitbag.de/[/QUOTE]
I believe most people only have a case rather than a bag. With the case on, the surface of the phone (screen + capacitive buttons) are still exposed. I'm just wondering if the heat in the pocket will still activate the buttons somehow.
I have tried the slide2wake (ponury gesture mod) myself, and it drains battery alot, even when the phone is out of the pocket.