Related
02/12/11: Froyo boots, stability issues resolved, all used modules from source except graphics. Problems: radio does not work, camcorder crashes the camera app, likely more issues. Big thanks to TheBirdman, SuperCurio and all the other devs working like myself out there to make this dream a reality. Gingerbread will come after Froyo is stabilized. As promised progress is being made.
This is not a Blazed kernel but will share in code fixes and versatility.
Thanks to TheBirdman, SuperCurio and others who's patches are pulled from TheBirdmans git to improve Fascinate compatibility.
The Eclair source appeared to be coded by multiple seperate teams simultaniously whilst Froyo source appears to be developed by one team and the sammy sources for the devices with Froyo are incrementally getting more updates as they move from one device to another.
Source will be posted soon, i am traveling right now and wanted to share this breakthrough from earlier today. Hint for those who can not wait the I9000 Samsung source contains almost everything you need except a graphics driver and a proper config, compare fascinate_defconfig, aries_eur_defconfig and the eclair defconfig or pull config from this kernel ;-)
The link below is for an alpha quality non-voodoo test kernel with ext4, ipv6, and full netfilter built in plus alot of extra modules stored in /system/kmodules:
02/16/11: Froyo Source Now Online!
03/10/11: Source pulled from laststufo's ULTIMATE SUPER OPTIMIZED Kernel for Galaxy S I9000
Wifi is working as client, Sound is working again, 3G radio that sometimes worked has stopped working again. This maybe a good thing though as it has indicated we may have been side stepping too much and avoiding drivers that may be more compatible than what we were actually using. The cpu is spot on, the sound is now using wm8994 aries and not wm8994 universal master. I suspect many incompatibilities in the platform still, but progress is being made. I think we were all just seeing too little with tunnel vision because of stress and perhaps a lack of sleep.
There are a number of goodies from laststufo in this tree (ramzswap, compcache, what appear to be usb host otg support just to name a few) non of which I have tested on fascinate but all of which compiled without error. I have tested overclock up to 1200Mhz, it supports up to 1.6Ghz (I would be very careful about anything past 1.2Ghz). VSF (Variable Screen Frequency) sync is broken ( a new feature from laststufo ) until replacement for the accel_xyz function of the smb380 is found, as the smb380 is not supported on the Fascinate, just as the yamaha compass driver is not supported. VSF's purpose is to save battery by reducing screen refresh rate when the device is being used in a minimal activity type situation.
I have not posted working binaries or full source to git yet, but I plan to have a new binary voodoo and non-voodoo up with source hopefully by sometime monday (but please don't hold me to it if I'm a little late)
Source:
GITHUB: http://www.github.com/sirgatez Last Updated 02/12/11
Binaries:
Non-Voodoo: http://db.tt/Y66iNVu - Proof Of Concept Alpha 02/12/11
Sent from my SCH-I500 using XDA App
I think I'm in love with you.
Sad news: it would only be bromance.
Anyhow, thank you so much for your hard work, and please keep it up!
It's incredible what you guys can do.
yay.. its just a matter of time till u make some magical work in froyo kernel.
i think punkkaos mentioned in one of his tweets that he was working on kernel, and got hardware acceleration on UI working but had graphical glitches, but he said that it was awesome fast.
Would that be possible here too ?
I will be looking forward to seeing this beast run on my phone once it hits the beta stage.
Maybe I'm mislead, but doesn't the i9000 froyo kernel use an rfs filesystem?
Sent from my SCH-I500 using XDA App
papstar said:
Maybe I'm mislead, but doesn't the i9000 froyo kernel use an rfs filesystem?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
I think the nexus s is the only recent Samsung phone not using rfs. The rfs drivers in this kernel are in the stock i9000 source.
Sent from my SCH-I500 using XDA App
I should have source up by the end of the day heading home from hospital now.
I did some googling, correct me if I am mistaken but I can not seem to find the kernel module source for s3c_bc, s3c_lcd, or pwrsrv outside of Eclair. The eclair module for pwrsrv fails to boot, and the sizes of all 3 compiled binaries do not come close to the froyo ones from samsung. Both s3c modulea are less that or about 100k in froyo, eclair and eclair compiled against froyo are closer to 300k each. PowerVR driver is like 350k on froyo, and eclair and eclair compiled against froyo are 1.8/1.9MB. I did find a newer powervr driver from imagination last night but have to rework some code make it compile, and ti has the most recent driver from imagination but will not share unless you purchased a 1,600 evaluation board.
Sent from my SCH-I500 using XDA App
SirGatez said:
ti has the most recent driver from imagination but will not share unless you purchased a 1,600 evaluation board.
Click to expand...
Click to collapse
I can send a lot curse words TI's way atm.
Btw, how much performance do these drivers improve ?
3d accel nor graphics work without them. Sammies binary works as shown in the alpha posted but ti isnt to blame, imagination (imageon) makes and releases/licenses the driver and its code.
Just read an article saying they may opensource it in 3rd quarter this year I dont see that hindering us much right now with froyo, we can always dissassemble and recompile the binaries if we are left no other options to ensure gingerbread compatibility. Nexus S binary modules should work for gb testers at the moment, not sure how different froyo and gb powervr sgx drivers are right now but their are seemingly major internal changes from eclair to froyo. Every google result says both use the same gpu.
But Samsung is to blame for the lack of opensource froyo s3c_bc and s3c_lcd modules. But they look portable to froyo at the moment, will delve deeper into rabbit hole soon...
Edit: I have not tried to boot without loading these modules but when I compile and use the eclair powervr driver for froyo it driver load loops then boot loops then shuts down. The phone may work in 2d without them but I am doubtful. The kernel does have enough internal code (s3c_fb, s3c_cfb, etc) to display the i9000 startup image but the rest of the drivers are supposed to load before the bootanimation plays.
Sent from my SCH-I500 using XDA App
SirGatez said:
Just read an article saying they may opensource it in 3rd quarter this year I dont see that hindering us much right now with froyo, we can always dissassemble and recompile the binaries if we are left no other options to ensure gingerbread compatibility. Nexus S binary modules should work for gb testers at the moment, not sure how different froyo and gb powervr sgx drivers are right now but their are seemingly major internal changes from eclair to froyo. Every google result says both use the same gpu.
But Samsung is to blame for the lack of opensource froyo s3c_bc and s3c_lcd modules. But they look portable to froyo at the moment, will delve deeper into rabbit hole soon...
Edit: I have not tried to boot without loading these modules but when I compile and use the eclair powervr driver for froyo it driver load loops then boot loops then shuts down. The phone may work in 2d without them but I am doubtful. The kernel does have enough internal code (s3c_fb, s3c_cfb, etc) to display the i9000 startup image but the rest of the drivers are supposed to load before the bootanimation plays.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
Damn, that's neat info. Where does one go to learn all this neat stuff about kernel, decompiling binaries and then compiling them again for another OS ?
StDevious said:
Damn, that's neat info. Where does one go to learn all this neat stuff about kernel, decompiling binaries and then compiling them again for another OS ?
Click to expand...
Click to collapse
Kernel hacking is very similar to any other reverse engineering effort, an under standing of asm is needed, as well as the file layout of thr target binaries.
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Either way that isn't something I will be working on just yet unless an opensource driver for this surfaces we will use sammies for now and concentrate on making what we have stable. Fixing the radio and testing the other hardware are priority since the current binary froyo graphics driver does work atm. We will get an opensource version working later, if not then we worry about the the black box problem.
Sent from my SCH-I500 using XDA App
About 2 hours more research later I learned that a portion but not all of the PowerVR SGX/MDX drivers are open source, they are released like binary blobs with the open sourced portion of the driver enclosing the closed sourced blobs to function (much like how NVidia and ATI began their Linux Driver crusade), I will attempt to contact TI / Imagination for the open source portion of the drivers, they do not have them posted for public consumption but should have no problem providing access under the OSS/GPL. If anyone has these already they can send me a PM and it will save some time, likely the closest port that should work will likely be TI's OMAP34xx PowerVR SGX with modifications as it is already Linux compatible. There are about 3-4 versions of the driver, the external installer version does not match the internal library versions, v1/v2 is Pre-Samsung-Eclair/Samsung-Eclair, and I have downloaded v3 and attempting to get it to work with Froyo, I am not sure what version Froyo uses, v4 is avail for OMAP3xxx developers from TI linked to a development board that they sell. Not sure what version is available by request. I downloaded v3 but the problem I'm having with v3 is compiling has a data type conflict that I am attempting to resolve between the portions I pulled from v2 for Samsung compatibility.
Go SirGatez go
Good go, appreciate the effort for the greater good.
SirGatez said:
Kernel hacking is very similar to any other reverse engineering effort, an under standing of asm is needed, as well as the file layout of thr target binaries.
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Either way that isn't something I will be working on just yet unless an opensource driver for this surfaces we will use sammies for now and concentrate on making what we have stable. Fixing the radio and testing the other hardware are priority since the current binary froyo graphics driver does work atm. We will get an opensource version working later, if not then we worry about the the black box problem.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
is there like a link to guide or a book to learn ?
I know it's too early for feature requests... so I'm just going to leave this here... you know, for fun.
http://forum.xda-developers.com/showthread.php?t=709135
No pressure.
SirGatez said:
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Click to expand...
Click to collapse
Nearly all of the innovators that make beautiful things happen with technology are in violation (or at least a gray area) of the law. It really is a shame.
I wonder how much bribe money it took to get the DMCA passed? I'm sorry, I meant "political funding".
Source is online now! Sorry for the delays, Enjoy!
http://www.github.com/sirgatez
I'm working on porting some features from Blazed into Froyo now, git will be updated once I verify everything works. To compile Froyo use the Fascinate_Blazed_defconfig. You will need need to use the stock modules pvrsrvkm.ko, s3c_lcd.ko, s3c_bc.ko for graphics to work. Use of hotspot_event_monitoring.ko, dhd.ko, dpram.ko, dpram_recovery.ko may also allow for operation radio and wifi although I have not tested this, so consider radio operations to still be broken, I am working on the issue.
I did manage to compile versions 2 (From Eclair, did not try Eclairs older EGL libraries with Froyo), 3 (Had android EGL libraries 1 subversion lower than stock Froyo) and 4 (no android egl libraries were included) of the PowerVR drivers and something is amiss and still results in a boot loop, something doesn't seem to be compatible, seems like I get missing library defines no matter how I try.
If someone has intimate knowledge about the PowerVR 3D and EGL on android and could PM me I would like to get some help on getting a fully working compile from source of the drivers that works. Any TI/OMAP3 experience with this driver should be applicable to this situation. I have not posted these drivers on git because there is a clickwrap license on the, you can get them from TI's website, some of them require a login to download, some of them are instant with no login.
I expect full source working drivers for all other devices except graphics within 7 to 14 days once the bugs and incompatible code is resolved, again the dhd wifi drivers are NOT compiling to the same size as the one provided by Samsung, so something seems fishy. If anyone from the internal Samsung Froyo dev team would like to help shed some light on why dhd.ko, pvrsrvkm.ko, s3c_lcd.ko, s3c_bc.ko all compile from the posted source to files 3-8 times the size of those included in Samsung's stock roms it would help progress greatly. Oh yes and I will not reveal any identifying information in exchange for your help unless you request it
Making progress with dpram/gpio control lines. Once I get this right the radio will be working like a charm. Dpram also controls operation of other major hardware such as camera, bluetooth, wifi, in addition to cellular. These devices all work independantly of each other but the dpram module handles the traffic and control i/o.
The galaxy phones while all sporting similar hardware have slightly different ways of controlling them.
Sent from my SCH-I500 using XDA App
Samsung released the source for froyo for the epic today.
http://www.androidcentral.com/samsung-releases-source-epic-4g-eb13-froyo-update
This is most likely of limited usefulness but hopefully a sign we wont have to wait long for the fascinate source.
I've heard/read that ONLY honeycomb makes use of the dual core.
So what's the advantage of having a dual core phone running gingerbread?
Nvm I found some information.
Sry for makimg a new useless topic
Where did you find the information?
Please post the Link!
All of the information I've read shows that Ice Cream should be the build with this integrated.
It's somewhat baffling that it's taken this long considering that for the average phone user, how smooth the phone is plays a huge part in whether they like it or not.
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Tossing the 2D UI acceleration over to the GPU should theoretically increase the speed of the OS as well, since it frees up the CPU to focus on its own tasks.
MustWarnothers said:
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Tossing the 2D UI acceleration over to the GPU should theoretically increase the speed of the OS as well, since it frees up the CPU to focus on its own tasks.
Click to expand...
Click to collapse
Caching is primarily what makes it so smooth on the iPhone, not GPU acceleration; though that helps a fair amount, also. The lack of heavy use of caching everything in the UI for what seems like all Android UIs is what has baffled me about Android UIs. Home screen launcher replacements like LauncherPro use it, and it makes everything nice and silky smooth. I've honestly been thinking that most UI designers for the hardware companies simply do not know what they are doing.
MustWarnothers said:
All of the information I've read shows that Ice Cream should be the build with this integrated.
It's somewhat baffling that it's taken this long considering that for the average phone user, how smooth the phone is plays a huge part in whether they like it or not.
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Tossing the 2D UI acceleration over to the GPU should theoretically increase the speed of the OS as well, since it frees up the CPU to focus on its own tasks.
Click to expand...
Click to collapse
it's not that simple...ios is missing a lot of features. i read that it doesn't support java and just object-oriented C++.
Since android was started, phone developers have pushed it in directions that Google didn't originally plan for. That's why the nexus s only had single core, and afaik, all the dual core phones have software on top of android to manage the dual core processing, which doesn't really do much for them. yes they're faster, but i think not as fast as they could/should be.
i'm assuming the next nexus will be a dual core, and with android that has support for them. if so, it'd blow all dual cores away to this point, because processor management is more efficient the lower in the stack it's handled.
however, what with the nexus s 4g being recently released, i'm not expecting the next nexus to be around anytime soon as G focus on tablets.
Since the SGS2 is so fast for web browsing and flash content, as well as UI, what type of magic do they do if they aren't altering the basic Android system? Does it involve using dual-core? How specific are the Samsung optimizations and are they low-level enough for Google to say this would be great in Ice Cream and thus steal that optimization from them? Is TouchWiz actually faster than stock Android? Or is that impossible since it is built on top of Android? Will the browser speed translate to other installed browsers, or is it specific to the stock browser? I really don't know how far Samsung or any other manufacturer can customize the software beyond just superficial skins and whether or not deep customizations change the system fundamentally and possibly break certain apps.
I didn't really investigate this issue deeply, but I think it works out like this:
Right now, the android sdk (2.3) provides no means to use more than one CPU core.
Still, multicore CPUs will increase performance because background processes can use CPU time on the core not being used by the running app.
This also applies to garbage collection (GC) which happens periodically (I guess you can trigger it manually too) whilst an app is running. With more than one core, the GC won't block the app which makes it feel "smoother".
I remember reading about Google's plans to improve multicore-support in android 2.4. It will take some time for existing apps to use it though (like it's happened with desktop applications).
Then just imagine the performance of the SGS II device with hardware acceleration support.
MustWarnothers said:
All of the information I've read shows that Ice Cream should be the build with this integrated.
It's somewhat baffling that it's taken this long considering that for the average phone user, how smooth the phone is plays a huge part in whether they like it or not.
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Click to expand...
Click to collapse
Since Honeycomb utilizes GPU for UI rendering, I guess it will be available on Ice Cream too.
Android is handicapped by the big range of hardware used by manufacturers. Some GPUs are simply too slow or have other issues which will make GPU acceleration fail. This is not an issue for Apple, because there is no hardware choice on iOS.
silverwolf0 said:
Since the SGS2 is so fast for web browsing and flash content, as well as UI, what type of magic do they do if they aren't altering the basic Android system? Does it involve using dual-core? How specific are the Samsung optimizations and are they low-level enough for Google to say this would be great in Ice Cream and thus steal that optimization from them? Is TouchWiz actually faster than stock Android? Or is that impossible since it is built on top of Android? Will the browser speed translate to other installed browsers, or is it specific to the stock browser? I really don't know how far Samsung or any other manufacturer can customize the software beyond just superficial skins and whether or not deep customizations change the system fundamentally and possibly break certain apps.
Click to expand...
Click to collapse
All parts of android (2.3) are open sourced, so Samsung can customize anything they want. They don't have to release the changed version as open source though (except for the GPLed parts, like the kernel) - so we'll probably never know what they've been doing.
german wikipedia says that gingerbread 2.3.3 features dual-core support ...
Link it please, thats odd.
My German is bad as I only read it for a couple of year but here is the Wikipedia page http://de.wikipedia.org/wiki/Android_(Betriebssystem)
At the bottom you have "Dual-Core-Unterstützung" on 2.3.3 which means it support it.
But as always Wikipedia is never 100% correct so who know
I read that they will re-release a gingerbread version (2.4?) that will take advantage of Dual-core apps. So basically, they add dual-core support and it will also still be gingerbread but version 2.4 of android.
Come to think of it, they did the same thing with Eclair (2.0 and 2.1) already.
Hope this helps
I think they have already done that with "Gingerbread 2.3.3", Instead of calling v 2.4 GINGERBREAD as well, they made the changes in "Gingerbread" and gave it versioning 2.3.3.
Thats what it looks like all on Wikipedia pages. Highlights 2.3.3 as a Major release.
Yes, the wiki says that dual-cores are supported from 2.3.3 and it says too that dual-core-apps are supported on single-core smartphones! --> Thats an indication for real dual-core support!
I'm just waiting for when Android decides to implement GPU UI acceleration.
Even if apps are offered dual core support, if both of those cores are still working on UI animations instead of tossing it to the GPU, it seems like 3 steps forward, 2 steps back.
As I understand it, Gingerbread (2.3) offers limited dual-core support. If your phone has a 2nd core available, then it will move the Garbage Collector onto the 2nd core which means there will be a lot less lag in applications and games when the GC fires off to remove unused resources.
http:/ /developer.android.com/sdk/android-2.3-highlights.html
It's under the 'enhancements to games' section I believe.
Honeycomb (3.0) offers full UI hardware acceleration and makes full use of both cores - so wait for Ice Cream to come to phones and it will be fully supported.
I know that wikipedia isnt always right but if i assume that it is right this time it says that what you just wrote Xailter was integrated in 2.3 and real dual-core support in 2.3.3 :
2.3 features:
Linux-Kernel 2.6.35.7
Unterstützung von WebM
Unterstützung von HTML5 Audio [31]
Unterstützung von Google TV
Unterstützung von Near Field Communication
Parallele Garbage Collection für ruckelfreiere Animationen
verbesserte Integration von sozialen Netzwerken
Unterstützung von Gyroskopen (nicht zu verwechseln mit Bewegungssensoren) und anderen Sensoren (u.a. Barometer, Schwerkraftsensor)[32]
Integrierter SIP-Client für VoIP[33]
Integrierter Downloadmanager[33]
Unterstützung des Ext4-Dateisystems[34]
translated something like "parallel garbage collection for smoother animations"
while 2.3.3 features:
Dual-Core-Unterstützung
Unterstützung von Dual-Core-Apps auf Single-Core-Geräten
verbesserte Unterstützung der NFC-Technik
verbesserte Bluetooth-Unterstützung
kleinere Verbesserungen
which means dual-core support
support for dual-core apps on single-core-devices
improved support of nfc
improved support for bluetooth
minor improvements
if we can believe in what wikipedia says ... 2.3.3 features dual-core support
and i think it is true because it would just make sense to support the hardware that is releasing right now
source: de. wikipedia. org/wiki/Android_%28Betriebssystem%29#Versionsverlauf
sry for the spaces .. but i'm not allowed to post outside links
So, my question is, why do we want the 3.0 Kernel for Nook Tablet again? From what I recall, there were absolutely no changes from kernel 2.6 to 3.0, other than the naming. Only the "alpha-manliness", and the shuffle of old drivers or something along those lines.
Any Ducati stuff is provided in acclaim_update.zip isn't it?
Anyways, if someone could answer that, that'd be great.
Ok, I am not part of the dev team and I got my NT too late to have read the original reasoning behind development of a 3.0 kernel but after a bit of research I think I may have at least part of the picture.
The main reason for the development of a 3.0 kernel is to gain access to the Ducati hardware integrated into the OMAP 4430 that the NT uses. With the 2.6 kernel we can use only the dual core Cortex A9 part of the processor but if we can develop a Ducati driver it will allow use to use the Cortex M3 dual core (four cores total) for hardware video acceleration.
This is proving to be a challenge because TI will not release the source for the Ducati related kernel elements; they will only give us a binary version which is crippled for our device because it uses the wrong watchdog timer (GPtimer 11 vs GPtimer 10 which we need).
This all requires Kernel 3.0 because the binary for Ducati is built using this kernel. Aside from that, ICS is built for the 3.0 kernel branch and we should be keeping up (if not one step ahead) if possible.
That is what I've gotten so far but if any devs want to step in and correct, clarify, or add anything else, please feel free. Thanks guys for all your hard work!
Android ICS v4 was build upon kernel v3 and also the framework (api's)
It provides some elemental changes over Gingerbread like HWA of the gui so in plain words it takes the burden off the cpu and uses the gpu like Nvidia VDPAU (Video Decode and Presentation API for Unix)
http://en.wikipedia.org/wiki/VDPAU
And Windows DXVA V2
http://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx
http://en.wikipedia.org/wiki/DirectX_Video_Acceleration
Hardware-accelerated 2D drawing
All Android-powered devices running Android 4.0 are required to support hardware-accelerated 2D drawing. Developers can take advantage of this to add great UI effects while maintaining optimal performance on high-resolution screens, even on phones. For example, developers can rely on accelerated scaling, rotation, and other 2D operations, as well as accelerated UI components such as TextureView and compositing modes such as filtering, blending, and opacity.
As everyone thinks that no changes where made on kernel transportation to v3 from 2.6, later on many arm optimizations where sync to git from different sources that help to make the v3 kernel more feature full over v2.6.
For starters,
Linaro is pushing more and more advancements to the git for v3.
Ubuntu decided to support arm hardware in Server and Userbase because of those changes.
They are putting out a Plasma tablet with Arm Cortex A9 cpu 512mb Ram with kde Plasma interface as well as pushing theirs code onto the git also.
So in the v3 kernel we see things done right.
Another proof that kernel v3 done miracles to arm is the XBMC project.
Now we have an xbmc version for arm also.
This is no coincidence at all.
An important factor to all this is that Android does not run on a stock Linux kernel. The source code for each Android release also includes a large number of Android-specific changes to the Linux kernel, including custom features and even entire subsystems. Each release of the Android OS is developed hand-in-hand with a specific kernel version and its changes, and ICS was developed around a modified 3.0.1 kernel. Using an older kernel version could potentially require work in patching newer changes into an old kernel or hacking in workarounds instead of just focusing on drivers. This is why most ROMs aren't just jumping straight to the newest Linux 3.3 either. I don't know any specifics about what changes are important though
Many drivers available from all these outside sources have been built around this same Android 3.0.1 kernel version too, so the chances of issues are much smaller if you stick to the same version
Also, to clarify about the Linux numbering: you're correct that the 3.0 version itself didn't include any big changes over 2.6.39 so as to keep the focus on simply replacing "2.6" with "3" while sticking with the same development process. However since they started the 2.6 branch many years ago they have constantly added new features, new frameworks, and all kinds of significant changes in the 2.6.X/3.X sub-versions as the code became ready. There wasn't simply a 2.6 kernel there were many 2.6 kernels, and it changed a lot over time from the initial 2.6.0 version just as it continues to evolve with each 3.X version
demetris_I said:
Android ICS v4 was build upon kernel v3 and also the framework (api's)
It provides some elemental changes over Gingerbread like HWA of the gui so in plain words it takes the burden off the cpu and uses the gpu like Nvidia VDPAU (Video Decode and Presentation API for Unix)
http://en.wikipedia.org/wiki/VDPAU
And Windows DXVA V2
http://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx
http://en.wikipedia.org/wiki/DirectX_Video_Acceleration
Hardware-accelerated 2D drawing
All Android-powered devices running Android 4.0 are required to support hardware-accelerated 2D drawing. Developers can take advantage of this to add great UI effects while maintaining optimal performance on high-resolution screens, even on phones. For example, developers can rely on accelerated scaling, rotation, and other 2D operations, as well as accelerated UI components such as TextureView and compositing modes such as filtering, blending, and opacity.
As everyone thinks that no changes where made on kernel transportation to v3 from 2.6, later on many arm optimizations where sync to git from different sources that help to make the v3 kernel more feature full over v2.6.
For starters,
Linaro is pushing more and more advancements to the git for v3.
Ubuntu decided to support arm hardware in Server and Userbase because of those changes.
They are putting out a Plasma tablet with Arm Cortex A9 cpu 512mb Ram with kde Plasma interface as well as pushing theirs code onto the git also.
So in the v3 kernel we see things done right.
Another proof that kernel v3 done miracles to arm is the XBMC project.
Now we have an xbmc version for arm also.
This is no coincidence at all.
Click to expand...
Click to collapse
Sounds good. But the nook Tablet is running Gingerbread, and it gets Ducati features. Doesn't that mean a 2.6 Kernel suffices the Ducati Susbsystem? Does moving to Kernel 3.0.x make it easier to crack Ducati? Hmm.
soshite said:
Sounds good. But the nook Tablet is running Gingerbread, and it gets Ducati features. Doesn't that mean a 2.6 Kernel suffices the Ducati Susbsystem? Does moving to Kernel 3.0.x make it easier to crack Ducati? Hmm.
Click to expand...
Click to collapse
Ducati wasn't the point because as you pointed out it already works with the original kernel, and it not working yet with this 3.0 kernel is an unfortunate side effect of the real goal.
Moving to a newer Android kernel apparently makes it much easier to get proper graphics acceleration working for apps and general user interface components. This hardware acceleration of the UI is why ICS can feel so much smoother than Honeycomb or Gingerbread. Without the proper kernel I think they have to resort to dirtier hacks into the rest of ICS to make it run properly. I'm admittedly a little fuzzy on the details though
Lets just say that moving to Kernel v3 will make full use of our hardware, something GB doesn't do right now.
boomn said:
This hardware acceleration of the UI is why ICS can feel so much smoother than Honeycomb or Gingerbread.
Click to expand...
Click to collapse
AFAIK Honeycomb has already the UI acceleration. But I haven't had any device with HC, is ICS really much smoother then HC? I didn't think so.
Aleq said:
AFAIK Honeycomb has already the UI acceleration. But I haven't had any device with HC, is ICS really much smoother then HC? I didn't think so.
Click to expand...
Click to collapse
The thing is, Honeycomb is really heavy on the device. Honeycomb would be slower than ICS, as it would be ported and contains more contents than ICS. ICS was made to be the faster successor to HC.
Aleq said:
AFAIK Honeycomb has already the UI acceleration. But I haven't had any device with HC, is ICS really much smoother then HC? I didn't think so.
Click to expand...
Click to collapse
I was mistaken and you are correct. However, something under the hood was definitely changed or tweaked in regards to acceleration and how it is used because ICS does feel much smoother and more responsive throughout than Honeycomb did
I searched a bit and found this helpful article. Here are the most relevant quotes:
Android 3.0 Honeycomb gave developers the ability to turn on hardware acceleration, but it wasn’t toggled by default.
Click to expand...
Click to collapse
According to Romain Guy and Chet Haase (Android engineers):
“With this new pipeline, all drawing operations performed by the UI toolkit are carried out using the GPU. You’ll be happy to hear that Android 4.0, Ice Cream Sandwich, brings an improved version of the hardware-accelerated 2D rendering pipeline to phones, starting with Galaxy Nexus. In Android 4.0 (API level 14), hardware acceleration, for the first time, is on by default for all applications.”
Click to expand...
Click to collapse
I happened to come across a very interesting article regarding speed improvements for ICS on devices with (TI Pandaboard) OMAP 4430 processors. I believe the NT falls into this category. Supposedly the improvements will practically double the performance of the current build of ICS (4.0.4). The difference is really quite significant. It looks like it is being added to CM9 so we should hopefully see it on the NT!
From what I can gather...
They use a newer compiler and a special toolset built in. The use the linaro android system that has all string operations replaced for a faster build. They changed the way that the build system works. It sounds like the optimization is CPU based, so it should work even if Ducati isn't working. There are a lot of other optimization included, but I didn't really understand what the guy is talking about. You can find a video in the link below.
http://www.androidpolice.com/2012/0...e-and-now-parts-of-it-are-being-added-to-cm9/
https://wiki.linaro.org/Platform/Android
I guess the question is what we need to do to be sure that this gets implemented?
It sounds like some of it is being worked into the CM source. So I'd say we may see some after that unless some one feels like working it into a build themselves.
See the last few posts in this thread.
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