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.
Related
I have noticed that on the 5 or 6 custom roms I have flash that the auto brightness works great. Although I believe it to be a bit too sensitive causing what I would describe as ever changing brightness almost like a flicker. Has anyone else had this problem or notice it? And is there a fix?
Sent from my PG86100 using XDA App
Mrdiaz09 said:
I have noticed that on the 5 or 6 custom roms I have flash that the auto brightness works great. Although I believe it to be a bit too sensitive causing what I would describe as ever changing brightness almost like a flicker. Has anyone else had this problem or notice it? And is there a fix?
Sent from my PG86100 using XDA App
Click to expand...
Click to collapse
i'm on a stock rom and i have noticed the auto brightness does seem to work fairly quickly .. but i haven't noticed anything similar to a flicker.
i've noticed when i sometimes put a finger over the light sensor on accident it will adjust and then i remove my finger and it readjusts .. i haven't ever seen it adjust too quickly to cause something like a flicker.
could you give more details on when/how you've seen it be "too sensitive" or have a "flicker"? i would like to see if i can replicate on a stock rom!
I believe its the problem you are talking about. I just did some test and like you said if I put my finger over the sensor it does it super fast as well as anytime I create a shadow while using the phone and it hits the sensor. I would personally like to see if we could somehow change the rate that the sensor registers without adversely affecting anything else
Sent from my PG86100 using XDA App
Would the sensors.shooter.so in /system/libs/hw be the place to start trying something?
Sent from my PG86100 using XDA App
Do the ROMS you use have the CRT shutdown and open animation? If so this MOD does cause some flicker with the autobrightness enabled. Viper ROM thread has a flashable fix but it also removes the CRT animation. Not sure if that will be compatible with your ROM though as it replaces the services.jar.
Mrdiaz09 said:
Would the sensors.shooter.so in /system/libs/hw be the place to start trying something?
Sent from my PG86100 using XDA App
Click to expand...
Click to collapse
from my understanding any of the .so files in /system/libs/hw are compiled file and might be a bit difficult to sort thru in a decompiler but if you have the time and patience, it is worth a try!
short answer: i would look thru the drivers for the sensor in the kernel code.
longer answer: i remember having an issue on the samsung moment with the light sensor not responding quick enough. from that previous discussion which is now over a year or so old, i remember leaning towards the kernel source code as potentially having some type of timing adjustment for the drivers which control that sensor.
down side is no updated kernel source has been released for 2.3.4 yet, but at least 2.3.3 is available and i'm sure very few changes were made to this area of the kernel so it should be the same when 2.3.4 is released.
ideal answer: the kernel is compiled with sysfs support so the light sensor sensitivity can be adjusted live in userspace! this is of course a dream more than a reality but figured i'd throw it out there as an ideal end goal.
hope that helps! keep us updated if you have a chance to dig deeper!
This weekend I'm going to dig deeper into the so file. As well as trying to switch back to 2.3.3 and mess with the kernel a little that way if I find anything when the kernel source is released for 2.3.4 I could possibly have a fix. I'm not sure if anyone else would like the sensor timing to be lowered just a little like I would. But I will definitely keep everyone informed with my findings
Sent from my PG86100 using XDA App
Mrdiaz09 said:
This weekend I'm going to dig deeper into the so file. As well as trying to switch back to 2.3.3 and mess with the kernel a little that way if I find anything when the kernel source is released for 2.3.4 I could possibly have a fix. I'm not sure if anyone else would like the sensor timing to be lowered just a little like I would. But I will definitely keep everyone informed with my findings
Sent from my PG86100 using XDA App
Click to expand...
Click to collapse
i posted the following suggestion and method of research in another thread regarding camera compression and searching thru the kernel source for the settings.
regarding the light sensor timing, i think a similar approach might be helpful. the best source for updated and properly compiling kernel source, in my opinion, https://github.com/toastcfh/htc-8660-kernel . i think most custom kernels on here are forked from his and then modified.
starting with the shooter_defconfig file, i'd search for references to sensors/light sensors and see which one is being included in our specific device. from there, i would grep the kernel source to see where the ifdef calls are at for the driver pieces and work out from there.
hope that makes sense and helps in the research! look forward to seeing anything you're able to put together!
Thanks and yes that did make sense. Sorry about the delay hurricane Irene really hit me hard I finally got power back Wednesday and this has been the last thing on my list. I have found what I think to be a fix, however I'm testing right now to make sure I didn't Bork anything else. Should be out to public mid next week.
Sent from my PG86100 using XDA App
You can decompile the framework-res.apk and edit the arrays in res/values/array.xml.
Just have a look at my sig for the guide, how to do it.
Also interesting post from leedroid:
http://forum.xda-developers.com/showpost.php?p=17220302&postcount=109
If you haven't yet tried kushdeck you should, so far it's the only one with crt that had smooth auto light, but you can also turn off the screen transitions in settings and keep crt, you can also use spare parts to have faster animations and again not lose crt.
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
Hey guys and gals, You have seen me lurking here and there
posting some kernels
Team BLACKOUT, would like to extend their support to this device for kernels (roms maybe when i purchase a tester unit)
I would like to call a few testers to help me getting a BeastMode Kernel going for your device
Things I would like you to know or have:
HTCDev Unlock (there is a tool now)
Custom recovery
Knowledge of ADB and Fastboot
Gtalk and willingness to spend a few hours a day working on testing kernels i pump out
Things the BeastMode kernel will offer:
GPU OC
CPU OC / Underclock
Adjustable UV
Mpdecision
ThermalD (userspace interaction)
Sweep2sleep: with screen on, swipe right to left to turn screen off
Sweep2power: with screen on, swipe left to right for power menu (simulated 2.5 second power button hold)
Sweep2snap: with screen on: swipe left to right and press Home within 2 seconds for a screen snap
Sweep2wake: with screen off: swipe left to right to turn screen on (disabled by default for better battery life)
Phantom volume down: with screen on, touch between back and home for vol-down one notch
Phantom volume up: with screen on, touch between home and recent apps for vol-up one notch
Sweep2mute: with screen on, swipe from home to back for vol full down (vibrate)
Sweep2loud: with screen on, swipe from home to recent apps for max volume
Patched linux kernel upstream to 3.0.51
LOTS Of fixes to HTC's D3rps
IF this sounds like something that interests you.... Please shoot me a PM or reply to this thread here
Thanks guys and gals and happy modding
-Z
How can I say no? lol
Or, in other words, sure I would like to test it.
blazingwolf said:
How can I say no? lol
Or, in other words, sure I would like to test it.
Click to expand...
Click to collapse
talk to you soon buddy
I can help if you still need testers.
Unlocked with fireballas CID
running Venom's rom and blazingwolfs kernel
@zarboz
any thoughts on potentially supporting inc2 w/ beastmode?
virtuous never released a primo based kernel for it, but id think from their source one would be possible
nitsuj17 said:
@zarboz
any thoughts on potentially supporting inc2 w/ beastmode?
virtuous never released a primo based kernel for it, but id think from their source one would be possible
Click to expand...
Click to collapse
This is in the works.. I am going to knock out the 8960 Chipset
Then i have most the 8660 Chipset devices done
next is 7X30
Beastmode Desire
Beastmode IncS/2
ohhhhh they will come
If you need any more testers, I'd love to test.
Zarboz said:
This is in the works.. I am going to knock out the 8960 Chipset
Then i have most the 8660 Chipset devices done
next is 7X30
Beastmode Desire
Beastmode IncS/2
ohhhhh they will come
Click to expand...
Click to collapse
awesome, glad to hear :good:
nitsuj17 said:
awesome, glad to hear :good:
Click to expand...
Click to collapse
i gotta get donated / buy a Inc S/2 first though and a DHD/inspire
lol
i gotta do some collecting before kernels start coming for those devices
very cool - good to see you around our community. thanks for your contributions!!!
Zarboz said:
i gotta get donated / buy a Inc S/2 first though and a DHD/inspire
lol
i gotta do some collecting before kernels start coming for those devices
Click to expand...
Click to collapse
I'm selling my inc2
Sent from my Nexus 7 using Tapatalk 2
I'm hoping someone else has already solved this issue, but I seem to be running into serious problems with AOSP CM ROMs with regards to the power button. Recently I actually bricked my original EVO 4G LTE and got a "new" one via the insurance replacement program with Sprint. I immediately obtained rooted, installed recovery, and obtained S-off. I then proceeded to install CM10.2 (deck's build) and am actually still running 9/20 version of this ROM.
My problem with the power-button is that it sometimes does not respond to a press where it may not wake the screen or sleep the screen. Sometimes it takes 2, 3 or more presses to get it to respond. Additionally, sometimes after the screen sleeps it will immediately wake again. It's as if the button is not properly de-bounced. My first thought was that the power-button was physically broken.
So as an experiment I rolled back to previous versions of CM10.1 and got the same results, even after clean flashes. Then I tried rolling back the stock ROM which came with the phone, from a nandroid backup. Shockingly, no power button issues at all. So with a sense based ROM, it seems to work perfectly, but a AOSP based ROM (specifically, CM10.x) I see the issues.
Could this be a kernel issue? Anyone else seen or resolved this issue already?
Thanks. Sincerely,
Frustrated.
Yeah I have that sometimes too although occasionally it won't even wake up and will have shut off by itself
Sent from my EVO using xda app-developers app
Promising update.
I updated the latest TP firmware from Captain Throwback, on a whim. While it doesn't seem to have fixed the issue, it seems much improved. The jury is still out - and it's only been an hour or so since I installed, so this is hardly enough data to say definitively. But promising.
FW is here: http://tinyw.in/cRCf
nebhead said:
Promising update.
I updated the latest TP firmware from Captain Throwback, on a whim. While it doesn't seem to have fixed the issue, it seems much improved. The jury is still out - and it's only been an hour or so since I installed, so this is hardly enough data to say definitively. But promising.
FW is here: http://tinyw.in/cRCf
Click to expand...
Click to collapse
Yup, spoke too soon. Still having issues. The search continues.
I just got a replacement evo lte and my power button sucks.. I gotta hold it down for a few seconds to wake or lock and that was before root.. I'm rooted now and on sense 5 r145 but I use the swipe to unlock and lock and it works great.. I said forget the power button...
Sent from my EVO using xda app-developers app
hondafreak513 said:
I just got a replacement evo lte and my power button sucks.. I gotta hold it down for a few seconds to wake or lock and that was before root.. I'm rooted now and on sense 5 r145 but I use the swipe to unlock and lock and it works great.. I said forget the power button...
Sent from my EVO using xda app-developers app
Click to expand...
Click to collapse
So your power button was bad with the stock ROM too? That's a bummer. At least mine seems to work OK with the stock ROM. Maybe I should try some modified stock ROMs to see if there is a difference there.
You're not alone. My brother and I both have EVO's and we're both experiencing this issue. It's annoying as hell having to press the power button multiple times to wake the device. Didn't start having this issue until the end of the CM.1 cycle. I also went back to Sense and found no problems. It only appears to occur on non sense ROMs. Does anyone have any insight to this or possibly a fix?
It's a kernel issue. That problem did not pop up until the 3.4 kernels started coming out.
AndrasLOHF said:
It's a kernel issue. That problem did not pop up until the 3.4 kernels started coming out.
Click to expand...
Click to collapse
Well that's great news (sort-of) and means that some day someone could potentially resolve this in the kernel. Maybe we need to X-Post with the CM10.2 development forum, unless they are already aware and are working on this.
nebhead said:
I'm hoping someone else has already solved this issue, but I seem to be running into serious problems with AOSP CM ROMs with regards to the power button.
Could this be a kernel issue? Anyone else seen or resolved this issue already?
Click to expand...
Click to collapse
There were certain nightly/kernel mixes with the 10.2 and Haunted kernel that seemed to clear it up for me.
I can't for the life of me remember which combination. Sorry.
One thing that alleviated that for me a bit was enabling "Volume Buttons Wake Up Handset" or whatever it was.
physix said:
There were certain nightly/kernel mixes with the 10.2 and Haunted kernel that seemed to clear it up for me.
I can't for the life of me remember which combination. Sorry.
One thing that alleviated that for me a bit was enabling "Volume Buttons Wake Up Handset" or whatever it was.
Click to expand...
Click to collapse
Cool, I think I may try the Haunted Kernel. Nandroiding first of course. I will report back later.
Yeah try a new kernel and use kernel tuner and turn on the Swype to wake option it is pretty cool..
Sent from my EVO using xda app-developers app
Haunted Kernel 31 + Unofficial CM10.2 9/20 Build (Deck) appears to still have issues. Although it seems a bit better than before. As to whether this introduces new issues, I'm not sure yet.
The work on the kernel is ongoing. Trust me, it's way better than it was before.
Captain_Throwback said:
The work on the kernel is ongoing. Trust me, it's way better than it was before.
Click to expand...
Click to collapse
Yup, expected to have a few hiccups using bleeding edge ROMs & kernels. Glad to hear that these types of things are being addressed. The Haunted kernel definitely makes things much, much better. It's definitely daily driver quality now.
As a side note, I've also noted that the WiFi seems to work better with the Haunted kernel as well. Not sure if that's related, but where I used to have difficulty staying connect to WiFi at home and at work, it now seems rock solid. Still a bit too early to be definitive, but so far so good.
nebhead said:
Yup, expected to have a few hiccups using bleeding edge ROMs & kernels. Glad to hear that these types of things are being addressed. The Haunted kernel definitely makes things much, much better. It's definitely daily driver quality now.
As a side note, I've also noted that the WiFi seems to work better with the Haunted kernel as well. Not sure if that's related, but where I used to have difficulty staying connect to WiFi at home and at work, it now seems rock solid. Still a bit too early to be definitive, but so far so good.
Click to expand...
Click to collapse
Haunted Kernel is still behind some, last I checked. So while you may have some benefits, you will lose/miss some fixes/optimizations. But to each his own.
Captain_Throwback said:
Haunted Kernel is still behind some, last I checked. So while you may have some benefits, you will lose/miss some fixes/optimizations. But to each his own.
Click to expand...
Click to collapse
Good to know. I will keep flashing and keep trying the new builds as they become available. For now, this seems to be a good combo for me. The current Haunted governor actually kinda seems to be draining the battery fast so I may tweak that. Anyway, thanks for all the responses here, this has really enlightened me on this issue.
Hey.. I'm behind for a reason
Sent from my EVO using Tapatalk now Free