FrameBuffer colors need fixed in AOSP based kernels. - Samsung Epic 4G Touch

According to the Screencast dev, they are currently be set as BGR when they should be RGB. This causes screwy colors when using screen capture apps such as Screencast. Here is a quote.
This is a framebuffer driver issue (kernel). Basically the kernel is setting a flag in the framebuffer driver to say the colors are arranges as BGR (blue, green, red) when in fact they are RGB. Nothing would normally need this information since everything goes through the Surfaceflinger (Android framework) except the bootup display, and Screencast.
Click to expand...
Click to collapse
If you want to see this bug in action, just download screencast and test on a AOSP/AOKP, etc.. based rom. Bug does not occur on none source roms, such as TW.

Please read forum rules before posting and the stickies!
This does NOT belong in Original Development
Moved to General

My apoligies. I figured it indeed had to do with developement (a kernel fix needed). My mistake. I would of never thought to put something develomental in the general section.

Takenover83 said:
My apoligies. I figured it indeed had to do with developement (a kernel fix needed). My mistake. I would of never thought to put something develomental in the general section.
Click to expand...
Click to collapse
If you read you might have. You didn't develop anything to put in development.
I like to break stuff!

Related

[DEV] Fixing/Updating the HD2 kernel and missing code

Please stay ON TOPIC to kernel DEV and missing code. Don't report every bug the Android build your using is having or it will be deleted as OFF TOPIC
As you all might be knowing that hd2 is pretty much a android native device now. Its just like any another snapdragon device. The current kernel code we are using in HD2 is pretty obsolete and missing a lot of things. It more like something working at its minimal efficiency. While i was porting over all the HD2 board files getting it on par with the other snapdragon devices I found out a lot of code was missing and some was obsolete. Eg. The gsensor code from microp was pretty minimal, a lot of things were missing in microp code. I suspect that it isnt the only code, a lot of bluetooth related stuff was missing and much more. I am not really gonna work on backporting the stuff to .32 kernel so i would like the kernel devs here to backport the stuff to the .32 kernel so a lot of bugs can be fixed and stuff can be made more stable until the .37 kernel is ready. All the commits can be found here
https://github.com/charansingh/cm-kernel/tree/master
There might be some bravo or passion instances in there cuz i am comparing the code with these two devices and taking what is necessary and sometimes i have to leave my work due to some other work and forget which file i was working on so would appreciate the more bugs.
Also Mods can we get this a sticky so we can track the progress here
Yap.. i'm not a really pro developer but i suspected those bugs before.. finally a real developer suspected that.. eager to see who's going to help fixing them
charnsingh_online said:
Also Mods can we get this a sticky so we can track the progress here
Click to expand...
Click to collapse
Ok sticky for the moment to see if it helps.
@charnsingh_online
I am really happy that you put so much power in this project big respect for that.
The reason for the missing code is because most of the drivers are reversed engineerd from winmo by cotulla. Wich make it possible to make working android parts but they don't work optimal by that. Also we miss some skilled active coders. After cotulla almost everything is created by markinus he did a incredible part big credit to him but looks like he isn't that active anymore..
Current development are mostly little things a guy who sees a little part from that and a little part from that like : you, tytung, darkstone, gauner,letama, the guy from the bluetooth fix.
We probaly don't have so much real kernel programmers because they buy a native linux / android phone.
The last two major things left with HD2 Android are buggy speakerphone and missing assisted-gps function.
Speakerphone mode is not usable because mic gain does not change when speakerphone is enabled. Info here:
http://forum.xda-developers.com/showpost.php?p=12698204&postcount=22
GPS works but without assistance so most locks take 1 minute instead of like 15 seconds. Info here: (please read all 25 pages)
http://forum.xda-developers.com/showthread.php?t=1008252
memin1857 said:
The last two major things left with HD2 Android are buggy speakerphone and missing assisted-gps function.
Speakerphone mode is not usable because mic gain does not change when speakerphone is enabled. Info here:
http://forum.xda-developers.com/showpost.php?p=12698204&postcount=22
GPS works but without assistance so most locks take 1 minute instead of like 15 seconds. Info here: (please read all 25 pages)
http://forum.xda-developers.com/showthread.php?t=1008252
Click to expand...
Click to collapse
actually i think the gpu drivers are kinda unstable when comparing to the performance of other phones that carry the similar gpu...
@charnsingh_online
Good start.
After reading the github commits, I still don't understand what kernel devs can do so far.
Just see the microp stuff I added to the file. Also I have updated the board files. See wats the difference between the files. A lot of updated code
hi charansingh,
i am willing to help, but i think it would be helpfull to define packets to take over.
By looking in the kernelsources it looks good to me, but i know from own expiriences with porting that i have to look deep...
best regards
trilu
charnsingh_online said:
Just see the microp stuff I added to the file. Also I have updated the board files. See wats the difference between the files. A lot of updated code
Click to expand...
Click to collapse
It's better to start/clone from pure CM 2.6.37 kernel, then add new commits when adding any new functions.
Would you please add a new commit when adding a new function?
Otherwise, it's very easy to lost the way in the source code.
A commit "Update some board files" doesn't tell the whole story. I want to know why to change.
Comparing the source code manually and guessing its function is not convenient for any kernel devs.
For me, I won't add any code in my 2.6.32 kernel until I know the meaning of the changes of the source code.
Thanks.
Ok I'll do it tomorrow n also maintain the list in the op
I may be wrong, but this thread is not supposed to become a bug fix request thread. It is aimed at developpers, so that they collaborate on a merging of HD2 specific stuff onto a cyanogen 2.6.37 kernel...
This would most likely result in the resolution of a lot of our issues, but in the mean time, [DEV] in the thread title means it is for devs only......
Keep this thread clean please.. there are only a select few devs who actually work on kernels around here. Let them use this as a way of communication to generate a complete kernel, then we can test it for bugs.
Very excited about the prospects of this, if you guys get a working kernel with all the new commits shoot it over and I'll test it out on one of my HD2's.
I looked pushed code and it's ok, at least for first few commits. But it needs some deep cleaning an optimization, also there is some bravo naming convention used in leo specific files. You should put this tree on gitorious so we can do more work on it, but anyway i will clone tree and do some cleaning and porting new stuff.
This could be of interest, and not too much off-topic.
This kernel: http://forum.xda-developers.com/showthread.php?t=966786
is being abandoned and it had some patches for performance that I think are valuable. It had linpack scores that can be achieved only with heavy overclocks on other kernels... The problem is, the source is being distributed by a .zip, no commits, nothing... the only way to get those would be to issue a diff with... something and guess where they are. Staying on topic, I've already adapted cm-kernel for another device so I think I'll be able to help when I get enough free time to spare.
D4rk50ul said:
Keep this thread clean please.. there are only a select few devs who actually work on kernels around here. Let them use this as a way of communication to generate a complete kernel, then we can test it for bugs.
Very excited about the prospects of this, if you guys get a working kernel with all the new commits shoot it over and I'll test it out on one of my HD2's.
Click to expand...
Click to collapse
Yes you are right. Unfortunately many threads like this one get's filled with off topic chatter, complaints etc. I will try to keep my eye on this thread so the dev's can communicate. If your not contributing to the DEV work on the HD2 kernel's, please don't post your wishes and thanks post as this will quickly clog up the thread. I'd hate to lose progress due to this. That's why many DEV's end up not using XDA and reverting to IRC only. Thanks
noellenchris
Hi,
Few days back there are some conversation about libsurfaceflinger.so for color banding issue http://forum.xda-developers.com/showthread.php?t=1012278 . Since Rom is changing continuesly with libs can we port the change for color issue.
HD2 GB-2.33-SENSE-2.1 LOCKSCREEN SENSE-3
tytung said:
It's better to start/clone from pure CM 2.6.37 kernel, then add new commits when adding any new functions.
Would you please add a new commit when adding a new function?
Otherwise, it's very easy to lost the way in the source code.
A commit "Update some board files" doesn't tell the whole story. I want to know why to change.
Comparing the source code manually and guessing its function is not convenient for any kernel devs.
For me, I won't add any code in my 2.6.32 kernel until I know the meaning of the changes of the source code.
Thanks.
Click to expand...
Click to collapse
tytung, has any1 of you done so? please let us know..
g30rg10u said:
tytung, has any1 of you done so? please let us know..
Click to expand...
Click to collapse
No, I didn't work on 2.6.37 kernel so far.
I didn't see that charnsingh_online added a TODO list in the OP.
Fried my laptop charger. New one on way. Hd2 arrived

