[Firmware][ICS]UNOFFICIAL CM9 for the Infuse 4G (07/28/2012)

Search This thread

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
How did you actually get this to work? When I tried that with apns-conf.xml to fix all the mms issues, the normal apns-conf.xml always overrode the one I added to the device tree. I added it to product_copy_files, but the zip always contained the old one. (even after make cleans)
For some reason, PRODUCT_COPY_FILES in the .mk files works for some stuff but not others...

And how do you actually have BT turning on? Must be more than just the BNEP change.. I'm getting this in logcat when I try:
Code:
I/hciattach( 2979): unknown option -- d
I/hciattach( 2979): hciattach - HCI UART driver initialization utility
I/hciattach( 2979): Usage:
I/hciattach( 2979): 	hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty> <type | id> [speed] [flow|noflow] [bdaddr]
I/hciattach( 2979): 	hciattach -l
I/logwrapper( 2979): /system/bin/hciattach terminated by exit(1)
(after compiling in the BNEP change)
Crap. Because Bluetooth was toast, I forgot to push http://review.cyanogenmod.com/#/c/17873/ out which was a failed experiment I tried to get working but it never did work.

There's a different solution in place, I just pushed it out. Sorry.

Posting a new build - Bluetooth working for non-audio stuff, Wifi direct working (at least partially, there seem to be a few glitches still). I also need to post a tarball with my blobs until I fix extract-files - I had that fixed but my tree got clobbered by some funkiness before I pushed it out.
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
As to APNs... AT&T's dual-APN setup is a pain in the ass. It's something almost no other carriers make you deal with, as a result handling of it in CM isn't quite right. I need to talk to Cyanogen about whether AT&T's LTE APNs have the same needs for dual-APN. Unfortunately while there are provisions for selecting a different default APN, handling the dual-APN situation is tough.

In my case I never use MMS so the solution is easy - just set up the phone APN manually. Using it alone breaks a feature I never use.

Sent from my GT-P7510 using Tapatalk 2
 

jblparisi

Senior Member
Jun 12, 2007
572
508
For some reason, PRODUCT_COPY_FILES in the .mk files works for some stuff but not others...


Crap. Because Bluetooth was toast, I forgot to push http://review.cyanogenmod.com/#/c/17873/ out which was a failed experiment I tried to get working but it never did work.

There's a different solution in place, I just pushed it out. Sorry.

Posting a new build - Bluetooth working for non-audio stuff, Wifi direct working (at least partially, there seem to be a few glitches still). I also need to post a tarball with my blobs until I fix extract-files - I had that fixed but my tree got clobbered by some funkiness before I pushed it out.

Been away from the PC for a few days and I see there has been quite the progress. You and araemo have showed so much in so little time it is hard to keep up sometimes. Awesome work!

Time to pick up where I left off...
 

araemo

Senior Member
Jun 23, 2011
515
620
Been away from the PC for a few days and I see there has been quite the progress. You and araemo have showed so much in so little time it is hard to keep up sometimes. Awesome work!

Time to pick up where I left off...

Pft, it's 99.9999% entropy. I'm just acting as occasional test mule. ;P

Edit: Not sure why this didn't post in here:
Maybe I'm not thinking this through right but the ATT LTE APN should never be enabled as an option on this device even if it isn't the primary apn so it's a good thing you changed it. On any CM builds I recommend doing one single APN or else you're going to run into switching issues (not sure if this has been alleviated). Anyways. After playing with about 100 billion combinations, this single APN seems to work best though you're limited to 4mbps downstream.

Edit: I didn't have too many issues when I used dual apns with this build. I set the phone apn as default,supl,hipri and the one I posted screenshots of as strictly mms. It took a longer time for pictures to send obviously because of apn switching, but it worked alright. I send a lot of pictures so single apn is the way to go for me personally :cool:

