Related
Hi,
I've built some kernels that can be applied to the MiRaGe CM7 build. Below are the changes of each kernel build.
The 16 BPP frame buffer uses 16 bits per pixel instead of 32 bits per pixel. This reduces the amount of memory used for the screen frame buffer. It also means that when Android updates the screen, it has to move half the amount of data. This has the potential to increase performance. The potential downside is color banding. Using fewer bits for each pixel reduces the number of colors that can be displayed. I haven't noticed a difference in how the screen looks.
Compiling the kernel for speed versus size tells the compiler to use more memory if it will make the code run faster. This tradeoff uses less than 256k more memory (the Nook has 524288k) for the kernel.
By default, the backlight is turned on and off at a base frequency of 128 times per second. If you are at 50% brightness it will be turned on and off 128 times in one second. The 256Hz kernel doubles the rate at which the backlight is turned on and off as some people can see the backlight flashing at 128Hz. Since the switching is done in an interrupt to the processor, there is more overhead at the higher frequency so it's not a free change. Only use if the default screen seems to flicker.
encore_kernel_07302012.zip:
- 16 BPP frame buffer
- Compiled with -O2 instead of -Os (speed instead of size)
encore_kernel_256Hz_07302012.zip:
- same as above and 256Hz backlight instead of 128Hz
encore_kernel_07122012.zip:
- 16 BPP frame buffer
- Compiled with -O2 instead of -Os (speed instead of size)
encore_kernel_256Hz_07122012.zip:
- same as above and 256Hz backlight instead of 128Hz
Attached are CWM zips you can apply to probably any recent MiRaGe build.
Frank
For the uninitiated, what does this do? (layman's terms)
And how do you apply it?
Sent from my NookColor using xda premium
The kernel is the engine that drives your rom. It is the core of the system, responsible for drivers, modules and managing the communication between hardware and software, among other responsibilities. You already have one, you just don't have this one made just for you.
Looks like frankusb has put it into a flashable zip, so just flash it over your Mirage rom.
Alternatively, for emmc installs, you could just take out the uImage file from the zip, rename it to kernel and put it in any rom you want.
If you have an sd install, just replace the uImage in your boot partition with his.
------------------------------------------------------------------------------------------
off-topic​
I've been following the 3.x kernel thread over at the Nook Tablet forum, as well as building and configuring my own from keyodi's source.
I'm not very good at it yet, though, and that's kind. My kernel builds tend to boot and I was able to enable the NAT stuff on my own (before the new .config was pushed) but that's as far as I have gone with it.
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Here is fattire's post at the acclaim forum, urging people to try and build their own kernel. (with links and guides)
slack04 said:
For the uninitiated, what does this do? (layman's terms)
Click to expand...
Click to collapse
- The LEDs that bring light to the screen flash twice faster, so it should be less noticeable, especially at lower brightness levels and a darker room. You might have noticed that cameras (see Youtube) also see the Nook Color flickering.
- The screen is now updated at 60Hz instead of 44 frames per second. Most laptop/desktop LCDs are run at 60Hz. Can make it possible to have smoother graphics. Does give the programs a harder time to keep up if they try to do this, since they need to push 40% more image data per second.
- With half the bits (32 vs 16) to push to the display, graphics get slightly faster. I believe this is optional in Cyanogenmod settings.
---------- Post added at 07:47 AM ---------- Previous post was at 07:31 AM ----------
Over from the Mirage main topic:
Henk Poley said:
I'm talking about the backlight. On a static image I can distinctly see the corners of the display in a stroboscopic effect when I move the Nook Color by hand. As if the image quickly disappears and then time travels to another spot . It's quite annoying and possibly tiring.
(Probably spaced ~78mm)
Click to expand...
Click to collapse
With this kernel build I now see the flickering at a reduced distance when I move the nook color by hand. It does look like half the distance, like it should
Still noticeable though.
There is a bug now, that ever so often 100% brightness in RootDim puts the backlight brightness all the way down. I wonder if the unmodified driver has a similar race condition in writing the value to the PWM divider register.
mateorod said:
The kernel is the engine that drives your rom. It is the core of the system, responsible for drivers, modules and managing the communication between hardware and software, among other responsibilities. You already have one, you just don't have this one made just for you.
Looks like frankusb has put it into a flashable zip, so just flash it over your Mirage rom.
Alternatively, for emmc installs, you could just take out the uImage file from the zip, rename it to kernel and put it in any rom you want.
If you have an sd install, just replace the uImage in your boot partition with his.
------------------------------------------------------------------------------------------
off-topic​
I've been following the 3.x kernel thread over at the Nook Tablet forum, as well as building and configuring my own from keyodi's source.
I'm not very good at it yet, though, and that's kind. My kernel builds tend to boot and I was able to enable the NAT stuff on my own (before the new .config was pushed) but that's as far as I have gone with it.
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Here is fattire's post at the acclaim forum, urging people to try and build their own kernel. (with links and guides)
Click to expand...
Click to collapse
Are you building for Nook Color or Tablet?
Sent from my NookColor using xda premium
This kernel works for Nook Color.
Henk Poley said:
There is a bug now, that ever so often 100% brightness in RootDim puts the backlight brightness all the way down. I wonder if the unmodified driver has a similar race condition in writing the value to the PWM divider register.
Click to expand...
Click to collapse
You are very observant. This driver has an interesting detail.
There are cases where there is a 1/8 second delay before the brightness level is set.
I've noticed even before my change of frequency that sometimes when it dimmed the screen due to inactivity, it would flash full brightness.
Side note: This driver was originally written by Nokia, probably for either the 770 or N800. The 770 was my first internet tablet.
Frank
mateorod said:
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Click to expand...
Click to collapse
I'm certainly OK with this thread discussing kernel development. I've been enjoying building the Nook kernel lately.
I doubt there's much to discuss about my particular kernel, at least so far, the changes are very minimal and mostly well known. The LED PWM frequency is the only new change.
Frank
Ur kernel makes the reading easier on eyes. Especially white background isn't too bright on webpages.
I think CPU adds 5% performance gains too.
However, can I apply this kernel on top of future upcoming mirage releases?
manic77 said:
However, can I apply this kernel on top of future upcoming mirage releases?
Click to expand...
Click to collapse
It depends on what mrg666 ends up doing but since I enjoy his rom, I'll probably keep this kernel current.
Frank
So...have you done any experimenting with different toolchains? I was originally using the one that I built making cm9, but then switched to the prebuilt linaro tool chain. I just recently installed the new 12.04 with 4.7 in it. I have seen the claim, (mrg666 makes it, for instance) that using certain toolchains gives performance advantages. I can't tell personally, but it's not like I put 'em through benchmarking or stress tests.
Anyway, the point is that I am debating building and configuring the 12.04 toolchain myself. What do you know, do you think it's worth it? I may just do it for the learning experience, regardless.
mateorod said:
So...have you done any experimenting with different toolchains? I was originally using the one that I built making cm9, but then switched to the prebuilt linaro tool chain. I just recently installed the new 12.04 with 4.7 in it. I have seen the claim, (mrg666 makes it, for instance) that using certain toolchains gives performance advantages. I can't tell personally, but it's not like I put 'em through benchmarking or stress tests.
Anyway, the point is that I am debating building and configuring the 12.04 toolchain myself. What do you know, do you think it's worth it? I may just do it for the learning experience, regardless.
Click to expand...
Click to collapse
I started with gcc 4.4 and then moved to Linaro 4.5. The kernel size got smaller but that's about all I can say. I have not come up with a good way to benchmark just the kernel (since that's all I'm recompiling). Android benchmarks don't seem repeatable to me. Way too much variance between runs. Also Android benchmarks aren't really testing just the kernel.
Then a source code change was required to move to Linaro 4.6. That's what I'm currently compiling with.
I did make one build with Linaro 4.7 from the 12.04 release but the kernel did not boot for me.
Frank
I didn't think the screen could get any better. I would use this but every time the screen times out it doesn't want to turn back on or when it does it gets really dim and touch is non responsive.
Sent from my NookColor using Tapatalk 2
I'm having trouble downloading the 7-1 kernel from my desktop (404 not found). Mirror or link fix, please?
foxalot said:
I'm having trouble downloading the 7-1 kernel from my desktop (404 not found). Mirror or link fix, please?
Click to expand...
Click to collapse
Weird - uploaded to a file host as well.
Frank
Great update and great work on the kernal once again. keep it up . can't wait to see everyone's work on 3.xx
Just installed Mirage 070512 and now confused as to which kernel to go with. Do I stick with the kernel from Mirage or do I flash one of the kernels in the OP? If OP, what are differences of the 3 kernels? I like the idea of 256, but not sure if 7/1 kernel also has 256? Appreciate any advice on this.
Sent from my NookColor using xda premium
360Razir said:
Just installed Mirage 070512 and now confused as to which kernel to go with. Do I stick with the kernel from Mirage or do I flash one of the kernels in the OP?
Click to expand...
Click to collapse
Your choice, the stock mrg666 kernel will work. Probably any of the 3 I built will work as well with the 070512 Mirage build.
360Razir said:
If OP, what are differences of the 3 kernels? I like the idea of 256, but not sure if 7/1 kernel also has 256? Appreciate any advice on this.
Click to expand...
Click to collapse
The 3 kernels are snapshots in time of 3 mrg666 stock kernels with my changes listed. The 7/1 kernel does not have a 256Hz refresh rate. I'd be glad to make one for you if you or others are interested. The increased refresh rate didn't do anything for me, but a 16 bit frame buffer and a different optimization did.
Frank
frankusb said:
Your choice, the stock mrg666 kernel will work. Probably any of the 3 I built will work as well with the 070512 Mirage build.
The 3 kernels are snapshots in time of 3 mrg666 stock kernels with my changes listed. The 7/1 kernel does not have a 256Hz refresh rate. I'd be glad to make one for you if you or others are interested. The increased refresh rate didn't do anything for me, but a 16 bit frame buffer and a different optimization did.
Frank
Click to expand...
Click to collapse
Thanks for the feedback, Frank. I will start with your 7/1 kernel and go from there. If you can make 256 with 7/1 then great...I will gladly put it through its paces. Thanks for all your efforts thus far.
Sent from my NookColor using xda premium
I haven't seen this posted anywhere. But once CM brings these changes to the TFP and other devices in its Device tree I think I will have no choice but to unlock and flash. What do yall think?
http://www.androidpolice.com/2012/0...e-and-now-parts-of-it-are-being-added-to-cm9/
https://wiki.linaro.org/Platform/Android
shreddintyres said:
I haven't seen this posted anywhere. But once CM brings these changes to the TFP and other devices in its Device tree I think I will have no choice but to unlock and flash. What do yall think?
http://www.androidpolice.com/2012/0...e-and-now-parts-of-it-are-being-added-to-cm9/
https://wiki.linaro.org/Platform/Android
Click to expand...
Click to collapse
Looks awesome. If they incorporate it correctly, it will definitely be worth unlocking (if not done so already).
Sent from my Transformer Prime TF201 using XDA
Jonphinguyen7 said:
Looks awesome. If they incorporate it correctly, it will definitely be worth unlocking (if not done so already).
Sent from my Transformer Prime TF201 using XDA
Click to expand...
Click to collapse
The changes are being added to CyanogenMod's Gerrit Code Review as we speak. Might take a while for them to be approved and merged though.
http://review.cyanogenmod.com
So far CM9 on the prime hasn't really bowled me over, that said, I would become incredibly interested if Gummy or Team EOS or AOKP bring linaro in (particularly Team EOS who's recent builds have been all but bulletproof). I think the kicker will be if CM can solve the niggles or if Team EOS can integrate linaro to their builds.
Nice find shreddintyres, will definatly be listening out for this
It's also being merged into AOSP, so it could wind up in an Asus build as well one day.
Wow, this is pretty awesome! Can't wait to see this implemented! Major performance increase, amazing!
Unfortunally this will result mostly in CPU improvements, but our CPU is constantly bottlenecked by the slow IO of the prime
However will flash this instantly when available
bedoig said:
It's also being merged into AOSP, so it could wind up in an Asus build as well one day.
Click to expand...
Click to collapse
I was unaware that it was being merged into AOSP, that is amazing news, i was thinking why doesnt google hire some of these guys . From what I've discussed and read it seems that this will only affect devices with newer CPU's and as such should contribute a fairly large performance increase to the Prime.
latest news about linaro and its benchmarking tricks do not really sound so promising.
jupppo said:
latest news about linaro and its benchmarking tricks do not really sound so promising.
Click to expand...
Click to collapse
to be honest im not too concerned with bench marks, i was taling to some ppl who are using a linaro/aokp build on their GNexus's and they were saying the over all user experience (fluidty etc) is significantly improved.
Benchmarks arent the best test for the quality of a build, user experience is the key difference. I cant wait to get back to the us in august to get my nexus so i can try out all this latest and greatest stuff as it comes out rather than having to wait all the time.
I have been using it for a day now on my GNex and there is a large improvement in fluid-ness. I will be unlocking for this if released for the TFP.
Cothek said:
I have been using it for a day now on my GNex and there is a large improvement in fluid-ness. I will be unlocking for this if released for the TFP.
Click to expand...
Click to collapse
Team Gummy just released a Linaro build for the Prime. I haven't tried it yet but will be looking forward to doing so tonight. You can find it on Goo Manager if interested...
paddycr said:
Team Gummy just released a Linaro build for the Prime. I haven't tried it yet but will be looking forward to doing so tonight. You can find it on Goo Manager if interested...
Click to expand...
Click to collapse
do leave a review feedback of it too! thanks
the new update sucks too bad, thinking of unlocking my prime and switch to custom roms for good
does anyone know how this will effect battery life? will it make it better or worse?
Tried the gummy linaro release, cant say I noticed much difference to be honest... Back to androwook now but might give it a try again later on.
Also the fact that thegummy builds don't put the prime in sleep mode when closing the lid annoys me too much atm
ps. Only did an antutu bencmhark which was about 10% below stock-based results... But this is the case for me with all the AOSP/AOKP roms.
painkillaz said:
does anyone know how this will effect battery life? will it make it better or worse?
Click to expand...
Click to collapse
Theoretically it would improve battery life due to taking less CPU cycles to complete a specific task. However realistically I doubt the difference would be drastic enough that it would even improve it to the point of simply lowering your screen brightness 10%.
dagrim1 said:
Tried the gummy linaro release, cant say I noticed much difference to be honest... Back to androwook now but might give it a try again later on.
Also the fact that thegummy builds don't put the prime in sleep mode when closing the lid annoys me too much atm
ps. Only did an antutu bencmhark which was about 10% below stock-based results... But this is the case for me with all the AOSP/AOKP roms.
Click to expand...
Click to collapse
+1
I am running it at the moment and it seems pretty similar to the regular builds. Maybe I am missing something?
Sent from my Transformer Prime using xda premium
Gummy Livaro
I'm running the Gummy Linaro Release with TWRP recovery currently and it seems to be a huge improvement for me from AOKP. Everything just seems more fluid and snappy. Also, I kept getting random browser lockups and crashes before, under AKOP, and now all is gone. I should also mention that I performed all the exact same steps flashing each rom. I'm not sure if its the Linaro addons or what but I'm extremely happy so far.
paddycr said:
+1
I am running it at the moment and it seems pretty similar to the regular builds. Maybe I am missing something?
Sent from my Transformer Prime using xda premium
Click to expand...
Click to collapse
You're not. The phones used in those videos had heavily optimized builds of Linaro. Just adding it to a build won't yield the same performance.
Hello,
I have tried to search kernels which are compiled with Linaro toolchain but I cannot orient in it. Can please anyone post here kernels which are compiled by Linaro toolchains here? (Jelly bean only).
festr said:
Hello,
I have tried to search kernels which are compiled with Linaro toolchain but I cannot orient in it. Can please anyone post here kernels which are compiled by Linaro toolchains here? (Jelly bean only).
Click to expand...
Click to collapse
Probably none. It's better/easier to use the toolchain from Google, that way you can be sure there won't be any problems compiling and you won't get any bugs from using an experimental toolchain.
Linaro's changes are being merged/considered for merging upstream. So as Google updates their toolchain we'll get the optimizations made by Linaro (and others).
If you want to live on the bleeding edge you're welcome to build with Linaro's toolchain. I'd suggest building Android as well as the kernel if you do that though.
I have used kernel on SGS 1 compiled by Linaro toolchain and the performance gain was outstanding. So thats the main reason I'm asking if someone already made experimental kernel compiled by Linaro for SGS 3. The SGS1 was pretty stable and I still have it on my old SGS 1.
Actually the performance gain from the Linaro TC is minimal, nothing outstanding. So don't even sweat it dude. Go on with the stock toolchains.
At least it was noticable difference on SGS 1 with linaro / without linaro. But it is only my expirience without any science background.
You have tried Linaro compiled kernel on SGS 3?
b-eock said:
Actually the performance gain from the Linaro TC is minimal, nothing outstanding. So don't even sweat it dude. Go on with the stock toolchains.
Click to expand...
Click to collapse
Yes exactly, the benefits were minimal at best.
Outstanding is waaaayyyyy off the mark.
(I've used linaro kernels on gnex, the exact same source (Franco's kernel) one built using linaro tool chain, the other using the Google tool chain.)The difference was negligible.
Sent from my GT-I9300 using xda premium
Thank you for sharing expirience. That is totally in oposite to my expirience on SGS1
Perseus at least is compiled with linaro toolchain.
b-eock said:
Actually the performance gain from the Linaro TC is minimal, nothing outstanding. So don't even sweat it dude. Go on with the stock toolchains.
Click to expand...
Click to collapse
The performance in SIII is minimal, ok. BUT USE LESS CPU THAN THE USUAL KERNEL.
and this is GOOD FOR NOT SPEND TO MUCH BATTERY...
Striatum_bdr said:
Perseus at least is compiled with linaro toolchain.
Click to expand...
Click to collapse
I actually reverted to using the standard toolchain, there were some bugs with the Linaro causing games to crash. Anyway lets get this myth busted once and for all: kernel compilation optimizations are almost useless. The kernel is there for system management and control, there is no performance critical parts in it or large computations being done. These are all parts of the operating system, so your ROM needs to be compiled with these optimizations to see any effect, especially graphics drivers and things like that.
The kernel actually do a lot of stuff. Graphic drivers is also as kernel module. I have heard from other developers that compiling android with LInaro do not bring any noticable gain. Its intended to speedup the kernel.
festr said:
The kernel actually do a lot of stuff. Graphic drivers is also as kernel module. I have heard from other developers that compiling android with LInaro do not bring any noticable gain. Its intended to speedup the kernel.
Click to expand...
Click to collapse
Graphics drivers are not part of the kernel, the GPU platform drivers are. There are no graphical computations or complex things done on the kernel, the kernel just does low level management stuff.
Actually to argue on that I have to learn more. All in all, this speeks for itself:
http://www.youtube.com/watch?v=mrQRYmYip6Q
But anyway - it seems that some work of Linaro has been adopted by Goodle for Jelly bean.
festr said:
Actually to argue on that I have to learn more. All in all, this speeks for itself:
http://www.youtube.com/watch?v=mrQRYmYip6Q
Click to expand...
Click to collapse
That was the entire system built with the linaro toolchaim (ROM + Kernel) and its doing synthetic benchmarks, take from that what you will.
Also you are arguing with the wrong guy here, if anyone knows about this stuff its Andreilux.
Sent from my GT-I9300 using xda premium
According to +Jean-Baptiste Queru, We've already merged some of Linaro's changes into AOSP (and therefore into Google's internal master branch), a few weeks ago. Some more are pending review and look promising.
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
Can any of the existing Tbolt kernels be compiled using a newer toolchain for better performance?
Looks like Linaro 4.6 works on 2.3.7.
http://www.linaro.org/downloads/1111/
I love leankernel, zoom, etc., but maybe we could squeeze a bit more out of them?