software under device forums?

Is this a good idea? as it causes fragmented discussion, eg. dt-apps2sd is something that works across devices but I see it discussed under one particular device meaning generally only owners of that device will take part in that discussion. BLN is another example.
chrcol said:
Is this a good idea? as it causes fragmented discussion, eg. dt-apps2sd is something that works across devices but I see it discussed under one particular device meaning generally only owners of that device will take part in that discussion. BLN is another example.
Click to expand...
Click to collapse
BLN though can be pretty device specific... Even down to the actual kernel you're using... I think there's always going to be a need for device-specific discussion of these things tbh - I doubt that would change
Or a mod for a Sense ROM, wont work on different Sense ROMs and non Sense ROMs etc.
yeah roms make sense of course that doesnt bother me, was just a thought tho

[REQ] Guess what? Right, 3.0 kernel.

@Kernel devs,
Please, congregate your forces and build 3.x kernel for our precious Arc. I bet this will be one of the most (if not The Most) appreciated works. I bet this will be one of the most useful ones too. I bet almost every Arc/S user will agree with me.
Sent from nowhere
Absolutely!
What are the features you are waiting for in 3.0?
soo what does the new kernel provide?! I've seen few comments about users wanting the new kernel, and was wondering what improvement will it do to our Xperia?!
Mods please move this thread to general or Q&A. This thread is for android development, not wish lists.
Yes we'd all love a new kernel, why not bump to 3.5, well the answer to that is closed source drivers. While we should be able to theoretically add most of the maintenance patches to get to the latest 2.6.32.xx, porting to different major versions are just unlikely to be possible for our phone. You can't link against something with a different API, it just won't work.
The first request should be made to Sony to release sources for these drivers. Good luck with that.
So instead of focusing on version numbers, instead ask "Is feature X possible with our current kernel" and the kernel devs will try to accommodate and patch it in.
First of all, this isn't for Wishes and Requests, this is where you share you dev work with everyone, if you have a request then go to general or Q&A.
Second, EVERY DEVELOPER ALREADY KNOWS ABOUT THIS. Everyone IS WORKING on Kernel 3.0, ICS was laggy and JB isn't perfect is because the the lack of support in the kernel. So they don't need a "request"
Third, it is not impossible but very very hard. There is a reason why kernel 3.0 was never ported, because even the best devs like FXP and DoomLord CAN'T. Unless Sony releases their hardware sources or some developers open up his own Arc and get it out, no kernel 3.0 can be ported!
Custom msm7x30 3.0 kernels are still really in infancy stages with no major changes. If anything it's just a facelift but still the same purpose-wise.
Well, for those saing that devs can't do something I would argue - there's a 3.0 kernel being developed for HTC Desire (which also has closed source drivers) and guys working on it are pretty close. Same goes for HTC DHD and HD2 if i'm not mistaken. So why not for our device?
Sent from nowhere
tajimura said:
@Kernel devs,
Please, congregate your forces and build 3.x kernel for our precious Arc. I bet this will be one of the most (if not The Most) appreciated works. I bet this will be one of the most useful ones too. I bet almost every Arc/S user will agree with me.
Sent from nowhere
Click to expand...
Click to collapse
+ over 9000!
---------- Post added at 09:49 AM ---------- Previous post was at 09:40 AM ----------
It would be just awesome, beacuse idiots from Sony will pobably never update our kernels. Even HTC Wildfire S (which is little, smarttoy) has 2.6.35.x. It's not big difference, but... It is!
pmdisawesome said:
First of all, this isn't for Wishes and Requests, this is where you share you dev work with everyone, if you have a request then go to general or Q&A.
Second, EVERY DEVELOPER ALREADY KNOWS ABOUT THIS. Everyone IS WORKING on Kernel 3.0, ICS was laggy and JB isn't perfect is because the the lack of support in the kernel. So they don't need a "request"
Third, it is not impossible but very very hard. There is a reason why kernel 3.0 was never ported, because even the best devs like FXP and DoomLord CAN'T. Unless Sony releases their hardware sources or some developers open up his own Arc and get it out, no kernel 3.0 can be ported!
Click to expand...
Click to collapse
Work had already begun (with a lot of help from Jimbo77). It is stopped now (holidays) but for sure it's not abandoned.
tajimura said:
Well, for those saing that devs can't do something I would argue - there's a 3.0 kernel being developed for HTC Desire (which also has closed source drivers) and guys working on it are pretty close. Same goes for HTC DHD and HD2 if i'm not mistaken. So why not for our device?
Sent from nowhere
Click to expand...
Click to collapse
Because there is no Sony msm8255t 3.x kernel released that we can use as a base. There are major changes between 2.6.3x and 3.x kernel so
-all hardware related files (read: cpu, vibra etc) must be updated
-all drivers (read: screen, keys, sound etc) must be updated or rewritten
so it takes a lot of time and learning.
It's done when it's done
Click to expand...
Click to collapse
gen_scheisskopf said:
Work had already begun (with a lot of help from Jimbo77). It is stopped now (holidays) but for sure it's not abandoned.
Because there is no Sony msm8255t 3.x kernel released that we can use as a base. There are major changes between 2.6.3x and 3.x kernel so
-all hardware related files (read: cpu, vibra etc) must be updated
-all drivers (read: screen, keys, sound etc) must be updated or rewritten
so it takes a lot of time and learning.
Click to expand...
Click to collapse
first and bigest major new funcion is ntfs suport(for me there are, also sove with batery iporvents , also ksm is form 3.0.16 or 3.0.8(with used in cm roms))
n1kolaa said:
first and bigest major new funcion is ntfs suport(for me there are, also sove with batery iporvents , also ksm is form 3.0.16 or 3.0.8(with used in cm roms))
Click to expand...
Click to collapse
I had internal functions in mind (like ssize_t(*show) ), not user level.
Why would anyone think that this thread belongs in Development section, is beyond me.
Moreover, why would anyone think that in such community, known for the breakthroughs that its developers are achieving at a daily basis, such a request thread is needed.
I would like to believe that anyone who has been here long enough knows that if something is possible, it is done.
So, all in all, please think twice before clicking the "Start A New Thread" button.
Thanks for your cooperation.
Thread closed.