Sent from my SGH-I997 using XDA
Personally, the ONLY change I have to make to get everything 'functional' is change the default apn to use an IP instead of a hostname for the mmsproxy. I have no clue if I'm being artificially limited to 4Mbit though. I do notice 4Mbit is my highest speedtest in a LONG time.. but I only reliably got more than 4 in one location anyways, and I haven't been there in a while. What APN gives you guys better than 4 Mbps reliably? I'd love to just poke at it a bit.

resetting the APNs' on CM9 or other ICS builds results in getting the "pta" apn. Easy enough to fix for most people that can flash firmware, right?
If adding the newer .xml file to github only results in the older file being added to the build when recompiling, why not just remove the old file?

BTW, I'm finding this to be the MOST interesting thread ANYWHERE on XDA, period!
If you 'reset to defaults' in CM9, it reads from apns-conf.xml, and that's what I'd like to fix since it would end a lot of repetitive posts (and a repetitive fix, that's kinda silly to have to do).

As for why not remove the older file? The build system and the older file are synched as part of a batch synch from the official cyanogenmod repos on github. If we change that file in our local build tree, every time we synch new changes down, we'd have to change that file again. Pain in the ass we don't want to deal with. That's why overriding it in the device-specific repo we control would be a realistic workaround..

Edit 2: I can confirm bluetooth pairing works, and OPP works (Was able to push a couple contact cards to another phone.)

Edit 3: A2DP is exactly like it was in CM7. I'm thinking something isn't setting the sample rate 'right' for audio being sent to A2DP.

And for some reason headset audio is actually far more broken than A2DP. A2DP you can actually pick up snippets of your intended audio... headset audio is just completely static.
 
Last edited:

stratatak7

Swappa Representative
Jun 6, 2011
1,574
2,574
Fredericksburg, VA
Pft, it's 99.9999% entropy. I'm just acting as occasional test mule. ;P

Edit: Not sure why this didn't post in here:
Personally, the ONLY change I have to make to get everything 'functional' is change the default apn to use an IP instead of a hostname for the mmsproxy. I have no clue if I'm being artificially limited to 4Mbit though. I do notice 4Mbit is my highest speedtest in a LONG time.. but I only reliably got more than 4 in one location anyways, and I haven't been there in a while. What APN gives you guys better than 4 Mbps reliably? I'd love to just poke at it a bit.


If you 'reset to defaults' in CM9, it reads from apns-conf.xml, and that's what I'd like to fix since it would end a lot of repetitive posts (and a repetitive fix, that's kinda silly to have to do).

As for why not remove the older file? The build system and the older file are synched as part of a batch synch from the official cyanogenmod repos on github. If we change that file in our local build tree, every time we synch new changes down, we'd have to change that file again. Pain in the ass we don't want to deal with. That's why overriding it in the device-specific repo we control would be a realistic workaround..

Edit 2: I can confirm bluetooth pairing works, and OPP works (Was able to push a couple contact cards to another phone.)

Edit 3: A2DP is exactly like it was in CM7. I'm thinking something isn't setting the sample rate 'right' for audio being sent to A2DP.

And for some reason headset audio is actually far more broken than A2DP. A2DP you can actually pick up snippets of your intended audio... headset audio is just completely static.

phone APN yields 7mbps within dolphin browser for me :)
 

araemo

Senior Member
Jun 23, 2011
515
620
phone APN yields 7mbps within dolphin browser for me :)

I'll do some testing next time I'm somewhere it looks like I'm bumping against 4Mb.

BTW, Entropy.. the Xperia Sola open source drop earlier.. I was just poking through it.. the defconfig they list for the sola definitely has this:
Code:
CONFIG_BT_CG2900=y
.. And there's also a bluez folder in the opensource.. is bluez what CM uses, or is Bluez the same thing Samsung used that was useless for us?
 

abo gassar

Senior Member
Feb 26, 2012
51
13
For some reason, PRODUCT_COPY_FILES in the .mk files works for some stuff but not others...


Crap. Because Bluetooth was toast, I forgot to push http://review.cyanogenmod.com/#/c/17873/ out which was a failed experiment I tried to get working but it never did work.

