Database Users

gTablet-TapUI-1.1-Kernel-Patch -- Summary and Analysis

Now that we have the kernel source patch, I thought it would be good to summarise what's in it.
I've made a start here:
https://spreadsheets.google.com/ccc?key=tqj3aStfFS2K5PO83we84TQ&authkey=CI6h0aMD#gid=0
Because we don't have a full changelog, and it's a big patch, I thought it would be helpful to summarise what was changed in each file which brief comments. If you can help fill in the gaps for the modified files please post below.
Note that the patch appears to include a lot of cruft (multiple redundant backup copies of some files) I'd like to verify which files are redundant and produce a filtered, simplified patch. If you can confirm that the marked files are redundant that would be helpful.
I note that there are a few points where there is debug code and fixme comments in the patch. These may point to areas where things were never quite worked out (eg power management?). I don't have enough experience to look into this more deeply but just thought I'd mention it here.
Finally, the mmc driver has been brought in from outside the nv-tegra tree. It would be useful to generate a diff against the mainline tree to understand what (if anything) has changed there.
Happy Christmas!

I'm not very android dev savvy either...but they may have left the old drivers in there because old ROMs refer to them and they wanted to preserve the ability to go back to previous ROMs? -- that is...if the ROMs reference the kernel for drivers...not quite sure how that whole thing works...just a thought.

I've built a kernel from these sources, but unfortunately the bootloader throws a "magic value mismatch" error rather than booting the kernel. Has anybody else had any better luck?
EDIT: my bad, I replaced the boot.img with the raw zImage. I now have it booting my kernel, but it dies like this when starting Android:
I/SurfaceFlinger( 1072): SurfaceFlinger is starting
I/SurfaceFlinger( 1072): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/Zygote ( 1070): Process 1072 terminated by signal (11)
I/Zygote ( 1070): Exit zygote because system server (1072) has terminated

Any lines starting with - are deleted code.