RAM hack impact to the Hardware Acceleration playback

I like the idea of reclaiming GN's reserved RAM, but we all understand there is no free lunch, those threads only mention 1080p record or playback support, what drawbacks of those RAM hack brought to us exactly?
I don't think most users who flash those kernel or even some kernel developer was acknowledged that. (especially who don't own a GN themself)
I keep seeing phase like "no known negative effects", "The ram being freed comes from things like 1080p playback/recording and other such things that keep ram even when not being used" .
They are wrong.
I test with a few video, show that all RAM hack has more or less backfire to GN's HW play-back ability, quick conclusion:
1. ASRAM is better than BigMEM. ( I just quote them by name, which I read in kernel thread, not pretent knowing what they are...).
2. Stock 693MB is better than ASRAM.
Two chopped video is attached,
When I said "better", I mean the kernel can allow more video files decode in hardware acceleration mode, aka, HW or HW+. Basically there is no video can play in HW mode with BigMem kernel. ASRAM can't play output.mp4 in HW mode, while outputb.mp4 is fine.
If by any chance you don't understand what is the difference between HW & SW playback...
Well, in short, HW will use less CPU to play a video, which lead to better battery performance, much better. I also tested that, it depends on you screen backlight and specific video parameter, in my test, SW mode will consume 2-3 times battery compare to HW mode.
Final conclusion:
If you watch video a lot (most online video is code by AVC1 ), avoid BigMEN hack kernel like superRAM, it's up to you whether use ASRAM though.
NOTICE: all 4.3 or later ROM may need another fix to play video without lag.
http://forum.xda-developers.com/showthread.php?t=2559138
This fix was discovered by @oubeichen
For the record, none of the test video is 1080p
So that's why some videos won't play smoothly on my gnex..
I guess i'll reserve such functions to my n7.
But when i was using no ASRAM/BigMem types like Trinity Kernel the HD playback was choppy too, since the 4.3.x + update everything messed up .
Ashtrix said:
But when i was using no ASRAM/BigMem types like Trinity Kernel the HD playback was choppy too, since the 4.3.x + update everything messed up .
Click to expand...
Click to collapse
Exactly.
I have a 1080p video and it was playing smoothly on 4.2.x but it shutters in 4.3+ Roms.
Sent from my Galaxy Nexus using xda premium
Ashtrix said:
But when i was using no ASRAM/BigMem types like Trinity Kernel the HD playback was choppy too, since the 4.3.x + update everything messed up .
Click to expand...
Click to collapse
That is another issue, and the fix is in the OP too, please refer to this link:good:
http://forum.xda-developers.com/showthread.php?t=2559138
seriousia said:
Exactly.
I have a 1080p video and it was playing smoothly on 4.2.x but it shutters in 4.3+ Roms.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
That is another issue, and the fix is in the OP too, please refer to this link:good:
http://forum.xda-developers.com/showthread.php?t=2559138
Mach3.2 said:
So that's why some videos won't play smoothly on my gnex..
I guess i'll reserve such functions to my n7.
Click to expand...
Click to collapse
No, not exactly. The decoder binary has problem since Android 4.3, there is a fix by reverting to 4.2.2 binary, as I said in OP or you can refer to this link:
http://forum.xda-developers.com/showthread.php?t=2559138
SW does the decode thing all by CPU, and GN's 1.2G CPU is OK to deal with many video, you won't notice difference between HW from SW except the battery drain in most of the case.
I've read the source of BigMEM and ASRAM, they are the same thing. They just used try & error way to "find out" that took 50MB from the heap_tiler instead of the more aggressive 70MB will keep the carama 1080p work, nothing sophisticated. Those developer didn't realize this heap not only relates to the ability video can play or not, but also hardware decode ability.
Honestly, I hope they don't realize that, or they were lying and put the blame on application
randommmm said:
I've read the source of BigMEM and ASRAM, they are the same thing. They just used try & error way to "find out" that took 50MB from the heap_tiler instead of the more aggressive 70MB will keep the carama 1080p work, nothing sophisticated. Those developer didn't realize this heap not only relates to the ability video can play or not, but also hardware decode ability.
Honestly, I hope they don't realize that, or they were lying and put the blame on application
Click to expand...
Click to collapse
How did you come to a conclusion that they were lying? And some developers DID realise that video playback is also broken and even has that mentioned in their threads. Or indirectly mentioned that things may break by making different variants for different users.
And by the way if you want 100% stable and working phone, xda or any other place that encourages you to tweak your phone is a complete no-no for you.
Sent from my Galaxy Nexus using Tapatalk
Most devs mention that this "hack" breaks "things".
The matter is how important to a certain user is the ability to play flawlessly every video available.
Most users aren't bothered at all...
"Bigmem" and "ASRAM" and bull****. They aren't anything special.
They do the same thing to a different amount. "Bigmem" reclaims more than "ASRAM" and "SuperRam" reclaims even more than "Bigmem".
Mpokwsths invented the technique and others just decreased the amount of reclaimed RAM.
The source is available, you could build your kernel with less RAM reclaiming and try to find the sweet spot for you.
Or if you are a hotshot try and build a kernel that gives back 900MB of RAM and keeps the video playback perfect.
Otherwise ... seal your lips and be more kind to the "developers".
@mods: This thread should be closed or at least moved to the appropriate section.
akash3656 said:
How did you come to a conclusion that they were lying? And some developers DID realise that video playback is also broken and even has that mentioned in their threads. Or indirectly mentioned that things may break by making different variants for different users.
And by the way if you want 100% stable and working phone, xda or any other place that encourages you to tweak your phone is a complete no-no for you.
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Do you read? I said If they know what they're doing, still claim "just some rare app will not work" , that is a lie in every definition. Did you ever read a line of source of any kernel or rom? Please shut-up before you've finished reading.(thumb down)
double post
antypas said:
Most devs mention that this "hack" breaks "things".
The matter is how important to a certain user is the ability to play flawlessly every video available.
Most users aren't bothered at all...
"Bigmem" and "ASRAM" and bull****. They aren't anything special.
They do the same thing to a different amount. "Bigmem" reclaims more than "ASRAM" and "SuperRam" reclaims even more than "Bigmem".
Mpokwsths invented the technique and others just decreased the amount of reclaimed RAM.
The source is available, you could build your kernel with less RAM reclaiming and try to find the sweet spot for you.
Or if you are a hotshot try and build a kernel that gives back 900MB of RAM and keeps the video playback perfect.
Otherwise ... seal your lips and be more kind to the "developers".
@mods: This thread should be closed or at least moved to the appropriate section.
Click to expand...
Click to collapse
Thankyou, XDA need more retard like you two, rate the thread 1 star? I don't care, did you read? Did you know the 4.2.2 fix? I post this topic is for those who read those OP like great CM, say goodie, goodie, and backfire? Sorry, we don't cover that, or we won't get some "donate", wow, bravo.
The most interesting thing is someone who don't own the phone can "create" a kernel for it , and still some stupid stand in the defense line for them. I like it. It worth a watch.:laugh:
@mods
I am totally fine if you feel like you should close this thread, I feel sorry for those user who using kernel not function as they'd expected. I feel even sorry for those developers who follow these BigMEM, ASRAM commits, making kernel they believe their kernel breaks nothing or just something rare use( like 1080p).
randommmm said:
Thankyou, XDA need more retard like you two, rate the thread 1 star? I don't care, did you read? Did you know the 4.2.2 fix? I post this topic is for those who read those OP like great CM, say goodie, goodie, and backfire? Sorry, we don't cover that, or we won't get some "donate", wow, bravo.
The most interesting thing is someone who don't own the phone can "create" a kernel for it , and still some stupid stand in the defense line for them. I like it. It worth a watch.:laugh:
Click to expand...
Click to collapse
I did know about the 4.2.2 Ducati engine fix... It was posted a few days ago.
So that doesn't make me a retard after all???
You are not only ungrateful to the devs that do things for free but you are a ***** that calls names as well...
I suggest that devs make memory-reclaimed kernel versions optional, and the stable version should use the stock ROM allocation to avoid any function impairment.
Or the users that don't want the extra RAM can build whichever kernel they desire from source after changing the RAM reclaiming values...
Simple as that.
randommmm said:
Do you read? I said If they know what they're doing, still claim "just some rare app will not work" , that is a lie in every definition. Did you ever read a line of source of any kernel or rom? Please shut-up before you've finished reading.(thumb down)
Click to expand...
Click to collapse
Even if I have read, android is God knows how many million lines of code and thousands of commits. They (kernel developers) never mentioned some rare app, they say it as a general thing. And please, even if I do not read github like a story book, I read OP and try my best to follow threads. And clearly most if not all made variants without RAM hacks or made variants that worked with most things. If that weird app doesn't work, screw it flash a kernel that doesn't mod with RAM. Or go fastboot flash to stock 4.3.
As pointed by others, you could make your own ram hack that is *better* or appreciate their work and accept the fact Galaxy Nexus sucked from day 1 in terms of RAM.
Seriously, if you're gonna rant you're also at the wrong section of the forum too. Have you read xda rules?
Sent from my Galaxy Nexus using Tapatalk
I think kernel with 40MB RAM reclaimed is safe for most 720p video.
Kernel with ASRAM(50MB) cannot play 720p video that ref > 7 with HW nor HW+ decoder.
And with 40MB declaimed can up to ref = 9.
Sent from my Galaxy Nexus using xda premium
This whole thread is just a giant ragefest, honestly it should be removed. I don't feel OP is correct in outright calling people liars, it's just not the appropriate way to get a point across in an adult developer community. Just because one individual has an issue with a particular app or a certain function properly working does not mean others will guaranteed have this same issue. With android we all do different tweaks, use different apps, kernels roms etc. This means that just because the particular apps you choose to use are not working because of Bigmem, Superram ASram blah blah blah, it doesn't mean it's an epidemic on all of our devices.
I have had no issues using MX Player or Youtube on HQ video setting with Superram, I haven't had a single reboot, freeze, app fc or anything else do to the SuperRam kernel, I've been using it since it first was released on 4.3. I use my custom settings with it as well. I am not trying to bag on randommmm, what I am merely doing here is saying that no one is right or wrong and the developers are certainly not liars.
On my custom kernel thread I have a poll on which kernel people prefer the most, as of right now 49 out of 73 people on there are using MPOkang superram kernel, none of them are complaining about it causing all these issues.
The OP of the Kernel clearly states that 1080p video playback/recording will not work, that is the only thing that is guaranteed to not work for sure, if you need 1080p on your device then simply do not use the kernel, quite simple.
With any kernel there is a chance of issues, but guess what? With any kernel settings there is a chance of problems too, just because people have certain issues with SuperRam kernel flashed does not mean it's superram, not everyone knows what they are doing when adjusting the kernel settings. Not to mention not every rom, especially 4.4.x roms, are going to work perfect.
I read randommmm's post about this on whatever thread he posted about it on, I personally do not feel this subject warranted it's own thread.
randommmm, I am in no way saying you don't know what you are talking about but..... until you have developed a kernel yourself you really should not be namecalling people that have. If this were as extreme of an issue as you are making it out to be there would not be so many using SuperRam kernel without complaint and there certainly would not be the vast amount of other kernel developers adding free ram modifications to their own kernels.
I sincerely mean no offence to anyone on this thread. I've been following it for a bit now and felt it was time to put my opinion in.
That is all.
Neph