There's a different solution in place, I just pushed it out. Sorry.

Posting a new build - Bluetooth working for non-audio stuff, Wifi direct working (at least partially, there seem to be a few glitches still). I also need to post a tarball with my blobs until I fix extract-files - I had that fixed but my tree got clobbered by some funkiness before I pushed it out.

how about Bluetooth ? :D

read all posted thread and u will know :)

thank u entropy for ur job and i appreciat it
 

PoXFreak

Senior Member
Jan 2, 2011
1,132
846
Apex NC
Pft, it's 99.9999% entropy. I'm just acting as occasional test mule. ;P

Edit: Not sure why this didn't post in here:
Personally, the ONLY change I have to make to get everything 'functional' is change the default apn to use an IP instead of a hostname for the mmsproxy. I have no clue if I'm being artificially limited to 4Mbit though. I do notice 4Mbit is my highest speedtest in a LONG time.. but I only reliably got more than 4 in one location anyways, and I haven't been there in a while. What APN gives you guys better than 4 Mbps reliably? I'd love to just poke at it a bit.


If you 'reset to defaults' in CM9, it reads from apns-conf.xml, and that's what I'd like to fix since it would end a lot of repetitive posts (and a repetitive fix, that's kinda silly to have to do).

As for why not remove the older file? The build system and the older file are synched as part of a batch synch from the official cyanogenmod repos on github. If we change that file in our local build tree, every time we synch new changes down, we'd have to change that file again. Pain in the ass we don't want to deal with. That's why overriding it in the device-specific repo we control would be a realistic workaround..

That ( ^ ) and a build.prop fix is about all thats needed to see above 4Mbps, albeit on the "phone" apn. I have done some extra poking around through various CM9 builds and found ro.ril.hsxpa to be set at 1, which is incorrect. Unless ICS handles this differently, this would limit data speed to only UMTS speeds.
1=UMTS/EDGE, 2=HSXPA/GPRS/HSPA+ (in my findings; I blew through a months data usage testing this)
 
  • Like
Reactions: qkster

aly_hosny

Senior Member
Nov 3, 2011
242
88
33
Benha
hitting thanks isnt enough to thank you
thank you Entropy for hard work you are a hero
thanks araemo for your help with this
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
I'll do some testing next time I'm somewhere it looks like I'm bumping against 4Mb.

BTW, Entropy.. the Xperia Sola open source drop earlier.. I was just poking through it.. the defconfig they list for the sola definitely has this:
Code:
CONFIG_BT_CG2900=y
.. And there's also a bluez folder in the opensource.. is bluez what CM uses, or is Bluez the same thing Samsung used that was useless for us?
Bluez is what we want... The thing is that the audio is a board-specific thing so while the Xperia's source might be useful, there's a good chance the problem lies elsewhere.

Also, what binary blobs changed? I have a working build with nothing but what's on github.

Wifi Direct will bomb - it needs a new firmware blob, unless I already threw a P2P file in there a while ago...
 

araemo

Senior Member
Jun 23, 2011
515
620
Bluez is what we want... The thing is that the audio is a board-specific thing so while the Xperia's source might be useful, there's a good chance the problem lies elsewhere.
Yeah.. I figure it's going to take finding the hooks that start configuring the A2DP audio path and following them all the way down the rabbit hole.. :/ And reading poorly commented C++ (There are NO comments in the bluez c files I saw in the sola code drop) on features I barely understand is slow. ;P

Wifi Direct will bomb - it needs a new firmware blob, unless I already threw a P2P file in there a while ago...

Ah, doesn't really effect me then.. Wifi direct between my infuse and all the other wifi direct capable devices I own (Oh, right, none..) is not very useful. ;)
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Yeah.. I figure it's going to take finding the hooks that start configuring the A2DP audio path and following them all the way down the rabbit hole.. :/ And reading poorly commented C++ (There are NO comments in the bluez c files I saw in the sola code drop) on features I barely understand is slow. ;P

Well, the interesting thing is that if I recall correctly, A2DP was partially functional but skipped like crazy in CM7. I don't know its current state in CM9, as I have not had access to a functional A2DP device in over a year with the exception of occasional rental vehicles. (My BT-enabled headunit has sat in a storage closet since I got rid of the car it was installed in...) The skipping stuff might be fixable with a few tweaks available as boardconfig options in CM9 - I have no clue though as I don't have a way to test.

I remember seeing something about A2DP buffering options somewhere but I forget where...

Headsets (SCO) are a completely different beast... Those are dead silent, so clearly something is wrong with audio routing, and I have no idea why or what. I'm not even sure if SCO is handled by software (audio is packetized and sent by the Bluetooth stack, implementing a virtual audio device somewhere) or if the chip has hardware audio connections directly to the sound subsystem.
 

araemo

Senior Member
Jun 23, 2011
515
620
Well, the interesting thing is that if I recall correctly, A2DP was partially functional but skipped like crazy in CM7. I don't know its current state in CM9, as I have not had access to a functional A2DP device in over a year with the exception of occasional rental vehicles. (My BT-enabled headunit has sat in a storage closet since I got rid of the car it was installed in...) The skipping stuff might be fixable with a few tweaks available as boardconfig options in CM9 - I have no clue though as I don't have a way to test.
I actually confirmed that a few posts up.. I know it's gotten spammy though. My computers can act as an A2DP sink and play A2DP audio through their speakers, so I tested that last night.. it skips but you get some of your audio.

I remember seeing something about A2DP buffering options somewhere but I forget where...
I'll start searching as well.. wish you could free-text search gerrit (Am I just blind?)

Headsets (SCO) are a completely different beast... Those are dead silent, so clearly something is wrong with audio routing, and I have no idea why or what. I'm not even sure if SCO is handled by software (audio is packetized and sent by the Bluetooth stack, implementing a virtual audio device somewhere) or if the chip has hardware audio connections directly to the sound subsystem.

I saw a fair amount of SCO stuff in the code.. and the weird thing for me is the headset connection isn't COMPLETELY silent, it actually has a lot of loud static/noise in it. But that noise is there regardless of what should be coming over (silence or real audio), so it seems like a more fundamental disconnect, more like what you're talking about..

What'd be really nice is some real CM documentation of 'when the system tries to connect to A2DP (or SCO), it makes this syscall or this api call, and that api uses this config to look up what to connect to.. blah blah blah.. ;)

