Related
Just found these online....
X10_Donut_100325_01 Open Source Software Download (78MB)
http://developer.sonyericsson.com/w...wnload/dw-300009-x10donut10032501?cc=gb&lc=en
Source code!!!!
Sony Ericsson Xperia X10 add-on for the Android SDK (51MB)
http://developer.sonyericsson.com/w...d/dw-102216-xperia-x10sdkadd-onr1?cc=gb&lc=en
Skin, IMG files, hardware.ini, manifest.ini
All X10 downloads, including a whitepaper:
http://developer.sonyericsson.com/wportal/devworld/search-downloads?cc=gb&lc=en&q=x10
IMO the best decision they have made in a long time. Way to go Sony!
This is just the source for the GPL parts Sony are required to release, like the kernel and any modifications they made to open-source projects (webkit, etc).
They're just doing their duty under the GPL, and it's a nastily-packed blob of source rather than diffs or any kind of documentation, which is even the laziest/worst way to do it.
The Timescape/etc. UI stuff isn't in here, so don't get too excited.
Yet another Sony fail.
Paul22000 said:
Yet another Sony fail.
Click to expand...
Click to collapse
Hows that?
I've seen Paul(Modaco) say he had trouble with the desire camera because of HTC's kernel hooks/mods, with this source it will be easier for sony apps.
britoso said:
Hows that?
Click to expand...
Click to collapse
I meant this part:
They're just doing their duty under the GPL, and it's a nastily-packed blob of source rather than diffs or any kind of documentation, which is even the laziest/worst way to do it.
Click to expand...
Click to collapse
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
I'm a happy user of VegaComb on my advent vega since version 1.7, really love the work of newbi5 and his staff!
But I was woundering, how 'legal' is VegaComb? Is it completly open source or does it use licensed parts? I understood that VegaComb "borrows" parts of codes from other tablet devices, because Android 3.2 is not officially released yet.
So wouldn't that make VegaComb an illegal software, because it uses pieces of codes that's offically owned by the tablet developer (Samsung/Acer/ect.)??
isn't this stuff based on floss? or have i got that wrong?? which means as high and mighty as google are they still have to accept the bds redistribution clause.
can't post outside links but wiki that..
I think it includes Google apps (gmail etc), as far as I remember Cyanogen got a C&D from Google for doing that, now they just offer them as a separate install to get around it
Honeycomb isn't open so not sure how legal it is
Since Honeycomb 3.2 is not open source, I think it's illegal to distribute vegacomb, because the used codes in the rom are partly owned by google and the tablet developer and they did not give permissionto use the code.....
.....or am I wrong?
3.2 was released as open source in July. Check out source dot android dot com.
--A
Andrew123456 said:
3.2 was released as open source in July. Check out source dot android dot com.
--A
Click to expand...
Click to collapse
That´s right, actually I posted that news a few months ago
that's not right:
http://source.android.com/source/build-numbers.html
For Honeycomb, the entire platform source code isn't available. However, the parts of Honeycomb licensed under the GPL and LGPL are available under the following tags:
Click to expand...
Click to collapse
Hi! We just released a bit of code we thought this group might be interested in.
Over at our Android Open-Source Project git servers, the source code
for Android version 4.0 (Ice Cream Sandwich) is now available.
Here's how to get it:Follow the instructions at
http://source.android.com/source/downloading.htmlCheck out the
'ics-release' branch:repo init -u
https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
That's it! However since this is a large push, please be aware that it
will take some time to complete. If you sync before it's done, you'll
get an incomplete copy that you won't be able to use, so please wait
for us to give the all-clear before you sync.
This is actually the source code for version 4.0.1 of Android, which
is the specific version that will ship on the Galaxy Nexus, the first
Android 4.0 device. In the source tree, you will find a device build
target named "full_maguro" that you can use to build a system image
for Galaxy Nexus. Build configurations for other devices will come
later.
Unfortunately we still don't have our Gerrit code review servers back
online. That remains our top priority though, and we hope to have them
back soon.
This release includes the full history of the Android source code
tree, which naturally includes all the source code for the Honeycomb
releases. However, since Honeycomb was a little incomplete, we want
everyone to focus on Ice Cream Sandwich. So, we haven't created any
tags that correspond to the Honeycomb releases (even though the
changes are present in the history.)
JBQ, on behalf of the AOSP team.
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Click to expand...
Click to collapse
http://groups.google.com/group/android-building/browse_thread/thread/4f85d9242667a85f
Just read this on AndroidPolice. Very excited!!!
Game.....on!
Sent from my PG86100 using XDA App
Developers make some rom's!!!!!! (Please)
this thread should make its way over to the development section. Thanks for the find op
Update: Already there
I'm actually curious about how long it will take for someone to make an A500 ICS ROM based on this. There is bound to be someone to do it, but who gets the #1 spot?
Whoever does it, it won't be soon. Build requirements are kinda steep...
https://groups.google.com/group/and...355d4256bdf4906?hl=en_US&lnk=gst&q=16gb&pli=1
They're not necessarily requirements, but more or less just recommendations. A more average computer could still compile ICS, but it will just take a lot longer. And I'm betting Thor will be the first to cook us a ROM. Hopefully soon
Sent from my HTC Glacier using xda premium
FloatingFatMan said:
Whoever does it, it won't be soon. Build requirements are kinda steep...
https://groups.google.com/group/and...355d4256bdf4906?hl=en_US&lnk=gst&q=16gb&pli=1
Click to expand...
Click to collapse
Those are only recommendations for developer workstations. It is certainly possible to compile it even on a low-grade office PC if you give it a week.
Hence my saying it won't be soon...
FloatingFatMan said:
Hence my saying it won't be soon...
Click to expand...
Click to collapse
Your still not understanding my friend. Unless your definition of soon is in 30 minutes. Peter Alfonso that develops for the OG Droid and a few other devices compiled his in about 1 hour and 45 minutes. That was a laptop core i7 and 8gb of ram.
Thats not whats going to be time consuming. The hard part will be finding/getting the hardware inside our devices to work. I asked THOR on his forum about ICS on the iconia, his response:
done know for now... depends how many proprietary stuff the a500 uses....
I'm worried the camera, sensors and battery as these seam to be tampered with...
for the moment I'm busy with other stuff will see when I get some time to sneak a peak at the code...
Click to expand...
Click to collapse
Time will tell.
I'm sure FFM understands that. As you say, the hard part is getting the hardware to work, but with a slower machine, how many test builds can you do in a day? With a big fast machine that can build in a few hours vs a laptop that might take a few days can make a huge difference of when you get to your final release.
But hey.. i don't know anything, so why don't I just shut up...
It takes about 3.5 hours for me to build a new version of ICS. I'm on a 3 year old laptop which is why it takes so long. It would be great to have a much newer machine to build with as it would help to make things go faster.
So I guess that Google engineer was taling out of his butt then.
Hi, a developer called pulser_g2 made this petition for Samsung to be more open and be a lot more developer friendly, this petition is for all Samsung android devices. So I thought I would post it here in the hope a few of you may consider singing it please
http://www.change.org/petitions/sam...t-achieve-full-potential-of-purchased-devices
Thank you
I don't see the point in signing this as SAMFIRMWARE already releases a bunch of firmwares for Samsung.
Sent from my GT-i9220 using Tapatalk
kotaro_14 said:
I don't see the point in signing this as SAMFIRMWARE already releases a bunch of firmwares for Samsung.
Sent from my GT-i9220 using Tapatalk
Click to expand...
Click to collapse
that's not what they're requesting
Samsung releases kernel sources but rest are not. This is the precise reason why CM crew is having trouble getting things like hardware codec support working like the stock rom
I think it's ok to demand full source to be released but i'm not sure if they can release the full source for things that they didn't produce (ie yamaha dac)
ph00ny said:
that's not what they're requesting
Samsung releases kernel sources but rest are not. This is the precise reason why CM crew is having trouble getting things like hardware codec support working like the stock rom
I think it's ok to demand full source to be released but i'm not sure if they can release the full source for things that they didn't produce (ie yamaha dac)
Click to expand...
Click to collapse
I agree - according to wikipedia the Android system is open source, so by definition all code should be available to all developers. I'm a bit of a noob to this, but my understanding is that as long as code is properly referenced, it can be re-used/improved etc.
Even something like sound and video drivers should be available to be used enhanced - it would make the system so much better. Voodoo Sound is a classic example of someone have to spend a heck of a lot of time tweaking and playing with a system until they find the right combination. How much better would our wonderful Note be if drivers, codecs and other fundamental kernel-related items were truly available to all?
Signed it
Sent from my GT-N7000 using xda premium