Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
Latest Kernel Here
20130625_10XX:
- updated with fix for more recent 4.1.2 Sense ROMs (should fix camera issue)
*unsure if this becomes incompatible with older 4.1.2 Sense ROMs though
20130602_07XX:
- NTFS support
- compiled using 4.8 linaro compiler
- improved workqueue queueing
- sleeper improvements
- responsiveness patches to the frequency controllers
20130531_09XX:
- fixed earpiece volume during calls
20130528_17XX:
- more optimizations (see GitHub)
20130527_18XX:
- more ARM implementations (see GitHub)
20130527_10XX:
- ARM implementations of kernel algorithms (see GitHub)
20130527_09XX:
- compiler optimization flags
20130526_22XX:
- initial version
- uses Linaro compiler
You can find my kernels at:
intersectRaven's Kernels
GitHub is at:
intersectRaven's GitHub
FAQ or something like that:
1.) Camera doesn't work!
- Try this fix from Golv here. This usually occurs on older ROMs.
*Latest 20130625_10XX version should solve this without flashing older camera libs.
Reserved 2
Reserved 3
Nice to see ir taking interest in the One. Truly a great dev
Sent from my Nexus 4 using Tapatalk 4 Beta
Uhhh nice to see you here
intersectRaven said:
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
Click to expand...
Click to collapse
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
m0nz said:
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
Click to expand...
Click to collapse
Should have put a qualifier there huh? Anyways, it's pointless from a no tweaking perspective since undervolting may not work for some chips and could cause more trouble (random restarts and the like) than it's worth. It's fun for a tweaker (like when I did something like that for the N1) but not for someone who's the flash and forget type. :fingers-crossed:
Thanks
P.S you missing the ":" on the http link
Really glad to have you here iR. Missed your kernels from my nexus one days with those hybrid AVS kernels.
Camera is buggy
Sent from my HTC One using xda app-developers app
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
The camera will problably need som librarys, like most other kernels, I think. There is a zip for this in other threads (couldn't find it right away)
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
What is the problem exactly? Also, is this a custom Sense ROM or stock Sense? Just mentioning that it is buggy doesn't actually help me solve it since there are no bugs in my phone.
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Intersect my man. Nice to see u in the HTC one forums!
Sent from my HTC One using xda app-developers app
Camera troubles
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
chourmovs said:
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
Can you try the link posted below by Maikeu and get back to us whether it fixes the issue?
Maikeu Locatelli said:
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
Click to expand...
Click to collapse
Posted this in the second post here for future reference.
HI, after fashing this kernel , i cannot hear any sound from call dial ,
008325 said:
HI, after fashing this kernel , i cannot hear any sound from call dial ,
Click to expand...
Click to collapse
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
intersectRaven said:
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
Click to expand...
Click to collapse
Thank you very much i really like this kernel , smooth , cold , save battery
Related
So I was just looking around the Qualcomm open source (CodeAurora) repositories and noticed that lots of interesting things are going on over there for the qsd8x50 that aren't yet in our N1 kernels.
One of the most potentially useful things to us, is adaptive undervolting, that always chooses the optimal voltage level based on the current temperature and silicon process variations.
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=621d0e14e6fcf454974634cf822f06fba1bd6816
If someone could get this into an N1 kernel, we wouldn't need any more experimentation with undervolting and could always run at the maximum possible stable voltage.
Other interesting changes include USB host support (although it's unlikely the N1 hardware is physically wired to allow for this):
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=109894cac8d01c6273cfa0466f7823a04e919bea
Unfortunately, the Chromium kernel for MSM/QSD seems to be structured quite differently and being worked on by a different team to the Android kernel. Still, it'd be nice to see someone attempt to port at least the AVS patch to a CM kernel.
p.s. can a moderator please approve my account to directly include links? This manual link-munging is getting annoying
This sounds interesting
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Also of interest is their framebuffer driver. We need it in the N1 kernel to use their X11 driver.
Has anyone had any luck getting a CAF kernel booting on the N1?
Markdental said:
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Click to expand...
Click to collapse
Yeah I know, but this is their Chromium/ChromeOS kernel, not their Android kernel. Might have gone unnoticed (I for one, had not thought to look there -- I'd have thought the only Chrome-specific kernel changes would've been the X11 driver -- why should platform-power-management changes not be shared across both kernels?)
I ported AVS code to the N1 kernel.
You can download the experimental version here:
http://forum.xda-developers.com/showthread.php?t=654416
AVS kernel is very experimental, and I expect it not to be fully stable.
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Ivan Dimkovic said:
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Click to expand...
Click to collapse
Funny that: a processor rated for 1 GHz (in a world where if they could get away with selling it as a 1.1 GHz processor they certainly would have) isn't actually capable of 1.1 GHz without compromising stability and/or lifetime. Who'd have thought
Cheers for porting it to your kernel though, I'll be interested to see if it makes much difference to battery life.
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
No doubt about it. Look at the Desire for example. It will be equipped with the 1ghz Snapdragon but will be underclocked to 768mhz to preserve battery life. So while it is certified for higher speeds HTC feels the market would prefer longer battery life over a little bump up in cpu speed
intersectRaven said:
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Click to expand...
Click to collapse
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
jlevy73 said:
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
Click to expand...
Click to collapse
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
intersectRaven said:
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
Click to expand...
Click to collapse
Also, the upstream (AOSP) MSM kernel tree is still at .32... I would guess they may be stabilizing for a release as they've merged the -stable patchseries too (2.6.32.9 etc).
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
tassadar898 said:
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
Click to expand...
Click to collapse
Its possible, but there are differences in the softkeys, charging hardware, and nfc at the minimum, so it will take a little work to port that over entirely. What would be better is for one of our current kernel modders to add some of the features of the SIYAH kernel over to their own.
I plan on pulling in 100 MHz support.
He doesn't have that much more, other than extremely experimental features that if you read the thread, tend to break.
Gokhan is quite talented, but he's also VERY aggressive - if you're more careful, you don't have to go through long beta periods with lots of broken releases like he does.
He also released source code for older kernels as megapatches, and now releases as straight full-source tarball drops. It makes separating the good from the bad EXTREMELY difficult.
As far as features he has that I don't currently:
1) 100 MHz support - I plan on this one, it's a fairly high priority as part of my current power management research
2) Crazy wacky alternative governors - these are a great way to somehow combine lag and poor battery life all in one
3) Charge current control - not possible on our devices, we have a different (very crippled) charger IC
4) Touchscreen stuff - I have seen no reports of people having touchscreen issues. If it ain't broke don't fix it.
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Entropy512 said:
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Click to expand...
Click to collapse
Would it be possible to get past the wakelock issue if you could program that the BLN shuts off after, say 30min, or user defined? That would work in my case but not sure if everyone universally would like it that way. Just a thought...
Hey Entropy nice to see you here! In siyah you can control the GPU voltage for undervolting. I currently do it using the Tegrak kernel module and I reduced the minimum step of 160 mhz to 750mv down from 950mv. I've noticed a nice bump in battery life. In his 2.1 beta version he also has this available feature
SiyahKernel v2.1 - not released yet -
Time to break some records... both performance-wise and battery-wise...
Overclocking part is optimized and bus frequency selection is modified.
User customizable frequency levels. you still have 8 steps, but you will be able to customize them. wanna change 100 to 150 as 100MHz is not stable on your device? wanna change 1400 to 1304 and 1600 to 1504? or increase 1600 to 1696?
User customizable bus frequency selection. no more overheating. if you are a battery freak, just set it to minimum and your device will last more than ever.
Based on Update3 sources...
Thanks for developing for us!!
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Thanks! I look forward to testing. If you need a guinea pig let me know.
Entropy512 said:
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Click to expand...
Click to collapse
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
AndreiLux said:
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Click to expand...
Click to collapse
Yeah, I figured as much, which is why it's pretty low on my priorities list
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
Click to expand...
Click to collapse
It says that nowhere. HTC claimed they had 90 days and that is a GPL violation. Easy enough to Google that one. It kind of bit them in the ass though - http://thread.gmane.org/gmane.linux.kernel/1048027 and https://freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone
After much media pressure they backed down and released sources in only 7 days.
GPLv3 gives an explicit 30-day grace period for resolving violations, but the kernel is not v3, it's GPLv2.
I really should stop pointing Gokhan towards fixes since he's a one-way street.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Click to expand...
Click to collapse
Yup - If someone else wants to port his more aggressive features they can try - it's just not coming from me.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
Click to expand...
Click to collapse
I'll have to look into that - As of a few weeks ago, the AT&T I777 sources were new enough that I9100 kernels (including Siyah) started to be based off of them. The question is - while Update2 to Update3 is a big improvement, is I777 to update3 such an improvement?
I'll have to check those out tonight and diff them.
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Looking forward to see the update being incorporated.
AndreiLux said:
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Click to expand...
Click to collapse
I'm going to start this over the next week - I've split update3 into what should be separate independent patchsets by component (touchkey, audio, wifi, etc.)
Last one is likely going to be the machine-specific ARM stuff - because that means rewriting the clock control patches completely.
this issue is driving me crazy... no matter what i do i can't get good battery life with cm based roms.... no mater what i try: official, temasek, carbon, paranoid, all have **** battery life that barrely last a day.
i always end up going back to sammy based roms like wanamlite. byt i dont like it!
i greenify apps, disable gps, dormancy, startup apps, what else???
if it matters, i never change kernels..
You aren't experiencing anything new, only Samsung based roms will get good battery life on the S3.
Probably due to a lack of sources
Sent from my GT-I9300 using Tapatalk 4
rootSU said:
Probably due to a lack of sources
Sent from my GT-I9300 using Tapatalk 4
Click to expand...
Click to collapse
what do you mean?
Samsung don't release their exynos source code properly, so AOSP developers don't have all the information required to get similar performance out of all the hardware components
Sent from my GT-I9300 using Tapatalk 4
rootSU said:
Samsung don't release their exynos source code properly, so AOSP developers don't have all the information required to get similar performance out of all the hardware components
Sent from my GT-I9300 using Tapatalk 4
Click to expand...
Click to collapse
is there any aosp or aokp based rom that will provide good battery life?
They're all about the same
Sent from my GT-I9300 using Tapatalk 4
they last the same for me with custom kernels.
i wont go back to sammy
Sent from my Nexus 7 using xda app-developers app
To me, any CM/AOSP and any kernel included or custom last about the same, and that is about 40% less then stock samsung rom.
Of course depending on situation...
However I won't be coming back to stock samsung rom any time soon
Agreed, custom kernels help a lot but still not quite as much as stock. Similarly, im sticking with aosp
Sent from my GT-I9300 using Tapatalk 4
Probably irrelevant but i tried the Illusion Rom and it gave me 1d 53h of normal usage whereas sammy barely gets me through the day
Just thought id mention it
1 day + 4 days?
Sent from my GT-I9300 using Tapatalk 4
You are confusing things here...
rootSU said:
Probably due to a lack of sources
...
Click to expand...
Click to collapse
You are confusing things here - the lack of sources is somehow relevant to the kernel part, and generally the best kernels in regard to power consumption are the custom ones (like Perseus, Siyah and so on) - which are precisely started from the sources coming from Samsung.
The ROM part only talks to the kernel part, and once you have the same kernel (like Siyah) talking to both a CM ROM and a Sammy ROM and you get better power consumption in Sammy I don't really see how that can be related to "lack of sources".
rootSU said:
1 day + 4 days?
Sent from my GT-I9300 using Tapatalk 4
Click to expand...
Click to collapse
hahahaha sorry my bad:silly:
1d 13h
AthlonGFX said:
Probably irrelevant but i tried the Illusion Rom and it gave me 1d 53h of normal usage whereas sammy barely gets me through the day
Just thought id mention it
Click to expand...
Click to collapse
Yeah sure, I even got on couple of occasion over 2 day and maybe 3-4hrs...
But however on stock with the the approximately same usage I would still have 30-40% more usage time.
xclub_101 said:
You are confusing things here - the lack of sources is somehow relevant to the kernel part, and generally the best kernels in regard to power consumption are the custom ones (like Perseus, Siyah and so on) - which are precisely started from the sources coming from Samsung.
The ROM part only talks to the kernel part, and once you have the same kernel (like Siyah) talking to both a CM ROM and a Sammy ROM and you get better power consumption in Sammy I don't really see how that can be related to "lack of sources".
Click to expand...
Click to collapse
No im not confusing things - but you're over simplifying things. The kernel sources are complete. Siyah uses the samsung kernel sources as a base and it interacts with touchwiz roms perfectly. The same kernel does not interact with aosp roms in the same way.
Set up a touchwiz rom with basic settings and siyah kernel and compare it to aosp with the same basic settings and kernel and touchwiz will win hands down.
Samsungs kernel source may be complete but the exynos and hardware sources are incomplete. That's why an aosp rom camera is much lower quality than samsungs using the same hardware.
Also its worth noting that these dual purpose kernels are built from a mixture of samsung sources and Google sources. Otherwise they wouldn't be able to support 4.2.2 aosp roms...because 4.1 kernels are different to 4.2 kernels...hence no existing kernels can work on 4.2 sammy roms. We need their kernel sources for that, but they will come unlike complete exynos sources.
If you look at the snapdragon variants of the s3, the chipset is well documented so the developer community have much more scope to get comparable battery performance but this isn't an option for us. This is why the developer community here are so frustrated with samsung and the i9300 to the point where team hacksung decided they no longer wish to support cyanogen on exynos devices. We are unable to exploit the hardware to its full potential as we don't have what's required. Developers need to use a lot of guess work to get things working. Our s3 device tree for aosp roms is incomplete and this is samsungs fault for not being forthcoming with their non kernel sources
Sent from my GT-I9300 using Tapatalk 4
You are still confused
rootSU said:
...
Samsungs kernel source may be complete but the exynos and hardware sources are incomplete. That's why an aosp rom camera is much lower quality than samsungs using the same hardware.
...
Click to expand...
Click to collapse
That is completely irrelevant to what it was discussed - and is also false since for instance your own post is somehow trying to suggest that the AOSP camera works perfectly for non-Exynos S3 and works bad for Exynos S3 - once you get your time to check reality instead of propagating stuff you will see that is just another myth and that:
a) the AOSP camera is about as bad for BOTH CPUs
b) the information that is missing has nothing to do with the CPU from Samsung but instead with the camera itself.
And getting back to what this thread was about - POWER CONSUMPTION - the facts show that most CM ROMs have worse power consumption than most Sammy ROMs when both scenarios are run with the SAME KERNEL compiled from sources. A very remote point might be (maybe) made for device-drivers that are blobs (and where custom ioctls maybe are not documented) - but CPU / power management is not one of those! Debunking even further your childish talking point - with the same Sammy ROM the POWER CONSUMPTION is clearly better when running with one of those custom kernels then when running standard Samsung kernel - so any point that somehow any information relevant to power consumption is missing - when actually the custom open-source kernels are demonstrably better in this regard - now stands forever debunked
xclub_101 said:
That is completely irrelevant to what it was discussed - and is also false since for instance your own post is somehow trying to suggest that the AOSP camera works perfectly for non-Exynos S3 and works bad for Exynos S3 - once you get your time to check reality instead of propagating stuff you will see that is just another myth and that:
a) the AOSP camera is about as bad for BOTH CPUs
b) the information that is missing has nothing to do with the CPU from Samsung but instead with the camera itself.
And getting back to what this thread was about - POWER CONSUMPTION - the facts show that most CM ROMs have worse power consumption than most Sammy ROMs when both scenarios are run with the SAME KERNEL compiled from sources. A very remote point might be (maybe) made for device-drivers that are blobs (and where custom ioctls maybe are not documented) - but CPU / power management is not one of those! Debunking even further your childish talking point - with the same Sammy ROM the POWER CONSUMPTION is clearly better when running with one of those custom kernels then when running standard Samsung kernel - so any point that somehow any information relevant to power consumption is missing - when actually the custom open-source kernels are demonstrably better in this regard - now stands forever debunked
Click to expand...
Click to collapse
Without the exynos source the cm kernels can't take full advantage of exynos power saving features..... Simple.
On another note, I suggest you tone down your attitude, and apologise for calling rootSU childish, and don't treat this place like somewhere you can come to wind people up or I will personally introduce you to the moderators
xclub_101 said:
That is completely irrelevant to what it was discussed - and is also false since for instance your own post is somehow trying to suggest that the AOSP camera works perfectly for non-Exynos S3 and works bad for Exynos S3 - once you get your time to check reality instead of propagating stuff you will see that is just another myth and that:
a) the AOSP camera is about as bad for BOTH CPUs
b) the information that is missing has nothing to do with the CPU from Samsung but instead with the camera itself.
Click to expand...
Click to collapse
Wow, way to take something completely out of context and miss an entire point! I didn't even think this was possible. Impressive.
So firstly, I cited the camera as an example of something that relied on Samsung sources along with the exynos chipset (NOT CPU by the way, I haven't use the term CPU, so I guess you just decided to choose that term yourself). The sources are incomplete and the binaries, libs an patches provided are not enough to get everything running on the device as it should be. I, in know way stated or inferred that the camera was better on snapdragon S3's.
The point was we don't have everything in relation to the camera, ergo the camera is not as good as Samsungs. This is not because of the AOSP camera application. Instead it is down to a lack of documentation /sources for the camera HAL. It was a simple example explaining that if we haven't got everything required to run the hardware properly, we can't achieve the same performance. This is obvious with the camera and it's poorer quality images compared to the touchwiz camera using the very same hardware. This is not the case with just the camera though, this extends to all the hardware where we have incomplete information and sources.
xclub_101 said:
the facts show that most CM ROMs have worse power consumption than most Sammy ROMs when both scenarios are run with the SAME KERNEL compiled from sources
Click to expand...
Click to collapse
It is true, with the SAME KERNEL on both platforms, power consumption is different (That's exactly what my post said). However, the dual purpose kernels are compiled from 2 sets of sources, so AOSP and Touchwiz platforms do not overlap 100% with each other (usage wise) in regards to what is compiled into these kernels. Touchwiz ROMs utilise (random guess number to illustrate a point) 90% of whats in the kernel as does AOSP. Meaning there could be a (fictitious) 10% of the kernel exclusively for each platform.
xclub_101 said:
but CPU / power management is not one of those!
Click to expand...
Click to collapse
I didn't mention CPU power management. I did not say that the kernels on AOSP were any different at *managing* the power. Although thanks for bring that up... because now that you mention it, they are.
xclub_101 said:
Debunking even further your childish talking point
Click to expand...
Click to collapse
I don't understand how you can be so audacious to call my talking point childish when you've managed to avoid applying adult levels of reading to my entire post thus far and have taken every point I made conversely to how it was intended.
xclub_101 said:
with the same Sammy ROM the POWER CONSUMPTION is clearly better when running with one of those custom kernels then when running standard Samsung kernel
Click to expand...
Click to collapse
Say what now? If You're saying you think that custom kernels on a Sammy ROM are better than stock kernels on the same sammy rom for power consumption, you'd be right. I never said anything to the contrary of that. I said these custom kernels on a sammy rom are better that they are on an AOSP rom for power consumtion.
xclub_101 said:
so any point that somehow any information relevant to power consumption is missing - when actually the custom open-source kernels are demonstrably better in this regard - now stands forever debunked
Click to expand...
Click to collapse
I really don't think you are managing to get any point you're trying to make across. You're not even arguing against the point I made. Surely a rebutal must directly address my points. You seem to be meandering aimlessly, taking pot shots at what you *think* is my point.
Again, I never said anything about information pertaining to power consumption being missing. My point is simple and basic, so here it is again. We do not have everything to run the hardware optimally. Whenever this is the case, performance suffers. If it is not running as originally intended because sources are missing to provide proper and full support, things are inefficient. Inefficiencies can lead to more power being used than is needed. That's all I was saying. You seem to be going out of your way to argue points I didn't even make, and not even graciously.
Edit>
Link for reading:
http://www.xda-developers.com/android/samsung-aware-of-exynos-documentation-issue/
slaphead20 said:
Without the exynos source the cm kernels can't take full advantage of exynos power saving features..... Simple.
On another note, I suggest you tone down your attitude, and apologise for calling rootSU childish, and don't treat this place like somewhere you can come to wind people up or I will personally introduce you to the moderators
Click to expand...
Click to collapse
I would just put him on ignore. It won't be the first time he's acting like an obnoxious know-it-all and it certainly won't be his last. For all his talk, I haven't seen him contribute anything remotely useful to any sort of development, just pointless ranting, raving and demanding.
Hi guys
Release 0.4 http://forum.xda-developers.com/showpost.php?p=45243784&postcount=48
New in this release is USB Fast Charging support (must be enabled via new kernel interface, see post for details)
Da_G said:
Old version 0.3 http://forum.xda-developers.com/showpost.php?p=45202710&postcount=28
Old version 0.2. http://forum.xda-developers.com/showpost.php?p=45198825&postcount=25
Old version 0.1! http://forum.xda-developers.com/showpost.php?p=45186352&postcount=18
Click to expand...
Click to collapse
Some of you might remember me from a time long ago and a galaxy far away!
I built/maintained dagkernel on release day for the Note 1, bringing root+overclock+recovery on day one of release
Well, recently my home was burglarized and all of my electronics taken. I took a very big ol hit that made me a sad panda Along with this stuff was my fancy-pants Alienware M18X laptop (minus the power brick, so they can't use it!) - which had all my source codes and development enviornments on it.
Rather than cry over spilt milk (really, I cried for a week! ) I decided I would re-build my development enviornment and crank out a new kernel for Galaxy Note, which is the most powerful computing device I currently have! (I am developing on an old school core 2 duo w/1GB RAM that sure feels slower!)
So, build enviornment is set up and the first build is done. Which is simply a re-built ramdisk and kernel from AT&T source. Using the newest available prebuilt toolchain from Google. I won't release this version as pretty much nothing is changed. But I wanted to get my dev enviornment up and running A first release with actual, substantial changes should be available within the day.
Support will include 4.1.2 stock ROMs (for the S-Pen love), CM, and whatever else I might support (suggestions?!)
GPU/CPU overclock will be supported, with the separate interfaces for overclocking each via an app. Hopefully I can actually push the app out this time around, it stayed internal only last time (although all frequencies and voltages were changable via boot script)
I took a look at the existing 4.1.2 kernels floating around and noted that most of them neglected some patches I made to Samsung's original source that did some funky things like re-set CPU1 (the second CPU) to stock speeds after toggling it off (for power saving)
As a result, the performance of these kernels is probably not quite what it should be after the first CPU shuts off (which happens almost immediately after android is done booting fully, when the load demand on the CPU(s) die)
Of course, my source will be public as it has been since day 1 and anyone is welcome to source my patches without asking. Viva la developers!
May your Galaxy Note run faster than this pos Dell desktop I'm using real-soon-now(tm)
Reserved for the use of the futures.
Reserved for the use of the futures.
Cool beans. Looking forward to this
Sent from my SAMSUNG-SGH-I717 using XDA Premium 4 mobile app
Welcome back
Sent from my SAMSUNG-SGH-I717 using XDA Premium 4 mobile app
Da_G!!!!!! Welcome back
2$HAYNE
Yes, welcome back Da_G. I'm sure there are a ton of us that remember your great work. Looking forward to some more.
Sent from my SAMSUNG-SGH-I717 using Tapatalk 4
Sorry to hear about your stuff!
I'm glad you're still able to churn out things like this though! Keep up the good work!
Welcome back! I loved your old stuff back in the day. Bring on the awesomeness!
Sent From My JellyBeanSandwiched Galaxy Note
ROM: Jellybean Sandwich w/ Hotcakez 1.8ghz kernel
Extras: Viper FX audio engine w/ Buzz Launcher
Sorry for the loss! But I'm glad you're back
Sent from my SAMSUNG-SGH-I717 using xda app-developers app
Sorry to hear of your trouble but glad to hear you're back on your Note development...a big plus for us! Welcome back Da_G!
Very sorry for your break in. Seems the world is full of d-heads. Glad nothing more than stuff was affected.
Welcome back. Of course we remember you. You're one of the first, and best at this Note stuff. Looking forward to seeing what you can put together. Let us know what you need from us.
Do your thing, man and welcome back!
you dont know me, but your reputation precedes you and I am aware of your quality of work.
I will send you a big welcome back
Welcome back :good:
I will have a first release out shortly. Just testing the impact of mpdecision on cpu performance.
For reference at OC to 1.83ghz/performance gov I was able to pull 9556 on antutu benchmark with performance gov and mpdecision disabled, ~6320 prior to overclocking. GPU is at 300MHz.
With ondemand gov and mpdecision enabled, looking around 8550. Lets try with performance gov and mpdecision enabled now...!
These scores seem about on par from what I remember from the first go-round I don't yet have the configuration sysfs interfaces set up.
Wow u know ure stuff n that really sucked about ur belongings but glad ure back in the community! I don't own a i717 but love to see all the roms u guys provide brings envy (in a good way) since my t879 has disappeared lol but good luck n the guys look very excited ure back... Lucky them cheers :beer:
Sent from my SGH-T879 using xda premium
Da_G said:
I will have a first release out shortly. Just testing the impact of mpdecision on cpu performance.
For reference at OC to 1.83ghz/performance gov I was able to pull 9556 on antutu benchmark with performance gov and mpdecision disabled, ~6320 prior to overclocking. GPU is at 300MHz.
With ondemand gov and mpdecision enabled, looking around 8550. Lets try with performance gov and mpdecision enabled now...!
These scores seem about on par from what I remember from the first go-round I don't yet have the configuration sysfs interfaces set up.
Click to expand...
Click to collapse
Awesome bro. How is the battery life? You going to put this out tonight?
Here is a first version, in TWRP/CWM compatible zip file. It is set to 1.83Ghz/300Mhz OC ondemand by default, with mpdecision left enabled. You should be able to use a tool like system tuner to change cpu frequencies and governors. I did not yet enable init.d support for a script in /etc/init.d to change frequencies on boot. It is on my to-do
This build is for 4.1.2 Stock/TW-based ROMs and most likely won't work on CM. Again, that's coming soon
As for battery life, I really don't know yet. I haven't had the phone disconnected from the computer during development, and this computer is so much slower than my old one I don't dare waste time doing things like that just yet. You guys try and let me know
I am thinking about 4 distinct releases,
High Power 4.1.2/Stock and CM
Power Save 4.1.2/Stock and CM
That way I can make one for balls-out speed and one for day to day use. I'm a fan of speed since I have an external battery charger and 4 batteries.
Da_G said:
Here is a first version, in TWRP/CWM compatible zip file. It is set to 1.83Ghz/300Mhz OC ondemand by default, with mpdecision left enabled. You should be able to use a tool like system tuner to change cpu frequencies and governors. I did not yet enable init.d support for a script in /etc/init.d to change frequencies on boot. It is on my to-do
This build is for 4.1.2 Stock/TW-based ROMs and most likely won't work on CM. Again, that's coming soon
As for battery life, I really don't know yet. I haven't had the phone disconnected from the computer during development, and this computer is so much slower than my old one I don't dare waste time doing things like that just yet. You guys try and let me know
I am thinking about 4 distinct releases,
High Power 4.1.2/Stock and CM
Power Save 4.1.2/Stock and CM
That way I can make one for balls-out speed and one for day to day use. I'm a fan of speed since I have an external battery charger and 4 batteries.
Click to expand...
Click to collapse
Seems like everything is running a-ok. I'm using it now Going to test it for the next couple days and see how it runs
Feels a little sluggish to me right off the bat. Tweaking the speed/governor with an app brings it right up to snappiness. Not too bad for a first run on an entirely new(to me) anciently slow computer, though. Only gets better from here
Sent from my SAMSUNG-SGH-I717 using xda app-developers app
So my new redmi 3 is on its way. I've chosen this phone over redmi 4a because of kernel source already available. I love tinkering, modifying and compiling kernel. But before doing so, I need to know which rom are stable for daily usage, with better battery life and overall stability, because I'll be compiling the kernel against the rom and I'll be looking into the kernel source while waiting for the phone to arrive.
From my reading on the threads here so far, I understand that miui roms have better battery life than cm roms, is that still true? Is it noticeable better on miui compared to cm? How about stability, are cm roms still buggy?
Thank you for any feedback :highfive:
LineageOS ?
Inviato dal mio Redmi 3 utilizzando Tapatalk
CM ROMs are really really stable. For me, they feel more stable than MIUI simply because some of the MIUI modifications make some apps bug out (like the battery saver and notification shade).
On the battery side, though, MIUI is way ahead of CM in terms of battery. The hotplug in CM ROMs is INCREDIBLY bad. The one in the latest LineageOS build is always keeping 1 BIG core active (that's the default setting for it) and turns on BIG cores at any touch of the screen. Previous builds had no hotplug, and other CM-based ROMs have some horrible hotplug who turns on little cores and high demand and always keeps the BIG ones active. All of them. Seriously, some ROMs heat up faster when keeping the phone idle with the screen on than MIUI does with hotspot active.
As a battery comparison, MIUI has like 8-9 minutes/1% and CM had 2-3 minutes/1% (SoT) for light tasks. It's now better for CM, like 5-6 minutes, but still a lot behind.
Since you want to modify the kernel, the above battery issue is something you might want to modify, though. You could even get some contributions for LineageOS to make it better for everyone.
vlt96 said:
CM ROMs are really really stable. For me, they feel more stable than MIUI simply because some of the MIUI modifications make some apps bug out (like the battery saver and notification shade).
On the battery side, though, MIUI is way ahead of CM in terms of battery. The hotplug in CM ROMs is INCREDIBLY bad. The one in the latest LineageOS build is always keeping 1 BIG core active (that's the default setting for it) and turns on BIG cores at any touch of the screen. Previous builds had no hotplug, and other CM-based ROMs have some horrible hotplug who turns on little cores and high demand and always keeps the BIG ones active. All of them. Seriously, some ROMs heat up faster when keeping the phone idle with the screen on than MIUI does with hotspot active.
As a battery comparison, MIUI has like 8-9 minutes/1% and CM had 2-3 minutes/1% (SoT) for light tasks. It's now better for CM, like 5-6 minutes, but still a lot behind.
Since you want to modify the kernel, the above battery issue is something you might want to modify, though. You could even get some contributions for LineageOS to make it better for everyone.
Click to expand...
Click to collapse
Thank you for the reply!
The hotplug issue can easily be mitigated by either adding thirdparty hotplug standalone driver or inbuilt in cpu governors. I'm not sure which hotplug implementation does default miui/cm kernel uses, either standalone driver or inbuilt in cpu governor because i dont have the phone yet, but adding thirdparty standalone hotplug driver are definitely in my plan for the kernel. They usually give much more refined control on the cpu core hotplugging mechanism. Plus with thirdparty thermal driver, it should be way better than the default one in those miui/cm kernels.
Actually i like cm based rom better than miui, but reading the cm/mokee/rr threads made me believed that they're more buggy and more battery hungry than miui roms.
nulldash said:
Thank you for the reply!
The hotplug issue can easily be mitigated by either adding thirdparty hotplug standalone driver or inbuilt in cpu governors. I'm not sure which hotplug implementation does default miui/cm kernel uses, either standalone driver or inbuilt in cpu governor because i dont have the phone yet, but adding thirdparty standalone hotplug driver are definitely in my plan for the kernel. They usually give much more refined control on the cpu core hotplugging mechanism. Plus with thirdparty thermal driver, it should be way better than the default one in those miui/cm kernels.
Actually i like cm based rom better than miui, but reading the cm/mokee/rr threads made me believed that they're more buggy and more battery hungry than miui roms.
Click to expand...
Click to collapse
Buggy, not at all. Battery hungry not really, just that MIUI has better optimisations.
My vote is for CM/Lineage. I am currently on Mokee CM/Lineage Marshmallow. It would be great if there was a hotplug option available.
Please build it for CM/LineageOS
It would be nice if you can add better hotplug driver and options to underclock the GPU for better battery life
@nulldash check PM
Hello,
I'm actually vote for LineageOS based ROMs instead because the kernel source is complete. Xiaomi's official source code doesn't include Prima WiFi driver.
OP, choice is on your hand, and up to you. We could only expect for things to come.
Sent from my ASUS_Z00A using XDA Labs
krasCGQ said:
Hello,
I'm actually vote for LineageOS based ROMs instead because the kernel source is complete. Xiaomi's official source code doesn't include Prima WiFi driver.
OP, choice is on your hand, and up to you. We could only expect for things to come.
Sent from my ASUS_Z00A using XDA Labs
Click to expand...
Click to collapse
i actually already expected that their original source are incomplete and broken like what they always did with their kernel source release, hence i'm syncing cm14.1 kernel source. unless cm did major changes in their source especially in graphic driver, the kernel would theoretically boot on any lp, mm and n roms if using anykernel zip installer.
already succesfully built the kernel but my phone didnt arrive yet to test :laugh:
nulldash said:
already succesfully built the kernel but my phone didnt arrive yet to test :laugh:
Click to expand...
Click to collapse
Lol,
As for AnyKernel2 template, we need to remove BusyBox in order for the template to work correctly. I've uploaded the modified one if people want to use it as the base (it's also a part of my build script).
Sent from my ASUS_Z00A using XDA Labs
I have always wondered how to achieve great camera results with custom Roms. I know it is kind of off-topic, but it would be nice to have a kernel with xiaomi's camera source for lineageOS etc. Though, I have no idea if the kernel source release included camera sources.
George_ioannidis said:
I have always wondered how to achieve great camera results with custom Roms. I know it is kind of off-topic, but it would be nice to have a kernel with xiaomi's camera source for lineageOS etc. Though, I have no idea if the kernel source release included camera sources.
Click to expand...
Click to collapse
I think no. Blame Xiaomi why they release incomplete sources
Sent from my ASUS_Z00A using XDA Labs
I prefer MIUI and I would appreciate the function DT2W (double tap to wake).
The most stable rom I've ever seen is RRemix. Battery life is great and there are no bugs (at least I did not see)
vesi said:
I prefer MIUI and I would appreciate the function DT2W (double tap to wake).
Click to expand...
Click to collapse
There is already a kernel for miui with dt2w. I would like one for lineage with dt2w
Enviado desde mi Redmi 3 mediante Tapatalk
could anyone upload, or just paste the content of /system/etc/init.qcom.post_boot.sh please? if want to paste please use code tags to preserve whitespace
nulldash said:
could anyone upload, or just paste the content of /system/etc/init.qcom.post_boot.sh please? if want to paste please use code tags to preserve whitespace
Click to expand...
Click to collapse
I'm on lineage official nightly, can't find what are you looking for
ainurrofiq said:
I'm on lineage official nightly, can't find what are you looking for
Click to expand...
Click to collapse
It's on the root of the ramdisk.
Sent from my ASUS_Z00A using XDA Labs
krasCGQ said:
It's on the root of the ramdisk.
Click to expand...
Click to collapse
So I have to unpack boot.img first?
I'll send boot image for you
---------- Post added 26th January 2017 at 12:23 AM ---------- Previous post was 25th January 2017 at 11:56 PM ----------
ainurrofiq said:
So I have to unpack boot.img first?
I'll send boot image for you
Click to expand...
Click to collapse
https://drive.google.com/file/d/0B4H7TUQI5FnxSU8tZEVKam83a0E/view?usp=sharing