I don't even know where to START looking for that stuff. (Well, not 100% true... I'd START by looking at the obvious phone and audio stuff in the tree.. ;P)
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
I actually confirmed that a few posts up.. I know it's gotten spammy though. My computers can act as an A2DP sink and play A2DP audio through their speakers, so I tested that last night.. it skips but you get some of your audio.
Whoops missed that...

I'll start searching as well.. wish you could free-text search gerrit (Am I just blind?)
Nope... Searching gerrit is a ****ing pain. Sometimes you get lucky with grepping. I know I saw some A2DP buffering stuff somewhere but I forget where.

I saw a fair amount of SCO stuff in the code.. and the weird thing for me is the headset connection isn't COMPLETELY silent, it actually has a lot of loud static/noise in it. But that noise is there regardless of what should be coming over (silence or real audio), so it seems like a more fundamental disconnect, more like what you're talking about..

What'd be really nice is some real CM documentation of 'when the system tries to connect to A2DP (or SCO), it makes this syscall or this api call, and that api uses this config to look up what to connect to.. blah blah blah.. ;)

I don't even know where to START looking for that stuff. (Well, not 100% true... I'd START by looking at the obvious phone and audio stuff in the tree.. ;P)
For me it was mostly silent with a little bit of static, as if a pin were just floating.