Roll-iphon

Roll-iphon download: Mod edit: Link removed. <- this is the one best Google Play Edition 5.1 ROM!
The launcher animations with real iPhone.
To use animation rendering engine Project Butter.
Smooth and fast animation.
Very simple and clean design.
Put the camera, gallery, sms, street view, calendar, extended menu restart button, the screen went out.
My job icons live living clock, calendar, оriginal sounds.
Installation Instructions:
- install a custom recovery...
- download Roll-iphon rom zip
- reboot recovery
- Install Roll-iphon with Full Wipe
- reboot device
Thanks Based on Danvdh
Google Project Butter accomplished its “buttery smooth” responsiveness and “speed infusion” improvements via three main additions: triple buffering, which improves coordination and animation synchronization between the CPU, GPU and display; VSync, which improves graphical performance and increases frame rates to 60fps (frames per second); and touch responsiveness, which predicts a user’s upcoming actions of the screen in order to improve load times for those actions.new technology Project Butter, aimed at making the entire UI fast, fluid and enjoyable — one of the complaints against Android was that the interface is sometimes slow even on powerful machines. The technology includes triple buffering the graphics pipeline in order to ensure the absence of jumps in the frame rate in the animation interface, as well as technology enabled vertical sync.
XDA:DevDB Information
Roll-iphon, ROM for the Samsung Galaxy S 4
Contributors
rullert
ROM OS Version: 5.1.x Lollipop
Version Information
Status: Stable
Created 2015-10-25
Last Updated 2015-10-25
Is it a GPE rom with a launcher right? ?
This guy is trolling.
Need someone to close the thread.
Razov said:
Is it a GPE rom with a launcher right?
Click to expand...
Click to collapse
Yes, of course only the rest of the shell is almost original GPE -10-21 -2015 .
ImChoey said:
This guy is trolling.
Need someone to close the thread.
Click to expand...
Click to collapse
Since I'm not a fan of the ordinary made extraordinary 5.1
The only thing you 'made' is catch the zip and put an apk inside there and now there is a new rom?
Razov said:
The only thing you 'made' is catch the zip and put an apk inside there and now there is a new rom?
Click to expand...
Click to collapse
Yes, a new not old.
:laugh: :laugh: :laugh: cool
need to theme settings, statusbar and add control center to make it look like iphone...good idea, something completeley different, but need a lot of work
beafraid88 said:
need to theme settings, statusbar and add control center to make it look like iphone...good idea, something completeley different, but need a lot of work
Click to expand...
Click to collapse
I tried already, but it turns out worse than the original short I could not get who can give the necessary files here. Although so good to me personally.
Thread closed.
12. Using the work of others.
If you are developing something that is based on the work of another Member, you MUST first seek their permission and you must give credit to the member whose work you used. If a dispute occurs about who developed / created a piece of work, first try to settle the matter by private message and NOT in open forum. If this fails, you may then contact a Moderator and provide clear evidence that the work was created by you.
Convincing evidence will result in the copied work being removed. If there is no clear evidence that it was you who created the work, then in the spirit of sharing, all work will remain posted on the forums.
As an addition, developers have the right to hold exclusivity over their work for as long as it is deemed necessary by that developer. However, if the work is claimed as exclusive, it must remain as such. No selective sharing will be allowed (ie, allowing certain people to use it and not others). If the developer decides to start sharing the work with others, the work automatically becomes available for all to use, albeit with the relevant credit displayed.
When permission has already been given, unless there is a very valid reason, it cannot be revoked (same applies to major updates on the work). Under that same premise, permissions cannot be denied unless the work is exclusive or under extreme circumstances.
In plain English: If you want to keep your work exclusive, go for it. However, if you are going to share your work, do it fairly.
Reposted content, derivative or maintaned works based on that of former or banned members may be removed at our discretion.
These rules apply to all software posted on XDA (including but not limited to ROMs, RUUs, apps, games, kernels, themes, icons, etc) unless that software comes with a license that waives these rules.
Regards,
The_Merovingian
Forum Moderator

Categories

Resources