Hello, XDA. This is my first post.
Before I start out looking like I'm helpless, and keeping with the mindset that I don't expect something for nothing, I've spent the time to write up newbie-friendly guides:
(edit: Apparently, I have to make eight posts before I can post external links) I will probably accumulate eight posts in this thread, and will edit this at that point.)
Adding OpenVPN and liblzo to the AOSP source tree and compiling a kernel to support it. Includes instructions for patching OpenSSL1.0.0a to enable engine support.
Wrangling with USB permissions
Making a custom boot animation from an animated gif
If it would be better to have the content located on the forum somewhere, tell me where it ought to go.
My problem:
I am trying to roll my own ROM from AOSP (Gingerbread 2.3.4). I have been successfully building images and even kernels for the Nexus S for several weeks now. Recently, I broke something.
I've beat my head against this for three days now. I think I read the entire internet before posting here. I think there is a problem with my build tools, but I don't know where I should be looking for it, or how to test it. The problem is not in the AOSP source tree. I know this because I checked out a clean copy of it, followed Google's instructions, and I get the same result. I get the same result in both the emulator, and on the Nexus S.
When I launch the browser, this is the output from logcat:
(edit: Wow... the parser that tells me I can't post URLs is so aggressive, that I can't paste my logcat output either... I have base64 encoded it instead.)
Code:
SS9BY3Rpdml0eU1hbmFnZXIoICAgNjYpOiBTdGFydCBwcm9jIGNvbS5hbmRyb2lkLmJyb3dzZXIg
Zm9yIGFjdGl2aXR5IGNvbS5hbmRyb2lkLmJyb3dzZXIvLkJyb3dzZXJBY3Rpdml0eTogcGlkPTM1
NyB1aWQ9MTAwMjEgZ2lkcz17MzAwMywgMTAxNX0NCkkvQWN0aXZpdHlUaHJlYWQoICAzNTcpOiBQ
dWIgYnJvd3NlcjogY29tLmFuZHJvaWQuYnJvd3Nlci5Ccm93c2VyUHJvdmlkZXINCkkvQnJvd3Nl
clNldHRpbmdzKCAgMzU3KTogU2VsZWN0ZWQgc2VhcmNoIGVuZ2luZTogQWN0aXZpdHlTZWFyY2hF
bmdpbmV7YW5kcm9pZC5hcHAuU2VhcmNoYWJsZUluZm9ANDA1OTU4Yzh9DQpEL2RhbHZpa3ZtKCAg
MzU3KTogR0NfQ09OQ1VSUkVOVCBmcmVlZCA0NTZLLCA1MSUgZnJlZSAyOTE0Sy81ODMxSywgZXh0
ZXJuYWwgOTM0Sy8xMDM4SywgcGF1c2VkIDVtcyszbXMNClcvZGFsdmlrdm0oICAzNTcpOiBObyBp
bXBsZW1lbnRhdGlvbiBmb3VuZCBmb3IgbmF0aXZlIExhbmRyb2lkL3dlYmtpdC9KV2ViQ29yZUph
dmFCcmlkZ2U7Lm5hdGl2ZUNvbnN0cnVjdG9yICgpVg0KVy9kYWx2aWt2bSggIDM1Nyk6IHRocmVh
ZGlkPTExOiB0aHJlYWQgZXhpdGluZyB3aXRoIHVuY2F1Z2h0IGV4Y2VwdGlvbiAoZ3JvdXA9MHg0
MDAxNTU2MCkNCkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiBGQVRBTCBFWENFUFRJT046IFdlYlZp
ZXdDb3JlVGhyZWFkDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3KTogamF2YS5sYW5nLlVuc2F0aXNm
aWVkTGlua0Vycm9yOiBuYXRpdmVDb25zdHJ1Y3Rvcg0KRS9BbmRyb2lkUnVudGltZSggIDM1Nyk6
IAlhdCBhbmRyb2lkLndlYmtpdC5KV2ViQ29yZUphdmFCcmlkZ2UubmF0aXZlQ29uc3RydWN0b3Io
TmF0aXZlIE1ldGhvZCkNCkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJr
aXQuSldlYkNvcmVKYXZhQnJpZGdlLjxpbml0PihKV2ViQ29yZUphdmFCcmlkZ2UuamF2YTo2MCkN
CkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJraXQuQnJvd3NlckZyYW1l
Ljxpbml0PihCcm93c2VyRnJhbWUuamF2YToxOTIpDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3KTog
CWF0IGFuZHJvaWQud2Via2l0LldlYlZpZXdDb3JlLmluaXRpYWxpemUoV2ViVmlld0NvcmUuamF2
YToxOTApDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3KTogCWF0IGFuZHJvaWQud2Via2l0LldlYlZp
ZXdDb3JlLmFjY2VzcyQ1MDAoV2ViVmlld0NvcmUuamF2YTo1MykNCkUvQW5kcm9pZFJ1bnRpbWUo
ICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJraXQuV2ViVmlld0NvcmUkV2ViQ29yZVRocmVhZCQxLmhh
bmRsZU1lc3NhZ2UoV2ViVmlld0NvcmUuamF2YTo2MTQpDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3
KTogCWF0IGFuZHJvaWQub3MuSGFuZGxlci5kaXNwYXRjaE1lc3NhZ2UoSGFuZGxlci5qYXZhOjk5
KQ0KRS9BbmRyb2lkUnVudGltZSggIDM1Nyk6IAlhdCBhbmRyb2lkLm9zLkxvb3Blci5sb29wKExv
b3Blci5qYXZhOjEzMCkNCkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJr
aXQuV2ViVmlld0NvcmUkV2ViQ29yZVRocmVhZC5ydW4oV2ViVmlld0NvcmUuamF2YTo2MzMpDQpF
L0FuZHJvaWRSdW50aW1lKCAgMzU3KTogCWF0IGphdmEubGFuZy5UaHJlYWQucnVuKFRocmVhZC5q
YXZhOjEwMTkpDQpXL0FjdGl2aXR5TWFuYWdlciggICA2Nik6ICAgRm9yY2UgZmluaXNoaW5nIGFj
dGl2aXR5IGNvbS5hbmRyb2lkLmJyb3dzZXIvLkJyb3dzZXJBY3Rpdml0eQ0KVy9kYWx2aWt2bSgg
IDM1Nyk6IE5vIGltcGxlbWVudGF0aW9uIGZvdW5kIGZvciBuYXRpdmUgTGFuZHJvaWQvd2Via2l0
L1dlYlZpZXc7Lm5hdGl2ZU1vdmVHZW5lcmF0aW9uICgpSQ0KRC9BbmRyb2lkUnVudGltZSggIDM1
Nyk6IFNodXR0aW5nIGRvd24gVk0NClcvZGFsdmlrdm0oICAzNTcpOiB0aHJlYWRpZD0xOiB0aHJl
YWQgZXhpdGluZyB3aXRoIHVuY2F1Z2h0IGV4Y2VwdGlvbiAoZ3JvdXA9MHg0MDAxNTU2MCkNCkkv
UHJvY2VzcyAoICAzNTcpOiBTZW5kaW5nIHNpZ25hbC4gUElEOiAzNTcgU0lHOiA5
At first, I thought maybe it was some setting specific to the browser. But then I tried another application that also calls native libraries (CSIPSimple). Whenever CSIP tries to load native libraries, I see something like this:
Code:
RC9kYWx2aWt2bSggIDQyOCk6IFRyeWluZyB0byBsb2FkIGxpYiAvZGF0YS9kYXRhL2NvbS5jc2lw
c2ltcGxlL2xpYi9saWJwanNpcGpuaS5zbyAweDQwNTEzNDg4DQpFL1BqU2VydmljZSggIDQyOCk6
IFdlIGhhdmUgYSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgc3RhY2suLi4uIE5PVCBZRVQgSW1w
bGVtZW50ZWQNCkUvUGpTZXJ2aWNlKCAgNDI4KTogamF2YS5sYW5nLlVuc2F0aXNmaWVkTGlua0Vy
cm9yOiBDYW5ub3QgbG9hZCBsaWJyYXJ5OiByZWxvY19saWJyYXJ5WzEzMTVdOiAgICAzMiBjYW5u
b3QgbG9jYXRlICdfX2Rzb19oYW5kbGUnLi4uDQpFL1BqU2VydmljZSggIDQyOCk6IA0KRS9QalNl
cnZpY2UoICA0MjgpOiAJYXQgamF2YS5sYW5nLlJ1bnRpbWUubG9hZChSdW50aW1lLmphdmE6Mzk0
KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgamF2YS5sYW5nLlN5c3RlbS5sb2FkKFN5c3RlbS5q
YXZhOjUzNCkNCkUvUGpTZXJ2aWNlKCAgNDI4KTogCWF0IGNvbS5jc2lwc2ltcGxlLnBqc2lwLlBq
U2lwU2VydmljZS50cnlUb0xvYWRTdGFjayhQalNpcFNlcnZpY2UuamF2YToxMTkpDQpFL1BqU2Vy
dmljZSggIDQyOCk6IAlhdCBjb20uY3NpcHNpbXBsZS5zZXJ2aWNlLlNpcFNlcnZpY2UubG9hZFN0
YWNrKFNpcFNlcnZpY2UuamF2YTo5MTMpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBjb20uY3Np
cHNpbXBsZS5zZXJ2aWNlLlNpcFNlcnZpY2Uub25TdGFydChTaXBTZXJ2aWNlLmphdmE6ODczKQ0K
RS9QalNlcnZpY2UoICA0MjgpOiAJYXQgYW5kcm9pZC5hcHAuU2VydmljZS5vblN0YXJ0Q29tbWFu
ZChTZXJ2aWNlLmphdmE6NDI4KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgYW5kcm9pZC5hcHAu
QWN0aXZpdHlUaHJlYWQuaGFuZGxlU2VydmljZUFyZ3MoQWN0aXZpdHlUaHJlYWQuamF2YToyMDM5
KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgYW5kcm9pZC5hcHAuQWN0aXZpdHlUaHJlYWQuYWNj
ZXNzJDI4MDAoQWN0aXZpdHlUaHJlYWQuamF2YToxMTcpDQpFL1BqU2VydmljZSggIDQyOCk6IAlh
dCBhbmRyb2lkLmFwcC5BY3Rpdml0eVRocmVhZCRILmhhbmRsZU1lc3NhZ2UoQWN0aXZpdHlUaHJl
YWQuamF2YTo5OTQpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBhbmRyb2lkLm9zLkhhbmRsZXIu
ZGlzcGF0Y2hNZXNzYWdlKEhhbmRsZXIuamF2YTo5OSkNCkUvUGpTZXJ2aWNlKCAgNDI4KTogCWF0
IGFuZHJvaWQub3MuTG9vcGVyLmxvb3AoTG9vcGVyLmphdmE6MTMwKQ0KRS9QalNlcnZpY2UoICA0
MjgpOiAJYXQgYW5kcm9pZC5hcHAuQWN0aXZpdHlUaHJlYWQubWFpbihBY3Rpdml0eVRocmVhZC5q
YXZhOjM2ODMpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBqYXZhLmxhbmcucmVmbGVjdC5NZXRo
b2QuaW52b2tlTmF0aXZlKE5hdGl2ZSBNZXRob2QpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBq
YXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52b2tlKE1ldGhvZC5qYXZhOjUwNykNCkUvUGpTZXJ2
aWNlKCAgNDI4KTogCWF0IGNvbS5hbmRyb2lkLmludGVybmFsLm9zLlp5Z290ZUluaXQkTWV0aG9k
QW5kQXJnc0NhbGxlci5ydW4oWnlnb3RlSW5pdC5qYXZhOjgzOSkNCkUvUGpTZXJ2aWNlKCAgNDI4
KTogCWF0IGNvbS5hbmRyb2lkLmludGVybmFsLm9zLlp5Z290ZUluaXQubWFpbihaeWdvdGVJbml0
LmphdmE6NTk3KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgZGFsdmlrLnN5c3RlbS5OYXRpdmVT
dGFydC5tYWluKE5hdGl2ZSBNZXRob2Qp
Are there any veteran android devs that can point me in the correct general direction? I don't need to have my hand held, but having never written any app more complex than HelloWorld, I'm not sure where to begin debugging.
edit: As long as I'm thwarting the parser with Base64, here are the external links I am not supposed to be able to post. I hope it helps someone. Figuring all that out was a lot of work.
Code:
W0xJU1RdDQpbKl1bVVJMPSJodHRwOi8vd3d3Lmpvc2hpYW5saW5kc2F5LmNvbS9pbmRleC5waHA/
aWQ9MTEzIl1BZGRpbmcgT3BlblZQTiBhbmQgbGlibHpvIHRvIHRoZSBBT1NQIHNvdXJjZSB0cmVl
IGFuZCBjb21waWxpbmcgYSBrZXJuZWwgdG8gc3VwcG9ydCBpdC4gSW5jbHVkZXMgaW5zdHJ1Y3Rp
b25zIGZvciBwYXRjaGluZyBPcGVuU1NMMS4wLjBhIHRvIGVuYWJsZSBlbmdpbmUgc3VwcG9ydC5b
L1VSTF0NClsqXVtVUkw9Imh0dHA6Ly93d3cuam9zaGlhbmxpbmRzYXkuY29tL2luZGV4LnBocD9p
ZD0xMTIiXVdyYW5nbGluZyB3aXRoIFVTQiBwZXJtaXNzaW9uc1svVVJMXQ0KWypdW1VSTD0iaHR0
cDovL3d3dy5qb3NoaWFubGluZHNheS5jb20vaW5kZXgucGhwP2lkPTExMSJdTWFraW5nIGEgY3Vz
dG9tIGJvb3QgYW5pbWF0aW9uIGZyb20gYW4gYW5pbWF0ZWQgZ2lmWy9VUkxdDQpbL0xJU1Rd
Thanks in advance for any help you are willing to give.
So, I've been at this for about 48 hours now (not continuously, but closer than you might think) and I figured I should take a break from modifying project files and puzzling over alignment issues to discuss the project, share some of the problems I've been having and ask if anybody can help, and so on.
The general idea is "Chromium build for Windows (on x86/x64) and build on ARM (for Linux), so there must be a way to build it for Windows on ARM". For the most part, that even looks like it's true. Probably at least 80% of 654 Visual Studio projects (no, that's not a joke) either build just fine with only minor amounts of work, or are things that we don't actually need (I'll try building the test suites... once everything else builds!!)
Areas that have given me problems (caution: some chance of brief rants ahead):
v8. Less than you might think, though. Setting the flags for Arm seems to have been enough.
Sandbox. There's a fair bit of thunking coded in assembly going on in the sandbox for x86. Not sure what's up with it (I don't know exactly how the Chromium sandbox works) but it'll have to come out or be replaced. The Linux (including ARM) sandbox seems to be SELinux-based, which doesn't help at all.
Native Client (NaCl). I think all the assembly is in test code, though, so I may just boldly #ifdef if all away.
libjpg-turbo (libjpg). Piles of carefully optimized assembly... for x86 and x64. There is a set of ARM assembly (for Linux) that Visual Studio won't compile, but something else might... or I may tweak until it works. Of course, I could also just accept the speed hit and use the version of libjpg implemented in nice, portable C.
Anything where the developers tried to use some SSE to speed things up. I may be able to replace it with NEON code, or I may just remove it and hope **** doesn't break. We'll see.
Inline assembly in general. Even when it's ARM assembly, Visual Studio / CL.exe don't want anything to do with it (__asm is apparently now an invalid keyword). I suspect I'll have to just pull the assembly out into stand-alone functions in their own files, then compile them to object files and link them back in later. If I can figure out the best way to do this (for example, I'll want to inline the asm functions) then it shouldn't impact performance. Seriously though, I kind of hate inline assembly. I can read assembly just fine, but I'm usually staring at it in a debugger or disassembly tool, not in the middle of source code I'm trying to build...
Everywhere that the current state of the CPU is cared about (exception and crash handlers, in particular) because the CONTEXT structure is, of course, CPU-specific. They're pretty easy to get past, though.
Low-level functions, like MemoryBarrier. Fortunately, it's implemented in ntdll.h... but as a macro, which breaks at least half the places it's referenced. Solution: where it breaks things, undefine the macro and just have it be an inline function that does what the macro did.
Running out of memory. Not even joking... well, OK, a little bit. I've got 32GB; I won't actually run out. Both Visual Studio and cl.exe do at times, though!. Task Manager says VS is currently using 1,928 MB, and before I restarted it, it broke 2.5GB private working set. Pretty good for a program that for some reason is still 32-bit...
Goddamn compiler flags. Seriously, every single project (I mentioned there are over 600, right?) has its LIBPATHs hardcoded to point at x86. Several projects have /D:_X86_ or similar (that's supposed to be set by the build tools, not the user, you idiots...) which plays merry hell with the #ifdef guards. Everything has /SAFESEH specified, not in the actual property table where the IDE could have removed it (unneeded and invlaid on ARM) but in the "extra stuff we'll pass on the build command line" field, which means every single .EXE/.DLL project must be modified or the linker will fail.
My current biggest goal is the JPG library; nobody wants to use a browser without it. After that, I'll tackle the sandbox, leaving NaCl for last... well, last before whatever else crops up.
Anyhow, thoughts/comments/advice are welcome... in the mean time, I'm going to go eat something (for the first time in ~22 hours) and then get some sleep.
Kudos for having the patience to look though this monster.
It's my understanding that NaCl is still a pretty niche thing at the moment. Is it possible to easily either disable it or completely hack it out, or do other more critical parts of Chromium now depend on it?
I don't think anything truly depends on it. I'll look in the VS dependency hierarchy and see how many things list it, and how awful it would be to remove them.. after I get the other stuff working. I may pass on the sandbox as well, if possible; it makes the security guy in me cringe something awful, but as they say, shipping is a feature..
great
Please make that happen !
Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.
It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).
GoodDayToDie said:
Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.
It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).
Click to expand...
Click to collapse
I thinkt tht is a mutch better taktic and mutch less frustrading.
I would love to see just a minimal version of it. After that all the small componens can follow.
50 of 400 is pretty good i think. Better then i expected
Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.
GoodDayToDie said:
Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.
Click to expand...
Click to collapse
the v8 engine ( used in nodejs ) has been ported to ARM :
I still can't link : htt p://ww w.it-wars.com/article305/compiler-node-js-pour-arm-v5
perhaps it will help you
Edit : oups, I just see that another great user of this forum made the port of nodejs to RT
Yep... but they did it without v8. That's not an encouraging result, but I feel like I'm so close...
Is there a GitHub repo so we can help or track the progress of the project ?
Sorry, not at present. There probably should be. The sheer size of the codebase is incredible (about 2.4GB) and having some way to share it practically would be good.
Also, I suspect this would go a lot faster if I don't have to repeat the work of others. I know that there's a working Webkit DLL out there, for example (though with several features, including the V8 JS engine, missing) and if I could get my hands on that it would drastically reduce the number of additional components I need to build. Currently I'm working on the sandbux, but expect that I will need to rip the whole thing out and basically have the browser run as though it was always passed the --no-sandbox parameter, at least for the first build. Too damn much assembly.
http://www.engadget.com/2013/01/22/google-chrome-native-client-arm-support/
This wouldn't have any impact on this project, would it?
Sent from my SCH-I535 using xda-developers app, complete with annoying signatures.
It probably means that NaCl on Windows RT will be possible in the future. At present, I'm cutting it out of the build - too much x86-specific stuff there to port it over myself, and it owuldn't be able to run x86-compiled NaCl code anyhow.
You might have bit off more than you could chew. It'd better if you put your current progress under version control on some public site so that other people may be able to help you.
It's a big and complex project. You are taking a lot of time, and understandably so. But just open up to other people and you could get this done faster.
Yeah, this is probably true. My life also got unexpectedly *busy* in the last week; a couple weeks ago I had many times as much free time as I do now, and so porting has slowed down.
My upload speed would take ages (literally probably at least a day of solid activity; it's embarassingly slow) to push the full source anywhere, but I may make the effort anyhow. I'll have to post it somewhere for GPL compliance in any case...
You may upload only the diff files, they'll probably be smaller then the whole distribution.
Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.
I don't see the point of this.
I have personally jumped from IE8 > FF > Chrome and finally back to IE10 over the years depends on its usability, smoothness, speed, etc
Speed isn't the only reason to use a browser. I actually prefer IE myself, but there are some things that other browsers do better than it (in the case of Chrome, parts of HTML5, the syncing across Google services, etc.) Also, Chrome gets updated far more often than IE; IE9 was equal with Chrome on speed at its release, and was far behind by the time IE10 came out.
The reason for this project, though, is a mixture of interest in what it takes, and a desire to benefit the community. Microsoft has deeped that only software which they have blessed may run on the Windows RT desktop. I disagree, and have chosen (among several other things) to port a web browser because I feel that it's important for users to have choice.
LastBattle said:
Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.
I don't see the point of this.
Click to expand...
Click to collapse
Some websites do not get along with the trident rendering engine. Some webdevs are so "Oh f*** IE I don't care" and block access to features just because it is IE. I have experienced this first hand on IE10 on my surface where it tells me to come back when I have a decent browser, only to not have the choice to do that.
This really isn't the webdevs fault either, for years IE was the scum of the internet, only recently has IE caught up to the rest of the browsers (and in my opinion exceeded some) but the years of IE being bad have left a lot of disjointed webdevs who won't even consider giving the latest IE a chance.
Has anyone played with the Si4709 chip in a SPH-L900?
I've read plenty of stuff saying that the us variants don't have the hardware, but I thought I'd check for myself.
I built a kernel with support for the chip (using ashton seo of samsung's driver) and loaded up the module.
The driver is only documented in the code comments, so I tried Spirit just to see if it'd pick up on it, but Spirit reboots the phone when started. Sooo... I tried just turning on the chip in FM receive mode, which didn't result in a reboot.
I went over to sysfs and poked through the related twiddles (which there are a bunch of) and didn't come up with anything useful (most things were full of zeroes).
Anyone have any experience with it? Anyone have some sample code that works with the Si4709?
I guess it could be that the phone really doesn't have the hardware, but I'm not sure how to tell at this point.
The Spirit author (who presumably knows all about this stuff) does say in his Spirit thread that this phone lacks hardware, so maybe I should defer to that wisdom, unless someone has an idea as to how we can verify that the hardware is or is not there.
Edit: Here is a kernel with si47xx support if anyone wants to have a go. It's built as a module, so modprobe Si4709_driver to load 'er up.
The phone doesn't have the chip, you're wasting your time here.
Link doesn't let me access the files