Android SCO documentation is ****. :(
 

araemo

Senior Member
Jun 23, 2011
515
620
For me it was mostly silent with a little bit of static, as if a pin were just floating.

Android SCO documentation is ****. :(

Interesting.. I hadn't thought of it that way.. could definitely be, and could definitely explain vastly different experiences - if there's a pin just floating, what you hear could depend a lot on just what else your device is doing, and how close it is to EMI sources.

Anyways, I found the cg2900 debug printks are disabled by default.. gotta turn the default debug level above 0 before they'll print anything.. you can then tune the running debug level through /sys/module/cg2900/parameters/cg2900_debug_level

Compiling a kernel with that on.. I think debug 20 might be all we need, but 25 also prints info about data being sent/received. 30 prints the actual DATA to kmsg.. that sounds like super overkill. ;)

Edit: Just noticed an interesting bug as well.. Bluetooth MAC is not being read right. Each reboot gets a different bt MAC.

Doubly funny because the bluetooth pairing list is saved by MAC.. so the pairing I did last night wasn't listed anymore.. but it might come back at a random reboot. ;P This really does break the pairings though because if you re-pair, the key is different.
 
Last edited:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Interesting.. I hadn't thought of it that way.. could definitely be, and could definitely explain vastly different experiences - if there's a pin just floating, what you hear could depend a lot on just what else your device is doing, and how close it is to EMI sources.

Anyways, I found the cg2900 debug printks are disabled by default.. gotta turn the default debug level above 0 before they'll print anything.. you can then tune the running debug level through /sys/module/cg2900/parameters/cg2900_debug_level

Compiling a kernel with that on.. I think debug 20 might be all we need, but 25 also prints info about data being sent/received. 30 prints the actual DATA to kmsg.. that sounds like super overkill. ;)

Edit: Just noticed an interesting bug as well.. Bluetooth MAC is not being read right. Each reboot gets a different bt MAC.

Doubly funny because the bluetooth pairing list is saved by MAC.. so the pairing I did last night wasn't listed anymore.. but it might come back at a random reboot. ;P This really does break the pairings though because if you re-pair, the key is different.
Probably just need to mess with bdaddr, I guess it's probably broken in some manner.

There's a possibility this problem lies in libaudio not in bluez, but not sure. It could be similar to the whole issue LB had to fix with ringing.

I think my next task is a Daily Driver update with CWM 5.x - This will allow easier Nandroiding back and forth between TW Gingerbread and CM9 - I have a feeling we need to crank up debugging on a TW Gingerbread system to see what is going on.
 

PoXFreak

Senior Member
Jan 2, 2011
1,132
846
Apex NC
Just took a peek into /sys/module/cg2900/parameters and didn't see one damn thing related to audio, unless baud rates would have any effect on audio.
My next place to look would be whatever handles D/A-A/D conversion in the audio stream to place it in the BT I/O. I'm no expert but I have built a few D/A converters in the past and I know how touchy they can be when it comes to the signal they receive.

Where can I look and what can I do to help?

Just offering insight, maybe looking somewhere else might help? :confused:

EDIT: Did I just flip through about 20 folders inside /sys/class/cg2900_class/cg2900_bt_audio? I almost crashed Root Explorer trying to get to the actual driver, which I never did.
 
Last edited:
  • Like
Reactions: qkster

