Related
Hi!
My Hero has had problems with the trackball not working for a couple of months but I haven't been bothered by it since I never use it. Lately however, the trackball (or it's sensors on the board) seems to have gotten a life of it's own. It's constantly scrolling upwards making it impossible to navigate in menus and send text messages.
I've read many many threads about people wanting to completely disable the trackball but noone seems to have any idea on how. I've also tried cleaning. If anyone knows about a solution to make the trackball not load when the basic IO functions loads I would be very happy indeed. The problem is not ROM specific since the scrolling occurs in the recovery menu as well.
If it's not possible to "deactivate" it I'm curious if you think it would be possible to write a tiny little background app that listens for the trackballs MotionEvent, catches it, does nothing and then returns true as if the handler in the background app took care of all the work and thus overrides the scrolling that would happend in the browser, menu or whichever context you are in?
The method I've been looking at is: public boolean onTrackballEvent (MotionEvent event)
What do you think?
span_01 said:
Hi!
My Hero has had problems with the trackball not working for a couple of months but I haven't been bothered by it since I never use it. Lately however, the trackball (or it's sensors on the board) seems to have gotten a life of it's own. It's constantly scrolling upwards making it impossible to navigate in menus and send text messages.
I've read many many threads about people wanting to completely disable the trackball but noone seems to have any idea on how. I've also tried cleaning. If anyone knows about a solution to make the trackball not load when the basic IO functions loads I would be very happy indeed. The problem is not ROM specific since the scrolling occurs in the recovery menu as well.
If it's not possible to "deactivate" it I'm curious if you think it would be possible to write a tiny little background app that listens for the trackballs MotionEvent, catches it, does nothing and then returns true as if the handler in the background app took care of all the work and thus overrides the scrolling that would happend in the browser, menu or whichever context you are in?
The method I've been looking at is: public boolean onTrackballEvent (MotionEvent event)
What do you think?
Click to expand...
Click to collapse
Maybe its just too much kernel compiling talking, but I would just kill it the kernel level - sounds easiest to me
Let me know if you want me to look into this, and nag me if I forgot....
Killing this at kernel level would be fantastic if its possible. You would be more than welcome to have a look at this.
I have no knowledge of where to start looking since I know very little about any kernel. I am very interested in learning more though so if you do not have time at the moment I would be very glad if you could provide some pointer on where to start looking.
This would be amazing if possible, my guess would be the kernel too.
I was using all the time at first, but now it's more of a hassle than anything else.
span_01 said:
Killing this at kernel level would be fantastic if its possible. You would be more than welcome to have a look at this.
I have no knowledge of where to start looking since I know very little about any kernel. I am very interested in learning more though so if you do not have time at the moment I would be very glad if you could provide some pointer on where to start looking.
Click to expand...
Click to collapse
Ok, I'll try to get around to it in the next couple of days, bump this or even PM me if I forget.
In the meantime if you want to get your hands dirty in kernel code, heres the section about "my" sources from my flykernel post:
erasmux said:
Kernel Sources
My sources with all my updates and changes are found on github:
http://github.com/erasmux/hero-2.6.29-flykernel
Use hero_defconfig for the regular version and hero-bfs_defconfig for the BFS version.
See the wiki for more information about building the kernel. Another great resource about kernel building is the cyanogen wiki - do note that currently the CM kernel will not work on the hero.
Please feel free to contact me regarding my sources and kernel development.
Click to expand...
Click to collapse
erasmux said:
Ok, I'll try to get around to it in the next couple of days, bump this or even PM me if I forget.
In the meantime if you want to get your hands dirty in kernel code, heres the section about "my" sources from my flykernel post:
Click to expand...
Click to collapse
Thank-you kernel king! Will have to put on some gloves and dig around the source this weekend!
Sent from my HTC Hero using XDA App
Any luck yet?
Nope, not yet. I have not had much time to look into this. Being a complete novice it will probably take me some time
Sent from my HTC Hero using XDA App
I've now found a solution to this that I'm testing out. I've recompiled FlyKernel with a small customisation and it seems stable enough. PM me if you want to see the change or need a flashable zip.
The first non-Samsung ROM for the SGS2! This is 100% stock AOSP from Google.
What works:
- It boots up.
- Stock launcher.
- OpenGL
- Vibration
- Phone Radio (Incl SMS)
- Internal Storage / SD Card
What doesn't work:
- Wifi, Bluetooth
- Sound.
- Cameras.
- Sensors.
This is at least a proof of concept of how AOSP can work on the SGS2.
Installation:
Warning: Don't do this unless you know how to use Odin or have time to learn. You won't be able to make phone calls until you flash back a Samsung firmware!
Also, this is a custom kernel, so you will have the yellow ! on your device after flashing this (same as root).
All of your data will be lost - backup first!
Download the .7z file from http://www.mobile-dev.co.za/I9100_AOSP_V2.7z
Unzip using 7zip or similar.
Flash the .tar file with Odin:
- Default settings, touch nothing
- Load I9100_AOSP_V2.tar as PDA
Put phone into download mode (Voldown+Home+Power after turning off device), connect with USB, press Start.
The device should then boot up into AOSP. When finished playing around, flash back a stock Samsung firmware (from http://www.samfirmware.com/ or other). You may need to go into recovery mode to use the 'format data' option. (Volup+Home+Power)
If you have fun with this, feel free to donate - https://www.paypal.com/cgi-bin/webs...=PP-DonationsBF:btn_donateCC_LG.gif:NonHosted
If you want to help out with porting, give me a shout! We could form up some kind of SGS2-AOSP team.
Swweeeeeeeet love aosp and seeing one for my loved phone makes me hyperventilate
Sent from my GT-I9100 using XDA App
Did you try to use the stock kernel with the AOSP build? You may get lucky and get some radios/hardware working.
Interesting... Did you manage this with Samsung's little bit of "platform" sources they give?
I'm around, though not that good with AOSP tbh... I still prefer to take a binary and hack it, than to compile from sources
Just gonna set up an AOSP tree on my server and have a play
uskr said:
Did you try to use the stock kernel with the AOSP build? You may get lucky and get some radios/hardware working.
Click to expand...
Click to collapse
Just needs a little tinkering in the init.rc, probably. This version is 100% AOSP, except for mounting the partitions using EXT4 instead of yaffs2 (obvious reasons). So this is a "no samsung code at all" ROM.
Little bit of tweaking should have wifi working without much trouble - no idea about the rest. Not really sure why I'm the first one trying this, to be honest!
RyanZA said:
Just needs a little tinkering in the init.rc, probably. This version is 100% AOSP, except for mounting the partitions using EXT4 instead of yaffs2 (obvious reasons). So this is a "no samsung code at all" ROM.
Little bit of tweaking should have wifi working without much trouble - no idea about the rest. Not really sure why I'm the first one trying this, to be honest!
Click to expand...
Click to collapse
Yeah, it was on my "to do" list for the upcoming week... I've got last exam tomorrow, then time to get the SGS2 on the go There's other stuff I need to get going first though...
this is great start. wait for fully working version!
pulser_g2 said:
Interesting... Did you manage this with Samsung's little bit of "platform" sources they give?
I'm around, though not that good with AOSP tbh... I still prefer to take a binary and hack it, than to compile from sources
Just gonna set up an AOSP tree on my server and have a play
Click to expand...
Click to collapse
Nope - 100% AOSP code. It's all just userland, after all. The Samsung "platform" sources are just the changes they made to GPL software, I guess?
And yeah, that was the point of this - for some reason I was seeing nobody playing with AOSP/CM - this will hopefully get more people involved.
Wow, nice! Are you going to continue developing this ROM or was it just made as a proof of concept?
RyanZA said:
What works:
- It boots up.
- Stock launcher.
- OpenGL
What doesn't work:
- All radios (wifi, phone, everything).
- Sound, Vibration.
- Cameras.
- Sensors.
Click to expand...
Click to collapse
Yes! is Useless
I'm so happy to see RyanZA back lol
Do miracles like you did on SGS
Nice work RyanZA !
Great work, I'm looking forward to a fully functional rom, I used to love Oxygen on the Desire.
Sent from my GT-I9100 using XDA App
Great! I have been waiting for this since I got the phone. I just love the clean stock Android. Really looking forward stable aosp roms!
I can't wait to have it fully working !!!
Great job !
@ryanza
Question about root. Are you also working on a z4root for sgs2? Nie to see you again in sgs forum
Sent from my GT-P7100 using XDA App
danikristijan said:
@ryanza
Question about root. Are you also working on a z4root for sgs2? Nie to see you again in sgs forum
Sent from my GT-P7100 using XDA App
Click to expand...
Click to collapse
No known exploits for the SGS2 yet, so not right now...
Security researchers have found some though, but nobody is disclosing any right now.
Progress on getting the radios working:
Nice big error about RILD, etc. The radio seems to be very different from the SGS1 (or any other hardware I know of...) If anybody has any ideas...? Otherwise, will have to try reverse engineer it or something? I hope not!
RyanZA said:
No known exploits for the SGS2 yet, so not right now...
Security researchers have found some though, but nobody is disclosing any right now.
Progress on getting the radios working:
Nice big error about RILD, etc. The radio seems to be very different from the SGS1 (or any other hardware I know of...) If anybody has any ideas...? Otherwise, will have to try reverse engineer it or something? I hope not!
Click to expand...
Click to collapse
I noticed that the rild binary is very different to the one that you end up with if you built it. Have you tried using the stock rild binary and even libril.so?
Also, would it be too much to ask that you show us your vendor overlay (the boarconfig, device and other mk files)?
Thanks.
focamonca said:
Yes! is Useless
Click to expand...
Click to collapse
NO! in fact its very USEFUL!
REALY LOOKING FORWARD TO AWSOME AOSP/CM ROMS SOON
Is there battery drain?
hi guys,
i just wanted to ask have anyone tried receiving calls from another phone in your gp5? i was just wondering i have a hp touchpad with webos and when its paired with my old phone it can receive the calls.
I was thinkin maybe if i can do that with my gp5 i can tuck away my old phone and receive calls with my gp5 when paired using bluetooth.
please let me know if anybody have any idea how get this done i know it requires certain service to enable this feature with bluetooth
The 4.0 and 5.0 do NOT support the bluetooth profile (HFP) Needed to be able to answer the calls of a paired bluetooth phone, the 3.6 does and I think the 4.2 might I just can't remember right now.
You could check out the custom ROM's for the 5.0 one of them may have added that functionality, but stock they will not.
4.2 does works like a charm. Just like my tp
Sent from my YP-GI1 using XDA
Well, it is unreal to answer a call? if you have not a dial, isn't it? So, galaxy player 4 and 5 HAVE NOT a dial (a phone app), maybe, in some custom ROMs... And they also have not (HFP) and you could not use them as hands-free...
server60 said:
Well, it is unreal to answer a call? if you have not a dial, isn't it? So, galaxy player 4 and 5 HAVE NOT a dial (a phone app), maybe, in some custom ROMs... And they also have not (HFP) and you could not use them as hands-free...
Click to expand...
Click to collapse
No, they have a dailer, they lack support of the needed bluetooth profiles, It was one of those weird things samsung did.
attn: ICS and custom roms user
any body running custom ics roms here? please feedback i need this badly it really sucks limiting the potential of this device i agree this might just be be something samsung disabled and might just work with custom roms with full functionality
aben.dc said:
any body running custom ics roms here? please feedback i need this badly it really sucks limiting the potential of this device i agree this might just be be something samsung disabled and might just work with custom roms with full functionality
Click to expand...
Click to collapse
Unlikely to see it in any of the CM9 based ICS releases as bluetooth doesn't even work in most of them.
Right. Calling custom fw users based on gingerbread kindly check if this feature exist on your gp5..thanks
Sent from my YP-G70 using XDA
i found a thread in htc flyer to enable hands free profile
http://forum.xda-developers.com/showthread.php?t=1185688
Using root explorer or your favorite text editor edit the build.prop file under /system/build.prop and edit the following lines:
Code:
ro.ril.reject.cs.ss.enabled=0
ro.ril.reject.mo.ussd.enabled=0
ro.phone.function=1
To enable Bt Headset profile change the following:
Code:
ro.bt.profiles = 4270403
service.brcm.bt.ag_supported = 1
Click to expand...
Click to collapse
thinking it might work with sgp 5.0 i tried opening my build.prop and cant find any lines like above
sadly it seems like nobody is after this feature but me
edit: added build.prop file and renamed to .txt
I'm very much interested in this feature and i'm sure there are people out there who care about it as well. I really would love to be able to use GP5 with my 10' tablet to answer and make calls though it.
aben.dc said:
i found a thread in htc flyer to enable hands free profile
http://forum.xda-developers.com/showthread.php?t=1185688
thinking it might work with sgp 5.0 i tried opening my build.prop and cant find any lines like above
sadly it seems like nobody is after this feature but me
edit: added build.prop file and renamed to .txt
Click to expand...
Click to collapse
I would love this feature! So did adding those lines to build.prop do anything?
Sent using Tapatalk
Okay, I tried adding the line in my build.prop, but it still fails to connect. Not surprised, but disappointed all the same.
Sent using Tapatalk
Thanks for trying. I got an idea based on the previous posts the 3.6 player has this feature I was wondering if the 3.6 has the identical chipset as ours provided that the its coming from the same rom version we can dump some of their core files that is controlling the bt chipset and port it to our device
Sent from my YP-G70 using xda app-developers app
i'm planning to post a request in the development forum, asking the developers to incorporate this feature into one of the rooms
I already asked the 4.0 devs. What we need is a 3.6 dump, so we can get what files we need.
Sent using Tapatalk
a dump? arent official roms available for download? why can't the necessary code be taken from a rom?
both 4.2 and 3.6 have this feature enabled, so it can be imported from any of these devices. I think it should be trivial - because the devices use the same components, adopting features from one into another should be almost as easy as cutting and pasting the code or a library or whatever they have in android.
Hi guys, since my 3.6 isn't rooted I'm not sure I can dump every file, but I can extract the ones which I have read access. You can also download all the source here
Mars11_ said:
Hi guys, since my 3.6 isn't rooted I'm not sure I can dump every file, but I can extract the ones which I have read access. You can also download all the source here
Click to expand...
Click to collapse
Wow, thanks for the link, mate. I will forward you offer to the devs. Btw i've started a new thread dedicated to this in the development section -> http://forum.xda-developers.com/showthread.php?t=1763496
double post
This is for developers only. No builds will be posted in this thread.
https://github.com/CM10DNA
Any valid development related discussion can be posted here. Please no posts that aren't directly related to development (i.e. comments, thanks, etc.).
I thought I would share an update on how this very experimental code-base is doing.
The code is running again (much of yesterday it was crashing on startup).
I have been running dirty flashing from my CM 10.1 build. It seems like that was safe to do so. I tried doing a clean flash this morning but sadly, my clean flash seems to have broken cell service. No phone or data. Restoring my cm 10.1 backup of data to the same install fixed it. Strange. (This included the change pushed this morning that updates the version of the apns file).
Superuser is now working but may be a little flaky. For example, on my clean install Titanium Backup couldn't acquire root access until after I rebooted.
Camera is still not working. It says "failed to connect to camera". I haven't looked at it at all, but there is a massive commit in the M7 kernel pulling source from the HTC One Google Edition for the camera.
Overall, I'm finding it's either completely broken or working very well. I think that the cellular network issue is going to get resolved upstream. I am afraid that we might be on our own for the camera.
crpalmer said:
I thought I would share an update on how this very experimental code-base is doing.
The code is running again (much of yesterday it was crashing on startup).
I have been running dirty flashing from my CM 10.1 build. It seems like that was safe to do so. I tried doing a clean flash this morning but sadly, my clean flash seems to have broken cell service. No phone or data. Restoring my cm 10.1 backup of data to the same install fixed it. Strange. (This included the change pushed this morning that updates the version of the apns file).
Superuser is now working but may be a little flaky. For example, on my clean install Titanium Backup couldn't acquire root access until after I rebooted.
Camera is still not working. It says "failed to connect to camera". I haven't looked at it at all, but there is a massive commit in the M7 kernel pulling source from the HTC One Google Edition for the camera.
Overall, I'm finding it's either completely broken or working very well. I think that the cellular network issue is going to get resolved upstream. I am afraid that we might be on our own for the camera.
Click to expand...
Click to collapse
https://github.com/CyanogenMod/andr...mmit/ec27077d6497c66f52488126ef6b181ef3fbed0d
seems cm has stopped camera building throughout probably prepping for the focal merge
edit: idk if m7 has cam working but it hasn't been detected as a bug
"Current bugs (they are known):
SMS sending will not work (receiving works)
Dialer sub-submenu FC's the dialer
Keyboard FC's when gesture swiping"
Not sure how much this helps. But the m7 kernel recently got its camera code updated with the Google edition. http://review.cyanogenmod.org/#/c/46164/
With that so. They are able to use the 4.2 libs http://review.cyanogenmod.org/#/c/46299/
Flyhalf205 said:
Not sure how much this helps. But the m7 kernel recently got its camera code updated with the Google edition. http://review.cyanogenmod.org/#/c/46164/
With that so. They are able to use the 4.2 libs http://review.cyanogenmod.org/#/c/46299/
Click to expand...
Click to collapse
we'd probably have to merge their whole drivers/media/video/msm and use their camera binaries at least that's how it works with sense if you want to use their 4.2.2 cam libs
JoelZ9614 said:
we'd probably have to merge their whole drivers/media/video/msm and use their camera binaries at least that's how it works with sense if you want to use their 4.2.2 cam libs
Click to expand...
Click to collapse
And their commit conflicts all over the place which is going to make it hard to cherry pick it. This was the commit I referred to earlier today.
On the plus side, the ril issue looks like it will get resolved for us. There is a commit out there for Samsung hardware that adds a couple of RIL events that look like they have been added.
crpalmer said:
And their commit conflicts all over the place which is going to make it hard to cherry pick it. This was the commit I referred to earlier today.
On the plus side, the ril issue looks like it will get resolved for us. There is a commit out there for Samsung hardware that adds a couple of RIL events that look like they have been added.
Click to expand...
Click to collapse
What about the commit introducing the HTCCDMAQualcommRIL?
Sent from my HTC6435LVW using xda app-developers app
times_infinity said:
What about the commit introducing the HTCCDMAQualcommRIL?
Sent from my HTC6435LVW using xda app-developers app
Click to expand...
Click to collapse
Which commit?
crpalmer said:
Which commit?
Click to expand...
Click to collapse
http://review.cyanogenmod.org/#/c/45607/
Hope it helps.
Sent from my HTC6435LVW using xda app-developers app
I'll take a look at the radio stuff tomorrow. I have a couple ideas.
Deck got data working on the m7 (Sprint), check the commits or wait until tomorrow if he hasn't pushed them yet
Sent from my buttered S3
chad0989 said:
I'll take a look at the radio stuff tomorrow. I have a couple ideas.
Click to expand...
Click to collapse
To be clear, it is working fine for me if I dirty flash. I have been running 10.2 builds for 48 hours everywhere from strong wifi to bad 3G in the middle of a forest.
It's only breaking if I do a factory reset before flashing a build. That's why my guess was that it was related to this event being missing:
cyanogenmod.org/#/c/46280/1/libril/ril.cpp
(around line 2240) and that a similar change was going to be required to our libril. My inclination would be to wait and see what happens with the M7 builds (which it sounds are coming along) and see if it just magically fixes itself for us....
Edited to add: sending of text messages wasn't working but looks like they were supposed fixed last night (I haven't built it to test it yet)
crpalmer said:
And their commit conflicts all over the place which is going to make it hard to cherry pick it. This was the commit I referred to earlier today.
On the plus side, the ril issue looks like it will get resolved for us. There is a commit out there for Samsung hardware that adds a couple of RIL events that look like they have been added.
Click to expand...
Click to collapse
mm actually now that i look at it drivers/media/video/msm has been left basically untouched in our source updating to what the m7 has shouldn't be too much of a problem
JoelZ9614 said:
mm actually now that i look at it drivers/media/video/msm has been left basically untouched in our source updating to what the m7 has shouldn't be too much of a problem
Click to expand...
Click to collapse
I tried a cherry-pick before and it looked very bad. But, actually, a lot of it looks like it could be related to the comments that HTC strips from the source when the release that I added back (because it makes it easier to patch from all non-HTC sources).
If you want to take a crack at this, try doing this before cherry-picking their commit:
git show c81741a8337c2342d856ffeac0cc087452729290 drivers/media/video/msm include/media/msm_camera.h | patch -p1 -R
That will strip all the comments back out again and get rid of all those conflicts. The conflicts then look very simple (outside of arch/arm/mach-msm, which is where it gets much harder).
crpalmer said:
I tried a cherry-pick before and it looked very bad. But, actually, a lot of it looks like it could be related to the comments that HTC strips from the source when the release that I added back (because it makes it easier to patch from all non-HTC sources).
If you want to take a crack at this, try doing this before cherry-picking their commit:
git show c81741a8337c2342d856ffeac0cc087452729290 drivers/media/video/msm include/media/msm_camera.h | patch -p1 -R
That will strip all the comments back out again and get rid of all those conflicts. The conflicts then look very simple (outside of arch/arm/mach-msm, which is where it gets much harder).
Click to expand...
Click to collapse
the board-monarudo-camera.c doesn't need to be updated, at least i didn't update it in my m7 kernel port
but i can't seem to get the kernel to build
drivers/gpu/msm/adreno_snapshot.c: In function 'snapshot_rb':
drivers/gpu/msm/adreno_snapshot.c:628: sorry, unimplemented: inlining failed in call to 'parse_ib': recursive inlining
drivers/gpu/msm/adreno_snapshot.c:588: sorry, unimplemented: called from here
make[3]: *** [drivers/gpu/msm/adreno_snapshot.o] Error 1
make[2]: *** [drivers/gpu/msm] Error 2
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs....
i don't believe it's related to any edits i made tho heres my commit https://github.com/Joelz9614/android_kernel_htc_dlx/commit/daa90f2bf8e64a8ad6f4f497ca412bc0a77ab7ef
JoelZ9614 said:
the board-monarudo-camera.c doesn't need to be updated, at least i didn't update it in my m7 kernel port
but i can't seem to get the kernel to build
drivers/gpu/msm/adreno_snapshot.c: In function 'snapshot_rb':
drivers/gpu/msm/adreno_snapshot.c:628: sorry, unimplemented: inlining failed in call to 'parse_ib': recursive inlining
drivers/gpu/msm/adreno_snapshot.c:588: sorry, unimplemented: called from here
make[3]: *** [drivers/gpu/msm/adreno_snapshot.o] Error 1
make[2]: *** [drivers/gpu/msm] Error 2
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs....
i don't believe it's related to any edits i made tho heres my commit https://github.com/Joelz9614/android_kernel_htc_dlx/commit/daa90f2bf8e64a8ad6f4f497ca412bc0a77ab7ef
Click to expand...
Click to collapse
Searching in the browser doesn't have any matches for adreno_snapshot...
Maybe try git checkout -b tmp HEAD~1 and make sure that builds?
Looks like CM just merged an updated audio HAL along with the legacy HAL, both of which incorrectly detect our device for now. Building with a fix now and if all is well I'll submit upstream.
Edit: It's going to cause a bunch of routing issues again also until some other stuff gets merged in. Best to just revert their change for now for builds.
chad0989 said:
Looks like CM just merged an updated audio HAL along with the legacy HAL, both of which incorrectly detect our device for now. Building with a fix now and if all is well I'll submit upstream.
Edit: It's going to cause a bunch of routing issues again also until some other stuff gets merged in. Best to just revert their change for now for builds.
Click to expand...
Click to collapse
Aside from the routing issues, this may already be fixed for us thanks to the m7:
http://review.cyanogenmod.org/#/c/46473/
@chad0989, FYI, I reverted the commit to use legacy alsa early this morning and haven't noticed any problems (play music on Bluetooth, voice calls with and without wired headset) using that build.
You may want to give it a try and see if you're ready to revert it.
Edit: actually, I just noticed that they had also enabled legacy audio in msm8960-common but since reverted that. So, I guess I was still running the legacy mode...
crpalmer said:
@chad0989, FYI, I reverted the commit to use legacy alsa early this morning and haven't noticed any problems (play music on Bluetooth, voice calls with and without wired headset) using that build.
You may want to give it a try and see if you're ready to revert it.
Edit: actually, I just noticed that they had also enabled legacy audio in msm8960-common but since reverted that. So, I guess I was still running the legacy mode...
Click to expand...
Click to collapse
They aren't allowing new HAL to build yet (see https://github.com/CyanogenMod/android_hardware_qcom_audio-caf/blob/cm-10.2/Android.mk) But we will need that flag when they allow the new HAL to build. I added it preemptively to hopefully avoid breakage. The issue was that the legacy HAL they pushed hadn't included some changes for our CSD client and platform detection. Looking at what was committed last night/today it should work now though.
I have gotten so far in this. The device boots and operates quite normally, with three exceptions.
The camera fails to record. If it starts to record, ending the recording freezes the camera. Or, it just won't start at all.
Some graphical glitches on the lockscreen. Nothing major, or breaking, but weird (see below) but the glowpadview is missing a chunk and there's a strong line of dots towards the lock icon.
Animations are jerky.
These are the device trees I'm using
# Device Samsung i9300
https://github.com/UltimaAOSP/android_device_samsung_i9300
# smdk44121-common
https://github.com/UltimaAOSP/android_device_samsung_smdk4412-common
# Kernel source
https://github.com/UltimaAOSP/android_kernel_samsung_smdk4412
This is the AOSP tree I'm using, by broodplank1337
https://github.com/AOSP-S4-KK
The source tree is great. broodplank1337 did a great job, and it builds and runs wonderfully on the S4 i9505. I have nearly got this down but I'd appreciate any help or advice available!
@Kryten2k35 I was surprised to find no pure AOSP ROMs for SIII. I'll be getting one soon so wanted to have compiled 4.4.4 for it.
I'm surprised you get the problems you have however, as surely these aren't apparent in AOSPA, SlimKat, etc. which are based on AOSP also? Surely you must have had to add vendor/samsung stuff, maybe some hardware/ repos, etc. as missing proprietary blobs would explain the broken camera. I'd be glad to help out anyway. I was about to sync pure AOSP source but do you think this'll be too much of a challenge?
Hi,
I should've updated this thread. It turns out I was compiling with ofast CFLAGS, which was causing the graphical glitches and animation issues. The camera I haven't tested yet, but I suspect the same.
Kryten2k35 said:
Hi,
I should've updated this thread. It turns out I was compiling with ofast CFLAGS, which was causing the graphical glitches and animation issues. The camera I haven't tested yet, but I suspect the same.
Click to expand...
Click to collapse
Thanks a lot, I may as well try building my own AOSP if I know you've been successful then. Will those UltimaAOSP trees work fine for me or should I use CyanogenMods or probably better AOSPAs? I'd be grateful if you could point me towards the correct vendor tree if I'll need to use anything our of the ordinary, but I assume CMs will be fine?
Thanks and sorry for the questions but I have 0 experience with this device (don't even own it yet ) so there's many more sources, trees, and stuff than I'm used to (Desire Z only had 1 maintained device tree).
The UltimaROM trees should work fine when I update them slightly based on these changes.
Everything is mostly AOSP, with the obvious exception of the device tree and kernel tree, both of which are Cyanogen, oh, and Camera, which is also Cyanogen. I had to make a few small changes to AOSP stuff to enable it to work with the S3, as well. nothing major, though.
EDIT:
My UltimaAOSP aim is to remain as close to AOSP as possible. Any modifications are 100% optional and disabled on a new install, so a user can have a Nexus-like experience if they wish.
You are 100% welcome to download UltimaAOSP's source and help in any way you see fit. I appreciate any help I can get.
Kryten2k35 said:
The UltimaROM trees should work fine when I update them slightly based on these changes.
Everything is mostly AOSP, with the obvious exception of the device tree and kernel tree, both of which are Cyanogen, oh, and Camera, which is also Cyanogen. I had to make a few small changes to AOSP stuff to enable it to work with the S3, as well. nothing major, though.
EDIT:
My UltimaAOSP aim is to remain as close to AOSP as possible. Any modifications are 100% optional and disabled on a new install, so a user can have a Nexus-like experience if they wish.
You are 100% welcome to download UltimaAOSP's source and help in any way you see fit. I appreciate any help I can get.
Click to expand...
Click to collapse
@Kryten2k35 Thanks, although I'd love to help I'm currently working on a few of my own projetcs with other members already. Is there no need for the android_hardware_samsung repo or SamsungServiceMode any more then as I can't find them in your sources? I've synced AOSP so I'm gonna have a go with your tree right now to see if it works, is it all updated? Thanks alot
EDIT: Found those repos in your default.xml, I assume they're needed then.
EDIT2: Will I need your vendor repo too? At the moment I assume I'll just have to run lunch full_i9300-userdebug as nothing else appears to work
@HTCDreamOn
Yeah you'll need my vendor repo and my Samsung propitiatory blobs repo, I think.
I've picked back up where I left off this last few days. All the graphical glitches were fixed. But the camera glitch remains: details are here: http://forum.xda-developers.com/showpost.php?p=54234546&postcount=585
I have one choice: ArchiKernel. No other kernel works with camera recording. Which is insane, since the CyanogenMod kernel should work fine, but does not.