NMCBR600 said:
Any lines starting with - are deleted code.
Click to expand...
Click to collapse
Yeah, in the patch itself, lines starting with + are added, and starting with - are deleted.
In the spreadsheet linked above, lines starting with + are files added, -files deleted, and !modified.
Actually the patch deletes no files, but /arch/microblaze/boot/dts/system.dts is overwritten with a new one. Anyone know exactly what that file does?
I started this because when I was reading the patch it seemed like a lot of new files were added and I wanted to work out where they came from, but it now looks like a lot of the added files are just backup copies the Malata dev has left in the tree (not a bad programming practice during development, but makes the patch a bit confusing to read).
Seems like the new files that are added (that aren't backups) are:
+ touch screen drivers in arch/arm/mach-tegra/odm_kit/platform/touch/{ak4183,at168}
+ driver for buttons in drivers/input/keyboard/so340010_kbd.c
+ drivers for gps control (power on/off), light sensor and accellerometer in drivers/input/misc/{gps_control.c,isl29023_ls.*,lis35de_accel.*}
+ drivers for batteries in drivers/power/smba10xx_battery and drivers/power/yoku_0563113
+ drivers for headphone and dock switches in drivers/switch/{switch_dock.c,switch_h2w.c} (header file in include/linux/switch_dock.h)
Also, mmc driver (presumably from mainline linux) is imported drivers/mmc

+ drivers for gps control (power on/off), light sensor and accellerometer in drivers/input/misc/{gps_control.c,isl29023_ls.*,lis35de_accel.*}
Sounds promising ..

Can someone explain to me perhaps if I'm missing something here- but what I am to understand from this post is that we finally got the source for the gtablet kernel? Would this incline to mean that we could compile the touchscreen and etc drivers onto a standard linux kernel and pop ubuntu or other such on the gtablet?
Or is 'patch' referring to just some small subset of the code missing the majority required to compile a gtablet kernel?
Any chance we might then be able to hack a fix into the accelerometer code to align the axis correctly?

rswindle said:
Can someone explain to me perhaps if I'm missing something here- but what I am to understand from this post is that we finally got the source for the gtablet kernel? Would this incline to mean that we could compile the touchscreen and etc drivers onto a standard linux kernel and pop ubuntu or other such on the gtablet?
Click to expand...
Click to collapse
One would have to recompile Ubuntu (or whatever distro) for ARM. Also, a finger friendly GUI would have to be added allowing the Capacitive screen to do its thing. Its very possible now with the kernel but no, you cannot use the iso downloaded from ubuntu.com.

rswindle said:
Can someone explain to me perhaps if I'm missing something here- but what I am to understand from this post is that we finally got the source for the gtablet kernel? Would this incline to mean that we could compile the touchscreen and etc drivers onto a standard linux kernel and pop ubuntu or other such on the gtablet?
Or is 'patch' referring to just some small subset of the code missing the majority required to compile a gtablet kernel?
Any chance we might then be able to hack a fix into the accelerometer code to align the axis correctly?
Click to expand...
Click to collapse
The drivers for the touchscreen, battery, and the accelerometer are all there in the kernel patch or the Nvidia tegra2 repo that it's patched again, yes. It's up on Viewsonic's website, in the support section.
Yes, you can merge them into an Ubuntu kernel if you want to. I'm sure somebody will do that in the next few weeks/months, it just hasn't happened yet since we just got the code dropped a few days ago.
There's some threads in NVidia's tegra2 dev forums on getting Ubuntu to work with a tegra 2 kernel. I posted the link earlier today if you're curious, look through my posts.

Great, so then the next question is, has anyone yet gotten a bootable compiled kernel from these yet?
Would be cool to get a stock android system compiled against a standard kernel for gtab.
Now I'm going to have to go rig up a linux thumb when I get home to start compiling the kernel with the patched sources and see what I can do. I so want to fix the damn accelerometer..
Best of all, my wife can play angry birds the entire time so she won't complain our HTPC is being used for my insanity..
Any suggestions what's a super lite fast distro to toss on a thumb quick that would quickly have me in position to git linux sources and compile this kernel? I don't keep up with the distros these days..

Yes
rswindle said:
Great, so then the next question is, has anyone yet gotten a bootable compiled kernel from these yet?
Would be cool to get a stock android system compiled against a standard kernel for gtab.
Now I'm going to have to go rig up a linux thumb when I get home to start compiling the kernel with the patched sources and see what I can do. I so want to fix the damn accelerometer..
Best of all, my wife can play angry birds the entire time so she won't complain our HTPC is being used for my insanity..
Any suggestions what's a super lite fast distro to toss on a thumb quick that would quickly have me in position to git linux sources and compile this kernel? I don't keep up with the distros these days..
Click to expand...
Click to collapse
I believe at least a half dozen of us have now built and deployed our own kernels. I've started cherry-picking Nvidia fixes beyond the baseline looking for something to fix the slowdown problem. Trying the latest variation now.
As for the accelerometer, I don't play any games where that is an issue, so I don't know if this resolves the problems, but there is a 1 line patch beyond our baseline in the Nividia tree which switches the X axis. Maybe this is the issue?
The patch description is:
X direction needs to be reversed to correct orientation in portrait
mode for Whistler.
Bug 678250
and the code diff is here:
http://nv-tegra.nvidia.com/gitweb/?...ff;h=6d57f00bb8276e0392dfa199017fc70fcea7d60b
I have applied this in my current kernel, but I've never seen the bug and can't tell you if it makes a difference.

[email protected] said:
I believe at least a half dozen of us have now built and deployed our own kernels. I've started cherry-picking Nvidia fixes beyond the baseline looking for something to fix the slowdown problem. Trying the latest variation now.
As for the accelerometer, I don't play any games where that is an issue, so I don't know if this resolves the problems, but there is a 1 line patch beyond our baseline in the Nividia tree which switches the X axis. Maybe this is the issue?
The patch description is:
X direction needs to be reversed to correct orientation in portrait
mode for Whistler.
Bug 678250
and the code diff is here:
http://nv-tegra.nvidia.com/gitweb/?...ff;h=6d57f00bb8276e0392dfa199017fc70fcea7d60b
I have applied this in my current kernel, but I've never seen the bug and can't tell you if it makes a difference.
Click to expand...
Click to collapse
mdwalker, I've likewise built my own kernel and have been running it too. I likewise have been trying to isolate and fix the slowdown problem. I likewise haven't succeeded yet.
There are a bunch of patches in the Nvidia tree that relate to suspend-resume issues, which I'm sure you've noticed. Let me know if you zero in on anything.

question.. I noticed all the developers are from Nvidia, I would think they would be Viewsonic developers... and if not the case are these bugs were not caught a while ago?

Viewsonic doesn't make this
stanglx said:
question.. I noticed all the developers are from Nvidia, I would think they would be Viewsonic developers... and if not the case are these bugs were not caught a while ago?
Click to expand...
Click to collapse
Viewsonic doesn't make our tablet, it's made by a Chinese company called Malata based on a standard Nvidia design. Viewsonic just resells it in the US.
There are actually a number of "rebadged" variations of this tablet, with more appearing almost every day.

Absolutely
rcgabriel said:
mdwalker, I've likewise built my own kernel and have been running it too. I likewise have been trying to isolate and fix the slowdown problem. I likewise haven't succeeded yet.
There are a bunch of patches in the Nvidia tree that relate to suspend-resume issues, which I'm sure you've noticed. Let me know if you zero in on anything.
Click to expand...
Click to collapse
Yes, I've certainly noticed the suspend/resume functionality looks to be a frequent source of "fixes". There are lots of patches which sound promising. Hopefully one (or more, gah!) will do the trick without having to hack up the cpu power management itself.
Likewise if you (or pershoot, or ... whomever else is tinkering) finds the right combination, please let us know!

Understand that... The point I am making is why is there so much Nvidia development going on for a version of the Kernel that is considered stable?
[email protected] said:
Viewsonic doesn't make our tablet, it's made by a Chinese company called Malata based on a standard Nvidia design. Viewsonic just resells it in the US.
There are actually a number of "rebadged" variations of this tablet, with more appearing almost every day.
Click to expand...
Click to collapse

rswindle said:
Now I'm going to have to go rig up a linux thumb when I get home to start compiling the kernel with the patched sources and see what I can do. I so want to fix the damn accelerometer..
Click to expand...
Click to collapse
Don't waste your time on the accelerometer, as the problem is with the app devs, not our device.
A nice explanation is here: http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html

iptables owner module
One of the critical features I am looking for is a kernel built with support for iptables, and specifically the "owner" module.
This is used by apps such as Droidwall and my own app, Orbot, which is the port of Tor to Android. I worked with Cyanogen on this issue previously and am hoping to get this into all of the ROMs for the GTablet as well.
Thanks!

stanglx said:
Understand that... The point I am making is why is there so much Nvidia development going on for a version of the Kernel that is considered stable?
Click to expand...
Click to collapse
Why are you considering it's stable? Afaik there are very few products running the NVIDIA kernel at this stage -- the base hardware target is "harmony", which is actually one of NVIDIA's development boards.
G Tablet is one of the first Tegra 2 based products and we are about to see a whole raft of them over the next 6 months. Starting with Gingerbread tablets and then going to Honeycomb. If you check the logs you'll see that stuff from nv-tegra repo is being merged into the AOSP repo pretty regularly at the moment. Presumably, preparing for the Motorola Tegra 2 tablet. I imagine NVIDIA devs are quite busy on that.

I think a bigger question is why the very different codes at kernel.org and Navdia's own repository? In some cases commits are pulled in from each other, but clearly they are on different paths. Motorola seems to be pushing commits to kernel.org.
s_frit said:
Why are you considering it's stable? Afaik there are very few products running the NVIDIA kernel at this stage -- the base hardware target is "harmony", which is actually one of NVIDIA's development boards.
G Tablet is one of the first Tegra 2 based products and we are about to see a whole raft of them over the next 6 months. Starting with Gingerbread tablets and then going to Honeycomb. If you check the logs you'll see that stuff from nv-tegra repo is being merged into the AOSP repo pretty regularly at the moment. Presumably, preparing for the Motorola Tegra 2 tablet. I imagine NVIDIA devs are quite busy on that.
Click to expand...
Click to collapse

[news] cm10.1 status update

Originally Posted by CYANOGENMOD
in facebook
CM 10.1 Status Update
So we continue to work through the merger of 4.2 code and our CM enhancements. A branch in our github repos called mr1-staging has been created to facilitate the merger and is the target for core CM items (not features).
mr1-staging is not meant to be compile-able, its only purpose is to be a staging grounds for our core work. Chances are, it is useless for independent builders.
CM 10.0 (4.1.2) code is in jellybean-stable, if you are working on a bug-fix for the last stable release, patches should be submitted against that branch. If/when we do another 4.1.2 release (ie CM 10.0.x), it will originate from code in this branch.
Once staging is done in mr1-staging, we will push all that code to a 'CM10.1' branch, and eventually back to our primary 'jellybean' branch. This process is in place to make sure that we effectively move forward from CM 10.0 code, instead of starting over as was seen with the jump from Gingerbread to ICS. Patches from gerrit will be accepted towards CM 10.1, but for now, please have patience while we work through mr1-staging.
While the 4.2 updates are on a smaller scale, they do present some changes that will need to be considered and will effect our implementation of features. Just to name them briefly: Telephony Split, Multi-User, Quick Settings, and Lock-Screen Widgets. These items will be a strong focus when the initial CM10.1 branch is created.
On the feature front, David van Tonder (dvtonder) decided to make his weekend productive, and has already worked on the code for the majority of our MMS enhancements: Emoji support, sms split, gestures and templates, quick messaging. Notably MMS auto retrieve is not being forward ported as Google fixed that themselves. As stated above, patches will hit gerrit review after this staging process is completed.
As always, a timeline isn't and won't be available. We will continue to provide updates as we have them.
Click to expand...
Click to collapse
Let's wait for further announcements

FXP has already stated that they won't be brining 4.2 (CM10.1) to any of the 2011 devices because of RAM limitations.. which makes this news pretty pointless.
Edit: FXP post here: http://forum.xda-developers.com/showpost.php?p=34344841&postcount=3896

[Q] Xperia Z2 OmniROM

Hello guys
May i ask if OmniROM will ever make it to the Xperia Z2 (Sirius)?
Been missing it for ages now
Keep up the great work

mariotme said:
Hello guys
May i ask if OmniROM will ever make it to the Xperia Z2 (Sirius)?
Been missing it for ages now
Keep up the great work
Click to expand...
Click to collapse
I normally just report device requests, but since I've done a lot of the Sony bringups:
I wanted a Z2. I really, really wanted one.
However I don't buy greymarket imports, and Sony refused to sell the Z2 in North America until after the Z3 was launched. Even now, the purchasing link is nearly impossible to find (it is not listed for sale anywhere on sonymobile.com)
Z3 is a possibility if it goes on sale unlocked in North America in a timely fashion. (Which is unlikely...) Z2 is a possibility if some maintainer picks it up, of course, but considering the device's successor is out now, that's pretty unlikely.

Entropy512 said:
I normally just report device requests, but since I've done a lot of the Sony bringups:
I wanted a Z2. I really, really wanted one.
However I don't buy greymarket imports, and Sony refused to sell the Z2 in North America until after the Z3 was launched. Even now, the purchasing link is nearly impossible to find (it is not listed for sale anywhere on sonymobile.com)
Z3 is a possibility if it goes on sale unlocked in North America in a timely fashion. (Which is unlikely...) Z2 is a possibility if some maintainer picks it up, of course, but considering the device's successor is out now, that's pretty unlikely.
Click to expand...
Click to collapse
I totally understand Entropy512! Thanks for your input buddy. Appreciate all your efforts man. Keep it up :good:

Entropy512 said:
I wanted a Z2. I really, really wanted one.
Click to expand...
Click to collapse
Thanks for your answer, yes that's the best smartphone I've ever got! Why the hell do they think they don't need to sell their devices in america??
As I know you are a major developer of OmniRom, I really hope you will be able to get an Xperia Z4, and hopefully port the ROM on it..
Thanks for your work!:good:

May I Taste said:
Thanks for your answer, yes that's the best smartphone I've ever got! Why the hell do they think they don't need to sell their devices in america??
As I know you are a major developer of OmniRom, I really hope you will be able to get an Xperia Z4, and hopefully port the ROM on it..
Thanks for your work!:good:
Click to expand...
Click to collapse
I'll probably skip the Z4 thanks to Sony's crazy 6-month product cycle.
I have a Z3 but so far it's stock. This device is holding a record for the longest I've gone without root/unlocking the BL.
Sony did an awesome job with the stock firmware on the SIM-unlocked Z3.

Entropy512 said:
I'll probably skip the Z4 thanks to Sony's crazy 6-month product cycle.
I have a Z3 but so far it's stock. This device is holding a record for the longest I've gone without root/unlocking the BL.
Sony did an awesome job with the stock firmware on the SIM-unlocked Z3.
Click to expand...
Click to collapse
Thanks for your kind answer and I can understand you. It seems however that the Z4 will now last for one year as flagship. Anyway I'll make sure to stay tuned if by chance you work on OmniROM for it.
Have a wonderful year, you and your whole family!

There some unofficial builds for the Sony Sirius floating around...
http://infectedbuilds.net/downloads/sirius/omni_lp/
From my very brief play with it, there's no Cam or NFC but everything else seems pretty useable.

A number of Omni team members are working with the Sony AOSP guys. Short-term it means a lot of things are broken that aren't in CM since Sony AOSP is reworking a bunch of stuff onto a newer unified kernel that will support a large variety of devices. Long-term it'll allow us to support more Sony devices with less effort.
I think one of the guys working this has a sirius... I forget who.

I just synced all the Omnirom repos and compiled for the Z2. It works ok, just no Camera, recovery and there seems to be a bug around internal storage, as it thinks there is no space left.
I'd be interested in helping to fix these things, I'm pretty comfortable using git and gerrit and know some Java and C++ but I have no idea where to start.
Code:
adb logcat | grep camera
- waiting for device -
E/CameraService( 373): Could not load camera HAL module
W/ResourcesManager( 1057): Asset path '/system/framework/com.google.android.camera2.jar' does not exist or contains no resources.
I/CameraManagerGlobal( 1057): getCameraService: Reconnecting to camera service
E/CameraService( 373): getCameraVendorTagDescriptor: camera hardware module doesn't exist
W/CameraManagerGlobal( 1057): Failed to set up vendor tags: The camera device is removable and has been disconnected from the Android device, or the camera service has shut down the connection due to a higher-priority access request for the camera device.
So I'd guess I'd have to find out why the camera HAL module can't be loaded?

mikeysteele said:
I just synced all the Omnirom repos and compiled for the Z2. It works ok, just no Camera, recovery and there seems to be a bug around internal storage, as it thinks there is no space left.
I'd be interested in helping to fix these things, I'm pretty comfortable using git and gerrit and know some Java and C++ but I have no idea where to start.
Code:
adb logcat | grep camera
- waiting for device -
E/CameraService( 373): Could not load camera HAL module
W/ResourcesManager( 1057): Asset path '/system/framework/com.google.android.camera2.jar' does not exist or contains no resources.
I/CameraManagerGlobal( 1057): getCameraService: Reconnecting to camera service
E/CameraService( 373): getCameraVendorTagDescriptor: camera hardware module doesn't exist
W/CameraManagerGlobal( 1057): Failed to set up vendor tags: The camera device is removable and has been disconnected from the Android device, or the camera service has shut down the connection due to a higher-priority access request for the camera device.
So I'd guess I'd have to find out why the camera HAL module can't be loaded?
Click to expand...
Click to collapse
Camera is far away from being supported. The blobs are completely missing, because they simply won't work with our kernel.
There's work being done, however a lot of it has to be done by someone within Sony and that results in stuff having to go through a legal approval process.
In theory it might be possible with some work to get 5.0 camera blobs working with a lot of kernel hacking, but most people are focusing on a cleaner approach that will take longer and unfortunately has dependencies on Sony's lawyers.

Entropy512 said:
Camera is far away from being supported. The blobs are completely missing, because they simply won't work with our kernel.
There's work being done, however a lot of it has to be done by someone within Sony and that results in stuff having to go through a legal approval process.
In theory it might be possible with some work to get 5.0 camera blobs working with a lot of kernel hacking, but most people are focusing on a cleaner approach that will take longer and unfortunately has dependencies on Sony's lawyers.
Click to expand...
Click to collapse
Thanks for the update. I noticed there weren't any camera blobs in the source, so I assumed it wasn't as simple as just adding them in. I see on github the CM guys hacked their kernel to be able to use the old Jellybean camera blobs which looks painful. Hopefully Sony's lawyers aren't too obstructionist. Although to their credit the Sony stock rom isn't actually too bad. Nothing compared to Omni Rom though.

mikeysteele said:
Thanks for the update. I noticed there weren't any camera blobs in the source, so I assumed it wasn't as simple as just adding them in. I see on github the CM guys hacked their kernel to be able to use the old Jellybean camera blobs which looks painful. Hopefully Sony's lawyers aren't too obstructionist. Although to their credit the Sony stock rom isn't actually too bad. Nothing compared to Omni Rom though.
Click to expand...
Click to collapse
Yeah. They used a kernel backcompat hack, and are using old 4.3 rhine blobs because those are the last ones that were completely 100% DRM-free.
DRM issues have caused all sorts of problems with rhine/shinano cameras ever since 4.4 - Workarounds for many of these have been found, but not all. But the kernel backcompat hacks would still be needed (potentially multiple hacks for each device supported by the Sony AOSP kernel) and that gets nasty.
So the current plan is to have a unified set of sensor drivers in the kernel, with blobs provided as part of the Sony AOSP project. However I think this is going to be easier said than done - it's not just Sony lawyers, but Qualcomm lawyers. It really sucks that the entirety of Qualcomm's mm-camera subsystem is proprietary and there's no way for an opensource developer to write modules for it, which prevents any of the community side of the Sony AOSP project from working on some things. Otherwise it would probably be not too difficult to replace Sony's noise reduction algorithm (likely with a better one... Sony's NR algorithm got slammed for being too aggressive and killing sharpness over in a dpreview review... All that DRM protection for something some people actually prefer to have gone.)
Edit: And yes, Sony's stock firmwares are amazing. My Z3 holds the record for longest I've ever owned a device without even bothering to root it.

Another thing, my phone is the China Mobile version (L50t) and OmniRom runs perfectly on it, I just have to change the radio and wlan firmware. I can supply the required files and be a tester if you wanted to add official support for this varient.

[ZEN-KERNEL] 3.10-zen for nexus 9 - testers

Call me crazy but the best kernel for the nexus 6 is coming to the nexus 9, a device I don't have
Zen kernel is pretty sane and doesn't have changes like SuperMegaIOBlastFrequency5Million, but somehow it manages a bigger improvement than all those changes put together primarily through better CPU scheduling for the light-numa workloads of our mobile devices (in other words, BFS)
I have a BFS port from v461 (minus SMT nice )for 3.10 android/msm along with most of Alfred Chen's -gc branch includes as well.
Anyway, the effects are noticeable in the nexus 6 (no more google now launcher lag, no more big list lag, no more 3 second clear all recent delay, better power consumption through better frequency scaling by design of sticky tasks)
I think it will be just as good on the nexus 9, however I don't have one of these devices in my possession so I'm not gonna ask for people to buy me one instead I'm just going to ask for testers.
I'd like to see the effects of BFS on arm64 and I'm sure everybody else would like to see the benefits -zen kernel brings.
PM me if you would like a weekend build. I need at least 3 but the more the merrier.
Zen kernel for nexus 6
Thanks,
B

Also if you ask for a build tell me what ROM and existing kernel you are on if applicable.

Will you be getting a N9 in the future?
Sent From Capsule Corp.

Ace42 said:
Will you be getting a N9 in the future?
Sent From Capsule Corp.
Click to expand...
Click to collapse
Probably not, I graduate next month and plan on expanding my open source endeavors then but I'd like to support the nexus devices + 1 or 2 other flag ships with zen at all times.
People are happy over at N6, they were happy back on gnex and evo 4g I'm sure they will like nexus 9 version too
The custom kernel landscape has changed since the old days because there's less problems with new devices, but zen still finds a way
I'm really looking to change issues as I see them here. I don't want to bolster big names, give me money, this project is mine, etc. I want to bolster the community effort in a way that aids in learning, growth , etc. Zen is all about real kernel improvements. in time there is an app I've had on the shelf for 3 years with a brilliant framework among other things that I want to GPL-ize and release.

bbedward said:
Probably not, I graduate next month and plan on expanding my open source endeavors then but I'd like to support the nexus devices + 1 or 2 other flag ships with zen at all times.
People are happy over at N6, they were happy back on gnex and evo 4g I'm sure they will like nexus 9 version too
The custom kernel landscape has changed since the old days because there's less problems with new devices, but zen still finds a way
I'm really looking to change issues as I see them here. I don't want to bolster big names, give me money, this project is mine, etc. I want to bolster the community effort in a way that aids in learning, growth , etc. Zen is all about real kernel improvements. in time there is an app I've had on the shelf for 3 years with a brilliant framework among other things that I want to GPL-ize and release.
Click to expand...
Click to collapse
At some point in time years ago I was a know nothing, figure out how to apply a patch, compile a kernel amateur. But through a great Linux, gentoo, arch , etc . community I have now become a proficient programmer, graduating with computer science + engineering degree in a few weeks.
the XDA community hasn't been about helping people learn or grow in any form. Its become a pit of protecting private property and don't take my work, don't ask dumb questions, just give up. I want to see more community efforts rather than private all mine type of stuff.

I've always wanted to develop a ROM or kernel, but the steps to just get Linux on my laptop is too much let alone driver support. If there was a simple way to use just windows 8 I would like to contribute to the N9 community.
Also I commend you for your studies, neither of those fields are easy from what I've heard. :good:

bbedward said:
At some point in time years ago I was a know nothing, figure out how to apply a patch, compile a kernel amateur. But through a great Linux, gentoo, arch , etc . community I have now become a proficient programmer, graduating with computer science + engineering degree in a few weeks.
the XDA community hasn't been about helping people learn or grow in any form. Its become a pit of protecting private property and don't take my work, don't ask dumb questions, just give up. I want to see more community efforts rather than private all mine type of stuff.
Click to expand...
Click to collapse
I was like you a know nothing about kernels
I started kernel development knowing nothing
I still don't know much but, I'm learning slowly
Im vary interested in the source code
Also to test

Ace42 said:
I've always wanted to develop a ROM or kernel, but the steps to just get Linux on my laptop is too much let alone driver support. If there was a simple way to use just windows 8 I would like to contribute to the N9 community.
Also I commend you for your studies, neither of those fields are easy from what I've heard. :good:
Click to expand...
Click to collapse
Thanks, many linux distributions nowadays make it incredibly easy to get started though I'd venture to say most of them will work out of the box with your hardware.
USBhost said:
I was like you a know nothing about kernels
I started kernel development knowing nothing
I still don't know much but, I'm learning slowly
Im vary interested in the source code
Also to test
Click to expand...
Click to collapse
Probably will have a test Friday, just going to use AnyKernel2 for the N9 probably (only replace fstab with f2fs support and no force encryption).
The N6 tree is here:
https://github.com/bbedward/ZenKernel_Shamu
The BFS branch is here (I split everything into individual branches on Zen):
https://github.com/bbedward/ZenKernel_Shamu/commits/sched_upstream_bfs_gc
Some of the stuff from my N6 kernel is a drop in for the N9 since they are both 3.10 based.

https://www.dropbox.com/s/uekphwlxvm2pya9/v3.10-zen0_anykernel_N9.zip?dl=0
Please make sure you have a backup plan if it doesn't work
It has almost identical to Zen-nexus 6 stuff:
- My sched_upstream_bfs_gc branch pretty much identical to the N6 kernel branch
- Not identical to the N6 branch because nvidia has a bunch of nonsense sched stat stuff I added into BFS also
- Fiops/BFQ in addition to the default stuff
- ext4 from v3.10.y stable
- newest f2fs
- usb fast charge support
- 2A charging
- fsync toggle
- upstream MM stuff from v3.10.y
- Several race condition fixes, memory leak fixes from upstream
- flar2 wake gesture support
- overclock support whatever elementalX has up to 2.5GHz
- USB fast charging
No idea if it works, please have a backup ready.
There's lots of compile warnings in the tegra kernel and I had to build myself an aarch64 compiler because I didn't have one.

bbedward said:
https://www.dropbox.com/s/uekphwlxvm2pya9/v3.10-zen0_anykernel_N9.zip?dl=0
Please make sure you have a backup plan if it doesn't work
It has almost identical to Zen-nexus 6 stuff:
- My sched_upstream_bfs_gc branch pretty much identical to the N6 kernel branch
- Not identical to the N6 branch because nvidia has a bunch of nonsense sched stat stuff I added into BFS also
- Fiops/BFQ in addition to the default stuff
- ext4 from v3.10.y stable
- newest f2fs
- usb fast charge support
- 2A charging
- fsync toggle
- upstream MM stuff from v3.10.y
- Several race condition fixes, memory leak fixes from upstream
- flar2 wake gesture support
- overclock support whatever elementalX has up to 2.5GHz
- USB fast charging
No idea if it works, please have a backup ready.
There's lots of compile warnings in the tegra kernel and I had to build myself an aarch64 compiler because I didn't have one.
Click to expand...
Click to collapse
Will test tomorrow
How did you update f2fs?

USBhost said:
Will test tomorrow
How did you update f2fs?
Click to expand...
Click to collapse
I will push the source up once I can later tonight. It's quite hefty so it will take awhile to push up the first time
The way I did everything is almost the exact same as the N6 kernel. Some nvidia garbage had to be implemented into BFS but that's it. And the device specifics like OC, 2A charging, etc.
https://github.com/bbedward/ZenKernel_Shamu/commits/f2fs_upstream
everything is exactly the same except the first f2fs commit "Sync with kernel/f2fs.git linux-3.10 branch"
There I basically just delete everything in fs/f2fs. copy/paste fs/f2fs from that branch, copy include/linux/f2fs* include/trace/events/f2fs (maybe? I forget where all the headers are exactly) and also update the Documentation/filesystem/f2fs.txt
The only reason I do that is because the f2fs/linux-3.10 branch is oddly based on linux-4.0. So simply merging or cherry picking won't work too well, and things like the msm and tegra kernel have different versions of f2fs already. So i just clear it all out and sync with that.
After that I pulled in all the newer commits from the f2fs/dev branch.

bbedward said:
I will push the source up once I can later tonight. It's quite hefty so it will take awhile to push up the first time
The way I did everything is almost the exact same as the N6 kernel. Some nvidia garbage had to be implemented into BFS but that's it. And the device specifics like OC, 2A charging, etc.
https://github.com/bbedward/ZenKernel_Shamu/commits/f2fs_upstream
everything is exactly the same except the first f2fs commit "Sync with kernel/f2fs.git linux-3.10 branch"
There I basically just delete everything in fs/f2fs. copy/paste fs/f2fs from that branch, copy include/linux/f2fs* include/trace/events/f2fs (maybe? I forget where all the headers are exactly) and also update the Documentation/filesystem/f2fs.txt
The only reason I do that is because the f2fs/linux-3.10 branch is oddly based on linux-4.0. So simply merging or cherry picking won't work too well, and things like the msm and tegra kernel have different versions of f2fs already. So i just clear it all out and sync with that.
After that I pulled in all the newer commits from the f2fs/dev branch.
Click to expand...
Click to collapse
O so thats how you did it
I was scratching my head with all the problems of cherry-picking I was having lol

Source is up:
https://github.com/bbedward/ZenKernel_Flounder
The real glory lives here:
https://github.com/bbedward/ZenKernel_Flounder/commits/sched_upstream_bfs_gc

bbedward said:
Source is up:
https://github.com/bbedward/ZenKernel_Flounder
The real glory lives here:
https://github.com/bbedward/ZenKernel_Flounder/commits/sched_upstream_bfs_gc
Click to expand...
Click to collapse
Thanks man

bbedward said:
https://www.dropbox.com/s/uekphwlxvm2pya9/v3.10-zen0_anykernel_N9.zip?dl=0
Please make sure you have a backup plan if it doesn't work
Click to expand...
Click to collapse
Could you provide a boot.img, to be used as in
Code:
fastboot boot boot.img
I tried with the zImage but that did not boot at all and I don't dare to flash it - yet

taronas said:
Could you provide a boot.img, to be used as in
Code:
fastboot boot boot.img
I tried with the zImage but that did not boot at all and I don't dare to flash it - yet
Click to expand...
Click to collapse
Did you flash it through recovery? This is where it needs to be flashed.
I plan on only providing AnyKernel version for the N9 though, so it requires existing ramdisk.

Somebody has to be willing to try this for me. All you have to do dirty flash your ROM or flash another kernel if it doesn't work.

bbedward said:
Somebody has to be willing to try this for me. All you have to do dirty flash your ROM or flash another kernel if it doesn't work.
Click to expand...
Click to collapse
Will do in a few hours
Ps I tryed what you did with f2fs
it built but data did not mount
I was encrypted also

Didn't boot for me. Tried on a 32gig encrypted n9, running cm12.1, wifi

dictionary said:
Didn't boot for me. Tried on a 32gig encrypted n9, running cm12.1, wifi
Click to expand...
Click to collapse
Maybe because CM12.1 is 5.1 based? This is all based on stock kernel.
I will look to see if there's compatibility issues.

Sandboxed Play services

GrapheneOS has this nice new feature called Sandboxed Play services which basically allows to run google play services as unprivileged apps. To make this possible, they built a compatibility layer.
For testing purposes I already merged necessary commits and created patches for LOS. As I'm not going to publicly release any builds, I've already posted a guide so that any rom builder can easily integrate the gms compatibility layer in their rom (not necessarily lineageos).
But, I'd love to see this in LineageOS officially. In a comment on reddit it sounds like the main problem is that the feature violates the Android Compatible Device Document. However, after looking at the source code of the compatibility layer, it seems like the layer could easily be implemented without violating anything. In fact, the gmscompat layer was implemented as a compatibility change to reuse the existing compatibility change infrastructure. It is a special implementation though, and automatically get's activated for GMS apps only (see these two patches).
My thinking is, if the compat change isn't activated on its own for GMS apps, but additionally relies on a checkbox (disabled by default) in the system menu, that wouldn't violate anything, because the default behaviour isn't tampered with at all. And as soon as the user enables the compatibility layer with the help of the aforementioned system menu setting, Google play services can be run in a sandbox.
What do you think?

I had inquired with the graphene devs about 2 or 3 weeks ago and they couldn't even tell me all of the repos I had to cherry pick the 100+ commits from....thanks for this. I've been putting off integrating this into my LOS ROM since I started developing it almost a month ago

> I had a with the graphene devs about 2 or 3 weeks ago and they couldn't even tell me all of the repos I had to cherry pick the 100+ commits from....thanks for this. I've been putting off integrating this into my LOS ROM since I started developing it almost a month ago
You can check the commits here: https://gist.github.com/thestinger/ee536cbd1ca674b94dde05831192c348#comments

Wait, that's all the commits needed?

PiXinCreate said:
> I had inquired with the graphene devs about 2 or 3 weeks ago and they couldn't even tell me all of the repos I had to cherry pick the 100+ commits from....thanks for this. I've been putting off integrating this into my LOS ROM since I started developing it almost a month ago
You can check the commits here: https://gist.github.com/thestinger/ee536cbd1ca674b94dde05831192c348#comments
Click to expand...
Click to collapse
Thanks so much for that. Seriously. I FINALLY have Sandboxed Play Services working.
It's a Lineage 19.1 rom

Glad to know about that!
I'm new to all these ROM development stuffs. I'd be helpful if you publish your work on GitHub with a build documentation.. (optional, you can decline my request).
As the dev already has confirmed that former (GMS_Sandbox) is ROM independent, I personally feel like making a Magisk Module for that, which will be systemless and optimal.

Yeah, I surely will upload my sources. It's just so monotonous creating each repo one by one and adding remotes lol I've been putting it off.
Getting it working with that gist was very easy though, most every commit auto-merged.
But yeah, I'll upload those sources and post back here when they are up.
( I am new as well btw, I just got started about a month ago)
EDIT: SOURCES

From what I read the Lineage OS developers don't seem very cooperative, at least on this front (see LineageOS for microG).
A Magisk module would be amazing. It would also make the work I just did to compile Lineage obsolete
Do you already have a technical approach for such a module? Would you just replace the files that have been changed? How concrete are your plans to make it?

Sewdohe said:
Thanks so much for that. Seriously. I FINALLY have Sandboxed Play Services working.
It's a Lineage 19.1 rom
Click to expand...
Click to collapse
u have sandboxed Google's for lineageos 19.1?
can u explain how u got it done?
Thanks