Top Liked Posts

  • There are no posts matching your filters.
  • 215
    DO NOT POST IN THIS THREAD UNTIL YOU HAVE COMPLETELY READ THIS POST AND THE FAQ.

    Since jt1134 is no longer supporting his CM9 releases here on XDA and asking people to go elsewhere for support, I have decided to start building CM9 for the Infuse.

    Much of the credit goes to him for doing the initial ICS bringup for Infuse, I'm working on fixing some of the things that are not yet working. Even more goes to LinuxBozo - without his CM7 work we would be nowhere.

    http://d-h.st/vN1 - 06/20/2012 build
    http://d-h.st/ahW - 06/27/2012 build
    http://d-h.st/Pfr - 07/28/2012 build

    Installation instructions-from a Gingerbread firmware with "red CWM":
    Place this release and an ICS gapps release on your SD card.
    Flash this ZIP in CWM
    Reboot - you will get stuck at the Samsung screen
    Reboot to recovery again using the three-finger salute - hold down VolUp+VolDn+Power until the device reboots, release Power after the reboot, continue holding VolUp+VolDn
    Go to Mounts and Storage and format: system, data, cache
    Flash this ZIP a second time, then flash gapps
    Reboot and enjoy

    Coming from any AOSP-based firmware with "blue CWM":
    Flash this, flash gapps, wipe. That should be all you need.

    What is working:
    Calls
    GPS
    Sound
    Video playback

    What is partially working:
    Camera (minor flakiness, but mostly working)
    Car dock audio (possibly desk dock too, untested) - Some issues with ringtone playback when docked - This is native dock audio, not using the Car Dock Redirector app workaround. Thanks go to StevenHarperUK of the GT-I9100 community for reworking CM9's dock audio code to permit this to work.
    Wifi - It frequently loses connection when the device is asleep. Most likely needs some SDHCI driver tweaks to match the N7000 wifi driver.
    Wifi Direct - A little glitchy but mostly working with I777/N7000. Won't talk to a P7510 (Tab 10.1) though.
    Bluetooth - A2DP (music) and SCO (call audio) now works. However BT power management (LPM) is currently disabled, so BT may eat your battery when on.

    Not working:
    TV Output - No one has gotten MHL fully working on any Samsung device yet to my knowledge. There's some promising results from the I9100 community but it's not there yet.

    Known issues:
    SetCPU seems to be unable to set the minimum frequency to 100 MHz. This is one of the main reasons for holding off on OC - even stock clock code isn't working quite right
    Facebook contact sync has been blocked by Google in ICS - this is universal to ICS on all devices I'm aware of. Facebook got what they deserved here.
    63
    Building - Use the Source, Luke

    Kernel source is at: https://github.com/teamhacksung/android_kernel_samsung_dempsey

    Device repo at: https://github.com/teamhacksung/android_device_samsung_infuse4g

    To build, first prep your system for a Cyanogenmod build by following the instructions at:
    http://wiki.cyanogenmod.com/wiki/Building_from_source

    Once you have done the first "repo sync", at the two following lines to .repo/local_manifest.xml
    Code:
      <project path="device/samsung/infuse4g" name="teamhacksung/android_device_samsung_infuse4g" remote="github"/>
      <project path="kernel/samsung/dempsey" name="teamhacksung/android_kernel_samsung_dempsey" remote="github" />

    Run "repo sync" again

    Sync https://github.com/TheMuppets/proprietary_vendor_samsung/ into vendor/samsung

    Drop the contents of the attached tarball into vendor/samsung

    (I really need to clean that process up...)

    Run:
    Code:
    . build/envsetup.sh && brunch infuse4g
    51
    FAQ

    Q: I get weird rainbows in recovery and when my device boots? What gives?
    A: This is what happens when a Gingerbread or ICS kernel is booted on a device with Froyo bootloaders. You will need to either live with the rainbows (recovery is at least partially usable with the rainbows now) or flash Gingerbread bootloaders. Stay tuned for more info on bootloader flashing.

    Unfortunately, the classic "rainbow fix" we used for Gingerbread is not compatible with how video acceleration is set up in ICS. The rainbowfix will just cause the device to crash immediately on boot. (I think this is why jt was not successful with LinuxBozo's CM7 source.)

    Q: I'm getting rainbows, how do I flash Gingerbread bootloaders?
    Flash the bootloaders from the file attached to this post using Heimdall as follows:
    Code:
    heimdall flash --primary-boot boot.bin --secondary-boot Sbl.bin

    DO NOT do this unless you are experiencing rainbows, and DO NOT do this until you have confirmed you can flash less dangerous stuff (like kernels) with Heimdall. If the flash fails you will hardbrick!

    Thanks to LinuxBozo for confirming, way back in the days of UCKJ2, that Heimdall can safely flash bootloaders from leaks. http://xdaforums.com/showthread.php?p=18539754#post18539754 - Be warned, once you do this step there is no going back. For whatever reason the Infuse won't flash dumped bootloaders, so there is no known way to return to Froyo and Rogers Gingerbread bootloaders.
    49
    Change Log

    7/28/2012:
    Removed 1000 MHz cpufreq step - the extra frequency step was causing all sorts of weird derpage.
    Fixed 1200 MHz step (it was using the wrong PLL settings)
    Moved to open source sensor HAL

    7/22/2012:
    Major improvements to camera flash functionality - torch is still broken but most other flash functions work
    EXIF info (including rotation) is now saved. However I had to disable JPEG thumbnail generation, which slows down viewing of images in gallery
    Structural changes to the repos to make things cleaner - Once two patches get merged by CM I plan on submitting Infuse for official nightlies
    CPU clock handling for GPU bus frequency was changed from a policy change (min freq bumped to 200 MHz in policy, which would cause some apps to "stick" the min at 200) to a DVFS lock. Min no longer bumps up to 200 - however any time the GPU is active it'll still lock to 200 MHz.

    6/27/2012:
    Discovered our device has a Broadcom BT chipset - the CG2900 is NOT used for Bluetooth. BT is now fully functional other than possible power management issues

    6/20/2012:
    Various upstream stuff
    Wifi Direct support added - partially glitchy (see OP)
    Bluetooth support brought up to CM7 levels (Audio stuff is still broken)

    5/27/2012:
    New wifi driver from GT-N7000 Update3 source drop: Hopefully will improve wifi for those with issues
    New LPM (charging while off) code from I9100
    All upstream changes since last build, including lockscreen weather

    5/19/2012:
    Lots of upstream CM9 changes, including theme engine and customizable lockscreen
    Settings->Advanced now works. mDNIE settings (tested) and HSPA+ control (untested)
    A small patch that might help wifi driver loading issues, but not guaranteed (gokhanmoral reverted it within a day in his case...)

    5/2/2012:
    Pulled in a few wifi fixes from gokhanmoral's I9100 SiyahKernel tree. May help those who are having wifi issues.

    4/23:
    Fixed wifi MAC address getting set randomly on every boot

    4/22:
    Misc stuff from CM9 upstream
    New wifi driver backported from the I9100 update4 sources and pershoot's Tab 10.1 kernel - Fixes wifi tethering!
    USB tethering removed until I can make the RNDIS driver play with the new net/wireless code - not even sure if it was working to begin with.

    4/19:
    No more banding in recovery (thank codeworkx for this one, exact same fix as for I9100)
    FFC is no longer cropped to one corner of the sensor. Full resolution support for FFC still not implemented
    Various upstream changes
    36
    I'm going to push out a build that hopefully fixes some of the wifi driver issues tonight, it pulls a few patches in from gokhanmoral's I9100 tree. (I9100 users have had occasional issues with wifi reliability too.)

    Since I can't reproduce the issues I don't know if it will help things or not.

    I do plan on staying with this wifi driver. The benefits of working tethering and (hopefully) eliminating the BT-AMP wakeup bug (as it did when backported to the Tab 10.1) outweight the small issues it has.

    Currently on my list, time permitting:
    Try to identify why the broadcast/ARP packet filters don't enable when the screen is off. This seems to be a common issue to all devices using the I9100 wifi drivers and CM9 - It can hurt battery life for those on "dirty" networks with lots of broadcast spam. It's not a problem for most developers as we run clean networks, which might explain the unusual discrepancies in battery life between the developers and some users.
    Attempt to see if there's a way to shoehorn the I9100 camera HAL onto the Infuse, which seems to use the exact same cameras. If possible it will provide a much more robust camera experience. If not - I've lost enough sleep to the damn camera HAL, I welcome someone else trying to fix it. I hate going from an open-source HAL to a blob - but the open source HAL isn't working too well.

    I'm probably not going to be doing too much over the next few days on any device, I'm generally exhausted.