i switched to this rom, seems much smoother than others, but overall i have 2 questions - 1. Why is the google search bar on the homescreen blank (is it a bug ? ) and 2. How can i add custom lockscreen widgets and expand them
i switched to this rom, seems much smoother than others, but overall i have 2 questions - 1. Why is the google search bar on the homescreen blank (is it a bug ? ) and 2. How can i add custom lockscreen widgets and expand them
Explain the problem you have please. I either don't understand or I don't have the lag.anyone know how to fix the notification pull down lag? its present in all roms. just wondering if someone found a way around.
Explain the problem you have please. I either don't understand or I don't have the lag.
Explain the problem you have please. I either don't understand or I don't have the lag.
Hi everybody. Just installed this rom on f2fs filesystem, seems fine but I can't connect my flash drive via OTG. Is this a common problem, can it be solved?
I'm using rom's own kernel and twrp f2fs recovery (the one from the dirty v thread)
i switched to this rom, seems much smoother than others, but overall i have 2 questions - 1. Why is the google search bar on the homescreen blank (is it a bug ? ) and 2. How can i add custom lockscreen widgets and expand them
More frequent builds are better in my opinion, but only if they don't slow you down much overall. And of course if you don't want to waste time uploading more frequently it's totally up to you.I have a question for you guys:
Would you rather see more frequent FML builds but with less changes in each build, or continue with what I've been doing lately and release builds less frequently with a huge amount of changes in each build?
Part of what has caused me to slow down with releasing builds is that I'm just getting extremely ambitious with things. For example, here's a preview of the changes for the next build, in order of when they were um, started.
- Complete overhaul of the kernel, rebasing it on top of Ziyan's heavily updated kernel. He managed to pull in upwards of 1,000 commits from the omapzoom kernel (sort of the 'official' OMAP (the CPU the Galaxy Nexus uses) kernel, which while the Galaxy Nexus was based on this kernel, it got neglected and wasn't kept up to date). I've also used this as an opportunity to clean up many things with the previous kernel and do them 'properly' this time around.
- Laid down some initial code for "OMAP Audio Control". This isn't going to be much for a while, as I'm not really familiar with Digital Signal Processing (DSP), at least on such a low level! But like just about everything I do with FML, it's an opportunity for me to learn new things.
- Switched the compiler for the ROM to Linaro's GCC 4.9, and the compiler for the kernel to 'standard' GCC 4.9. This should result in an all-around improvement of speed, however it also could introduce some bugs. The kernel seems fine, but the ROM-side of things was pretty disastrous:
--- First, it wouldn't boot at all. After a while I was able to figure out what the problem was and implement a workaround for it.
--- Second, it resulted in a huge problem with my /data partition, after tracking down and fixing what was causing this I had to reformat /data.
--- Third, fourth, fifth, sixth, and seventh, there were just random inexplicable crashes, that I somehow managed to fix. Seriously!
--- Eighth: I haven't gotten to eighth yet actually but I'm sure I will eventually!
- Small change to the build.prop that will improve (reduce) memory usage.
- Updated libpng from 1.2.46 (released in 2011, however 1.2 as a whole was originally released in 2001) to 1.6.10 (released just a few months ago, with 1.6 as a whole being released in 2013), and also enabled NEON for it. This may or may not affect speed or stability... I'm not going to say that it will as there's not really a way for me to measure it and if I try to 'guess' based on how it 'feels' my mind will probably play tricks on me and just make it a placebo effect, but I certainly like higher version numbers!
- Switched from libjpeg to libjpeg-turbo. Like the libpng change, libjpeg-turbo has NEON support, and as a result is claimed to be 2 to 4 times faster than the regular libjpeg.
- Enabled LTO (Link-Time Optimization) for all the things it previously had to be manually disabled for: parts of bionic and parts of ART. This is partly due to fixes and improvements to LTO by GCC 4.9.
I hope the links were helpful! I know this stuff can be hard to understand sometimes.
Yeah I still haven't quite worked out all the USB OTG issues, hopefully they'll be fixed for the next build.
I see somebody else answered #2, as for the search bar being blank I'm not really sure what's up with that. I'll ask the OmniROM guys, I'm guessing it could maybe be a legal issue with using Google's images.
I have a question for you guys:
Would you rather see more frequent FML builds but with less changes in each build, or continue with what I've been doing lately and release builds less frequently with a huge amount of changes in each build?
Part of what has caused me to slow down with releasing builds is that I'm just getting extremely ambitious with things. For example, here's a preview of the changes for the next build, in order of when they were um, started.
- Complete overhaul of the kernel, rebasing it on top of Ziyan's heavily updated kernel. He managed to pull in upwards of 1,000 commits from the omapzoom kernel (sort of the 'official' OMAP (the CPU the Galaxy Nexus uses) kernel, which while the Galaxy Nexus was based on this kernel, it got neglected and wasn't kept up to date). I've also used this as an opportunity to clean up many things with the previous kernel and do them 'properly' this time around.
- Laid down some initial code for "OMAP Audio Control". This isn't going to be much for a while, as I'm not really familiar with Digital Signal Processing (DSP), at least on such a low level! But like just about everything I do with FML, it's an opportunity for me to learn new things.
- Switched the compiler for the ROM to Linaro's GCC 4.9, and the compiler for the kernel to 'standard' GCC 4.9. This should result in an all-around improvement of speed, however it also could introduce some bugs. The kernel seems fine, but the ROM-side of things was pretty disastrous:
--- First, it wouldn't boot at all. After a while I was able to figure out what the problem was and implement a workaround for it.
--- Second, it resulted in a huge problem with my /data partition, after tracking down and fixing what was causing this I had to reformat /data.
--- Third, fourth, fifth, sixth, and seventh, there were just random inexplicable crashes, that I somehow managed to fix. Seriously!
--- Eighth: I haven't gotten to eighth yet actually but I'm sure I will eventually!
- Small change to the build.prop that will improve (reduce) memory usage.
- Updated libpng from 1.2.46 (released in 2011, however 1.2 as a whole was originally released in 2001) to 1.6.10 (released just a few months ago, with 1.6 as a whole being released in 2013), and also enabled NEON for it. This may or may not affect speed or stability... I'm not going to say that it will as there's not really a way for me to measure it and if I try to 'guess' based on how it 'feels' my mind will probably play tricks on me and just make it a placebo effect, but I certainly like higher version numbers!
- Switched from libjpeg to libjpeg-turbo. Like the libpng change, libjpeg-turbo has NEON support, and as a result is claimed to be 2 to 4 times faster than the regular libjpeg.
- Enabled LTO (Link-Time Optimization) for all the things it previously had to be manually disabled for: parts of bionic and parts of ART. This is partly due to fixes and improvements to LTO by GCC 4.9.
I hope the links were helpful! I know this stuff can be hard to understand sometimes.
Yeah I still haven't quite worked out all the USB OTG issues, hopefully they'll be fixed for the next build.
I see somebody else answered #2, as for the search bar being blank I'm not really sure what's up with that. I'll ask the OmniROM guys, I'm guessing it could maybe be a legal issue with using Google's images.
I have a question for you guys:
Would you rather see more frequent FML builds but with less changes in each build, or continue with what I've been doing lately and release builds less frequently with a huge amount of changes in each build?
Part of what has caused me to slow down with releasing builds is that I'm just getting extremely ambitious with things. For example, here's a preview of the changes for the next build, in order of when they were um, started.
- Complete overhaul of the kernel, rebasing it on top of Ziyan's heavily updated kernel. He managed to pull in upwards of 1,000 commits from the omapzoom kernel (sort of the 'official' OMAP (the CPU the Galaxy Nexus uses) kernel, which while the Galaxy Nexus was based on this kernel, it got neglected and wasn't kept up to date). I've also used this as an opportunity to clean up many things with the previous kernel and do them 'properly' this time around.
- Laid down some initial code for "OMAP Audio Control". This isn't going to be much for a while, as I'm not really familiar with Digital Signal Processing (DSP), at least on such a low level! But like just about everything I do with FML, it's an opportunity for me to learn new things.
- Switched the compiler for the ROM to Linaro's GCC 4.9, and the compiler for the kernel to 'standard' GCC 4.9. This should result in an all-around improvement of speed, however it also could introduce some bugs. The kernel seems fine, but the ROM-side of things was pretty disastrous:
--- First, it wouldn't boot at all. After a while I was able to figure out what the problem was and implement a workaround for it.
--- Second, it resulted in a huge problem with my /data partition, after tracking down and fixing what was causing this I had to reformat /data.
--- Third, fourth, fifth, sixth, and seventh, there were just random inexplicable crashes, that I somehow managed to fix. Seriously!
--- Eighth: I haven't gotten to eighth yet actually but I'm sure I will eventually!
- Small change to the build.prop that will improve (reduce) memory usage.
- Updated libpng from 1.2.46 (released in 2011, however 1.2 as a whole was originally released in 2001) to 1.6.10 (released just a few months ago, with 1.6 as a whole being released in 2013), and also enabled NEON for it. This may or may not affect speed or stability... I'm not going to say that it will as there's not really a way for me to measure it and if I try to 'guess' based on how it 'feels' my mind will probably play tricks on me and just make it a placebo effect, but I certainly like higher version numbers!
- Switched from libjpeg to libjpeg-turbo. Like the libpng change, libjpeg-turbo has NEON support, and as a result is claimed to be 2 to 4 times faster than the regular libjpeg.
- Enabled LTO (Link-Time Optimization) for all the things it previously had to be manually disabled for: parts of bionic and parts of ART. This is partly due to fixes and improvements to LTO by GCC 4.9.
I hope the links were helpful! I know this stuff can be hard to understand sometimes.
Yeah I still haven't quite worked out all the USB OTG issues, hopefully they'll be fixed for the next build.
I see somebody else answered #2, as for the search bar being blank I'm not really sure what's up with that. I'll ask the OmniROM guys, I'm guessing it could maybe be a legal issue with using Google's images.
100% +1I would like to be absolutely honest with you - in my opinion rare but major updates are preferable. This nightly/weekly updates are totally useless - but this is just my opinion. I also think that it is a must to be used latest Linaro Toolchain 4.9 by @Christopher83 and you can also make a chat with him for any question in connection with his Linaro 4.9 toolchain because he and his ADC-Team are really nice and helpful devs! Lag on home/recents, drawer and notification (swipe/pull down/remove) should be totally executed. Also i think that you gotta keep focusing on EXT4 and Dalvik instead of F2FS or ART. Because both ART and F2FS are just experimental things for KitKat. We better stick with good old dalvik which is really stable. About this DSP thing which you wrote - you can put this for last thing in your project. But rare and major builds are preferable - even once a month!
I have a question for you guys:
Would you rather see more frequent FML builds but with less changes in each build, or continue with what I've been doing lately and release builds less frequently with a huge amount of changes in each build?
Part of what has caused me to slow down with releasing builds is that I'm just getting extremely ambitious with things. For example, here's a preview of the changes for the next build, in order of when they were um, started.
- Complete overhaul of the kernel, rebasing it on top of Ziyan's heavily updated kernel. He managed to pull in upwards of 1,000 commits from the omapzoom kernel (sort of the 'official' OMAP (the CPU the Galaxy Nexus uses) kernel, which while the Galaxy Nexus was based on this kernel, it got neglected and wasn't kept up to date). I've also used this as an opportunity to clean up many things with the previous kernel and do them 'properly' this time around.
- Laid down some initial code for "OMAP Audio Control". This isn't going to be much for a while, as I'm not really familiar with Digital Signal Processing (DSP), at least on such a low level! But like just about everything I do with FML, it's an opportunity for me to learn new things.
- Switched the compiler for the ROM to Linaro's GCC 4.9, and the compiler for the kernel to 'standard' GCC 4.9. This should result in an all-around improvement of speed, however it also could introduce some bugs. The kernel seems fine, but the ROM-side of things was pretty disastrous:
--- First, it wouldn't boot at all. After a while I was able to figure out what the problem was and implement a workaround for it.
--- Second, it resulted in a huge problem with my /data partition, after tracking down and fixing what was causing this I had to reformat /data.
--- Third, fourth, fifth, sixth, and seventh, there were just random inexplicable crashes, that I somehow managed to fix. Seriously!
--- Eighth: I haven't gotten to eighth yet actually but I'm sure I will eventually!
- Small change to the build.prop that will improve (reduce) memory usage.
- Updated libpng from 1.2.46 (released in 2011, however 1.2 as a whole was originally released in 2001) to 1.6.10 (released just a few months ago, with 1.6 as a whole being released in 2013), and also enabled NEON for it. This may or may not affect speed or stability... I'm not going to say that it will as there's not really a way for me to measure it and if I try to 'guess' based on how it 'feels' my mind will probably play tricks on me and just make it a placebo effect, but I certainly like higher version numbers!
- Switched from libjpeg to libjpeg-turbo. Like the libpng change, libjpeg-turbo has NEON support, and as a result is claimed to be 2 to 4 times faster than the regular libjpeg.
- Enabled LTO (Link-Time Optimization) for all the things it previously had to be manually disabled for: parts of bionic and parts of ART. This is partly due to fixes and improvements to LTO by GCC 4.9.
I hope the links were helpful! I know this stuff can be hard to understand sometimes.
Yeah I still haven't quite worked out all the USB OTG issues, hopefully they'll be fixed for the next build.
I see somebody else answered #2, as for the search bar being blank I'm not really sure what's up with that. I'll ask the OmniROM guys, I'm guessing it could maybe be a legal issue with using Google's images.
On another note, I've been testing Chromecast mirroring with the GNex using @r3pwn's MirrorEnabler. Looks like for it to work on the GNex, Custom ROM maintainers must add audio.r_submix.default to the product_packages in the device.mk file.
Would it be possible to add this patch on your next build? Pretty please?