PLEASE NOTE THE FOLLOWING:

This is the BETA Series of releases. Some things do not work and you should assume BUGS will be present. I am not responsible if you brick your phone with this or any other firmware. You are your own warranty once you start loading firmware. Please do NOT post about anything that's in the "broken" or "bugs" list; I will ignore you if you do. The status of things that are "working" and not will be updated as changes are made. See the second post for a reverse-chronological set of builds. While I am using this as my "daily" as most elements are currently functional, not everything is working - or working properly.

Note that this build uses the ext4 filesystem. Not all Clockwork versions can load this. The one in this thread can as can those of recent build by Isaac (yes, you should read the top posts by myself on every update, top to bottom.)

If it's not listed as working or broken below then that particular feature has likely not been tested at all. This code has very little runtime on it at present and is under constant revision and development. You're getting a peek at the code in a state where I would normally never let anyone see it simply due to lack of testing and documentation - please keep that in mind.

Kernel: Mine, built from Motorola's released source. The kernel has ext2, ext3 and ext4 support, and in addition to the standard governors also supports "SmartassV2". Default governor is "ondemand". Note that Smartass currently logs a bunch of complaints in the kernel log when ramping down the CPU speed; I'm looking into this but it does not appear to affect the performance or usability of the governor. I really like SmartassV2 but will not set it as a default; use CM7's or SetCPU's profiles to do so if you wish. Tunneling is built in and the CIFS loadable is present.

Performance: Quadrant scores around 2400 on my unit with gobs of applications loaded.

Codebase and credits: Originally sync'd from Isaac's work in the other thread, heavily modified at this point. Isaac deserves the credit for getting the base code to boot and getting me interested in hacking on it. We continue to work together.

Please note that I have moved from Virgin Mobile and expect to sell my Triumph, so I will not be able to test anything else soon. The 0.8 build should thus be seen as a "final", although I will monitor the reports on Github for bugs and can build if necessary. What's remaining as non-functional, other than the wifi/bluetooth interrupt storm, is relatively minor or has no reasonable hope of being fixable.


What's working (Bold = changed since last version):
If it's not listed below, you can reasonably assume it works.
In other words, pretty-much everything is working.
Wifi tethering is supported in 0.8 but is untested


What's known BROKEN (Bold: Added since last version):
HDMI is inoperative.
Front camera does not mirror snapshots or videos taken. Preview, however, is mirrored.
Occasional force-closes if you switch cameras from front to back; the switch works but there is a buffering problem in the camera code that causes a fault during the switch process.
CPU pegs if both Wifi and Bluetooth are on at the same time. This appears to be an interrupt storm and is a nasty problem as we do not have driver source for the libra.ko driver (Wifi); it appears to be coming from that device. For now the only answer is "don't do that."


Included Apps:
Essentially nothing. See below for GAPPS if you want Google applications (you almost-certainly do.)


Note that you cannot provision on the CM7 ROM (the "Activate" apk, if you grab it from the Triumph, will not work - it appears to run, but does not function.) You must be provisioned using the stock ROM before you load this code.


To install or update:

1. MAKE A NANDROID BACKUP! I cannot emphasize this enough - and make sure you keep that backup somewhere SAFE. Most notably there is no way to activate the phone on CM7 at this time, and there may never be. If you need to change your phone number or similar you need to swap back to stock firmware. If you lose the ability to do that you will be pissed. Consider yourself warned.

2. Place the file in the below post on your SD card in the root.

3. Boot to clockwork by turning your phone off and then hold BOTH volume buttons while pressing POWER. Release power when the phone vibrates and continue to hold both volume rockers until Clockwork comes up.

4. Important: Clear the cache and data ("factory reset") unless you are coming from a previous build of my CM7 code. If you fail to do this CM7 will almost-assuredly blow up on boot. If you have odd problems and didn't do a factory reset from Clockwork, try that before reporting bugs. You'd be surprised at how often ill-behaved applications have a kitten when versions of the operating system are changed out from under them.

5. If you are coming from a previous CM7 build I strongly suggest formatting /system (from the Clockwork menus) before loading. You don't technically need to, but not doing so could leave pieces of the old load laying around. Doing this will not bork your data and apps.

6. Select the ZIP file from the SD card (about halfway down on the top screen of Clockwork to get to that menu, then the first entry and point at it.)

7. Commit the update.

On first boot it will take about 2 minutes before the system comes up. Provided you see the little CM7 guy with the rotating arrow, it has booted. If you are not clearing data and have a lot of apps loaded it may take materially longer - as much as five minutes - as the davik cache has to be rebuilt and the screen may time out before the boot is complete. If it's been more than 5 minutes hit the power button twice and see if that turns on the screen. It should.


NOTE: On this release and forward the "Gapps" (Google Apps) must be separately downloaded and flashed after you load the ROM (before booting the first time is recommended):

http://goo-inside.me/gapps/gapps-gb-20110828-signed.zip - Base Google Apps
http://goo-inside.me/gapps/gapps-gb-20110828-newtalk-signed.zip - Google Talk (if you want it)

The base "Goo-Inside.me" page is found here: goo-inside.me - gapps downloads.

IF YOU FORMAT /SYSTEM AND DO NOT REFLASH BASE GAPPS AFTERWARD MANY THINGS WILL BREAK. That package contains all of the Google connections to Android - the authentication for your contact list, email, sync settings and more.

It is generally safe to not format /system if and only if you are coming from one of my previous ROMs in the same series (e.g. Beta, etc) and you have not manually tampered with any files in the /system area or the kernel. If that does not apply then you should format /system and reflash GAPPS or I can virtually guarantee that you will not like the results. If you have changed files under /system, especially if you have replaced any of the stock applications (e.g. the dialer, etc) or the kernel there is a very high probability that the remainder of the load will be out-of-sync with what you did and that can cause serious stability problems. There is no way for me to know what you did in this instance and I cannot realistically provide individual assistance if you have modified system files in the load or on your phone. Please be aware that the framework, kernel and loadable modules are different than stock and in many cases from one version to another as this is a work in progress.

If you want to make a donation to me for my work, please use the "Market Ticker" link below and hit the "Tip Jar." Any amount can be donated through PayPal using this method. If you sign up for my forum there you'll get credit for it too. Note: It's a tip; you're not buying continued work on my part by doing so.

My Github repository is under the user ID "Tickerguy"; I have verified that the code I am running will build off the manifest and repos there from scratch, so if you wish to pick up the development the ability do so is there. Due to time constraints I cannot provide hand-holding on getting set up to build or develop on this or any other device; PMs requesting same will be ignored. If you know enough to be a developer and be productive for this or any other Android device then you know what you're doing already or where you can find the information on the Internet (yes, it is easily found!) on setting up the cross-compile environment necessary to do so.

 

Current build:

11/19 - vB.08 http://www.mediafire.com/?bhmitbx7weqf8g2 - Wifi Tethering / FINAL
11/06 - vB.07 http://www.mediafire.com/?eqdfo7ktmtuq281 - Haptic soft keys / light sensor
10/30 - vB.06 http://www.mediafire.com/?qj28ip6o09j1ai6 - Screenshot / restore GB Launcher
10/29 - vB.05 http://www.mediafire.com/?rjf20vb74oc0irb - Cleanup release; see below
10/26 - vB.04 http://www.mediafire.com/?wwj1l5lzjb4glfy - Wifi wake lock and PRL
10/22 - vB.03 http://www.mediafire.com/?nssofns6sljfj33 - Proximity sensor and CIFS
10/21 - vB.02 http://www.mediafire.com/?vlbiqs99gijmvos - Proximity and USB Tether
10/16 - vB.01 http://www.mediafire.com/?jg5matblx1d7bq2 - First BETA


Clockwork that I am using:

Isaac's, built from source, has select and back on the soft buttons, v4.0.1.5. As of 9/24 you must use this (or one from someone else that understands ext4): recovery.img (again, recovery.img file only)

 

Priority list for the NEXT build:

Coming in the next build: (done and/or fixed; being tested):

Change Log (tracking as of 9/5), reverse chronological order:

11/19:
Wifi tethering is now built into the code (from Isaac's work); untested other than the fact that it does come up and is believed working. No other changes.


11/06:
Haptic feedback on soft keyboard now works and is treated as any other "virtual key" off the screen. Kernel modified to multiply light sensor readings by 30; this "sorta" aligns them with actual lux values (not really, but I don't have a light box that can get me a closer integration formula) and makes possible the CM7 options for "jump" settings, hysteresis and such to work as designed. No other material changes against b.06.


10/30:
Screenshot from power menu fixed and Gingerbread default launcher restored.


10/29:
Cleanup release. 2.3.7 codebase merge with CM7 upstream completed. "99memory" file added - see the notes below for how to tune this if you want to. Significant change to power management was made in the kernel; if you have Wifi turned off the phone will enter deep sleep, but if it's loaded then the sleep state is held at one level higher to prevent Wifi lockups. Note that data, when active, is a major power pig, even if nothing appears to be using it. It looks like Sprint has some "keep alive" processing going on either at the network level or in the actual CDMA driver code (which we don't have) that plays hell with power consumption. In short, with a data connection up I can't get materially under 30ma when idle and it's either the carrier or the CDMA radio code doing it - either way, I have no way to change it as there's no source to the chipset code available. Juice Defender, assuming Wifi is off, does a amazingly excellent job in conjunction with this release in shutting down the data connection and "waking it" once every 15 minutes or so to check for new notifications. It makes a huge difference in power burn with the phone in your pocket. You decide if its worth losing "instant" data notifies. I noted the same battery behavior on stock (Froyo) when I first got this phone, so my best guess is that this is in the radio firmware itself. Last alpha release pulled.


10/26:
Wifi wakelock fixed, PRL now comes from the actual radio ROM instead of being spoofed. Proximity sensor may flash once or twice if you put the phone to your ear before the call connects (when the phone vibrates briefly) but should not do so after that. It should also automatically wake up when you pull it away from your ear.


10/22:
Proximity sensor should be fully fixed; CIFS supported as a loadable .ko


10/21:
USB tethering now fully supported; this uses the RNDIS protocol, so your device must support it or it won't connect. Turn it on in the connections menu. It is sticky once turned on and will go "blue" like the Bluetooth tether does. A crack at improving the proximity sensor behavior was made; it is not a full fix, but you may find that instead of flashing repeatedly it only flashes once now - or not at all. This is a tough one; I've been in the kernel code and userspace - the hardware is sending actual "close/not-close" events upstream. This is still being investigated and I have a few leads on further resolution. Note that you do not need to clear /DATA or /SYSTEM if coming from 10/16 unless you have something really odd in your configuration.


10/16:
Front camera options that were invalid have been removed (caused hangs previously.) Soft keypad backlight is now PWM enabled, rather than just "on and off" and can be changed under CM7s options if you don't like my defaults. Sensor libraries changed to the cherry libs as they're far more responsive - this has both good and bad effects; the good is that the accelerometer is now useful for things like "shake to take screenshot"; the bad is that the compass is more jittery. Data drop is detected and the data connection recycled if it occurs - not that this does not address the "infinite search" bug, but does address the "data shows present but is white and doesn't work" problem. Memory management changes that should result in material "perceived speed" improvements across the board were made.This build was pushed early as verification of a "cold build capability" was not possible due to git repositories being offline all morning; do not expect to be able to pull a repo sync and reproduce this at present.


10/12:
GAPPS removed from base build, front camera fixes complete, rear camera will now video record in HD. Tunneling support now internal to the kernel (no longer requires a loadable) for VPN users. Torch application and power widget enabled. Previous versions REMOVED.


10/11:
Front camera now previews right-side up. Back camera supports touch focus. Tunneling driver added for those who want VPN access. Few other changes; this is a "point" interim release. Work continues.


10/2:
Partial front camera support is now available. The camera functions properly in video calling software such as Skype. Note that the "hacked" Froyo-capable Skype does not work properly; the one in the market, however, does. Other video calling applications may work but have not been tested. The Camera application itself will display the preview on the front camera but it is flipped 180 degrees (top to bottom), attempting to switch to video mode force-closes and a snapshot attempt hangs. Don't do that, basically. These are on the list to be fixed but progress is slow due to the very hacksterish way I had to implement the camera (no thanks to Motorola on that with no source access.) Kernel has the smartassv2 governor available for those who wish it and the build tree was synced up from CM7 to incorporate their fixes and updates.

9/25:
MSS clamping implemented - if your chosen tethering option recognizes that this is present it will prevent the dreaded "MTU mismatch" problems that require hardcoding a MTU in your ethernet or other interface. Bluetooth tethering is now supported and works; pair and load the drivers for the phone on your device and then choose to connect via the "Access point" (what Win7 calls it anyway) and tethering will come up. USB tethering is enabled in the codebase but has problems on my laptop for unknown reasons. The filesystem has also been converted to ext4, which is much faster. HDMI daemon now starts and runs, but I have no cable and thus no way to test it. Code sync against base CM7 and cleanup of the build structure is now complete.

9/20:
GPS is now functional. Despite what is reported by various people all of the "AGPS" stuff - in this ROM or any other - does NOT work. It is shut off in this build - if it's enabled I get quite-reproducable crashes. In Froyo it is intentionally turned off as well although it claims to be able to be "enabled" with various patches - it's lying to you.

9/18:
Primary change is that the Wifi lockup appears to be fixed - I can no longer reproduce it. Minor changes to the lights code; there should no longer be a combination while on charge where no light is on. Minor changes to the backlight table.

9/12 Afternoon:
Email program fix and guarantee that if there are existing APNs they will be cleared and overwritten. Note that an active APN will not show up in APN Manager on boot any longer (it's there but shows white and thus "inactive", not green and "active"), but it does work and if you wish you can mark it "active."

9/12 Noon:
Only change of materiality is that the APN is now force-set on (every) boot and the Gingerbread launcher is now the default. This version may be safely overloaded on the 9/11 load without a data clear.

9/11 afternoon:
MMS now correctly sends and receives - note that you will probably have to use APN Manager from the market to select the Virgin Mobile APN (it's in there, but will not autoselect for unknown reasons on first boot. You may also have to clear your /data - that is, factory reset - for the APN to show up.)

Bluetooth now picks a MAC address on first use and keeps it from that point forward. Wipe data if you run into problems with this on an overload from a previous version.

9/10 morning:
Compass/geomagnetic sensors now working properly
Lights code now honors CM7's customization screens

9/5 morning build:
Market problems with apps not showing up repaired.

 

To file a BUG report
Use the Bugtracker Git at https://github.com/ikarosdev/CM7_Triumph_bug_tracker/issues?sort=created&direction=desc&state=open

Filing a new bug will require that you set up a login ID on Github if you don't have one. Please note that bugs reported in this thread (as opposed to discussion, which is always welcome) may or may not be noticed and tracked; if you care about whatever you're reporting, please use the GITHub system. Bugs filed on Github must include steps to re-create the problem if you're able to do so and if you can obtain one, a logcat or other trace is very helpful. You can also look at the above link to see what issues are open (please do not duplicate already-reported bugs, although if you have comments on them adding them is fine) as well as what has bene closed which may be of interest if you're looking for what is likely to show up in the next code turn.


Expectations
I have been using this build as my personal load since the 9/25 code release and other than for things like loading PRLs have not been back to stock since. It's very stable for me and has only improved with time. It's not perfect but there's nothing that annoys me sufficiently to get "mad" and want to run Froyo again. This code is much smoother, much faster, more capable and very stable in my experience.

My battery burn is about 4% an hour idle (screen off) with "push" email through K9, but otherwise nothing running in the background (other than Gmail notifies, calendar event syncs, etc.) I do not allow random apps (e.g. Facebook, Twitter, etc) to sync automatically and you shouldn't either unless you like dead batteries.

For power management keep in mind the following things:

1. Wifi is a power pig. If you leave it enabled on battery it's going to suck the juice. In a good signal area 3g is better. In a bad one Wifi is better because 3g is seeking a signal often which is terrible.

2. The phone cannot enter the deepest sleep states with Wifi enabled and wakes up a lot when data is connected on 3g. This results in ~35ma or so of idle current with a data connection up and roughly 50ma with Wifi up (remember, Wifi also has the cell radio on, although 3g data is down.)

3. A seeking radio is the worst case. Attempting to re-acquire a cell or Wifi signal murders battery life as that requires actively transmitting. Transmit = bad, receive = much less bad.

4. If you are off charge do not have Wifi on when not where there's a connection for you consider something like "Juice Defender". This phone has a nasty power profile when data is up, even on cell and even when it appears no data is being run over the connection. It is what it is; this is true on Froyo as well. Juice Defender will kill the data connection most of the time when the screen is off but bring it up every 15 minutes or so to check for background transfers. The gain in battery life on this phone from doing that is very significant. This doesn't inhibit getting calls or text messages while the phone is "sleeping" and is nearly transparent. In fact I'm considering trying to figure out a way to patch CM7 to build in some of that functionality without an app, as a "timed" data enable could be a monstrous power saver.

5. Accept that if you have the screen on you're going to burn up the battery. Ditto if the CPU is pegged doing work. Between the two it is entirely possible to run power levels of 500ma or more, which will exhaust a full batter in under three hours. This is not unique to the Triumph; the more CPU you have and use and the more backlight you have on the less time the battery will last.

Bluetooth is utterly stable. I use Bluetooth a lot; in fact, I almost never actually put the phone up to my face, which is why the prox sensor wasn't a "first out of the gate" problem - it just didn't bother me much having it be odd once in a while.

I get about 3 hours of "heavy" browser use out of the battery. That's pretty good - on par with my other Android devices over the last couple of years. If I am going to be away from a charge source all day and want to make heavy of the phone I carry a spare battery with me.

YMMV, of course, but this is what I experience - and I use this device heavily every day. The guy who's building this stuff is eating his own cooking, as it is sometimes said, so there you have it.


Memory Tuning
This series of ROMs in B.05 and later have a reasonably easy to change memory allocation feature allowing you, the user, to select how low memory can get before the kernel starts killing things off. The file is in /system/etc/init.d/99memory. You will need to mount the /system directory read/write to be able to change this file. If you know how to use "vi" you can edit the file directly on the phone, edit it using something like ES File Explorer in "root" mode, or use "adb pull" and "adb push" to obtain and then re-write it (after re-mounting the /system area for writes.)

Do not alter the top of this shell script! The top portion causes the file to be loop-executed exactly once; when the phone boots this file runs quite early in the boot sequence, and the base command to set memory allocations in the init runs after this file does. To prevent this from being un-done immediately the code intentionally backgrounds a copy of itself, waits 2 minutes, and then executes the memory settings.

The second-to-last line sets the parameters. The defaults are reasonable but may allow the system to get lower on memory than you'd like. It is strongly recommended that you not tamper with the first three values. The last three are in pages (4,096 bytes each) and set the parameters for most ordinary applications, backgrounded things and un-attached data providers. A reasonable "more aggressive" setting from the default is 10000,25000,32000 for these three numbers. If you get too aggressive (too large) the phone will shut down virtually anything you background, obviating most multi-tasking. If you get too "open" then the phone will get slow as it runs low on RAM. The defaults are reasonable but you should consider tuning this to suit your particular mix of things you do. The values should always be in ascending order as well. This table is likely to change fairly regularly with new releases of the code, so if you have a particular personal preference do check it on each new load if you've changed it from the defaults (or like the present defaults!) Reboot to activate your changes.


Notes

Do NOT tamper with the following lines in build.prop:
ro.telephony.ril_nid=97
ro.telephony.ril_prl=1115
ro.telephony.ril_class=Triumph
ro.ril.def.preferred.network=4
ro.telephony.default_network=4
rild.libpath=/system/lib/libril-qc-1.so
rild.libargs=-d /dev/smd0

If you do there is a high probability that the radio will break. In particular the ril_class is required to deal with the oddities in the Qualcomm radio code. If you are running a different PRL you can change the prl line but it should remain present. The code has been taught how to get the real PRL; this is a backup but it should be there.

If you like to play around with different PRLs be aware that while CM7 claims to support diag mode on the USB port by default (to the point that it will happily claim it accepted a PRL update) it in fact does not write it to the radio. I have no idea why. As such if you want to update the PRL you need to flash back to stock to do so. For the most part on Virgin this is probably a waste of time as the PRL mostly controls roaming access, and you can't roam on Virgin service. Nonetheless, some people like to play, so the caution and note deserves mention.

If you are updating from previous releases and have problems format the /system partition before you load the update. You should not need to format the data partition ("factory reset") and reload your applications, but no promises can be made at this point in development. Note that formatting /system will wipe out GAPPS (Google's apps including the market!) and you will have to reload that. See the link in the top post.

The proximity sensor fix as of B.04 (and later) MAY cause one or two "bounces" if you put the phone to your ear BEFORE it vibrates with the "connected" notification. It should not once that happens, and it should wake when you pull the phone away from your head. If it does not, file a bug and include a trace. In B.03 it may require you to hit the power button to clear the lock after you put the phone to your face. This will not disconnect your call.

USB Tethering requires that "USB Debugging" be selected on the phone to work on Windows 7. This appears to be a Windows Driver issue with RNDIS as the phone is happy to offer tethering down the USB port without it turned on. Linux is perfectly happy to "see" the tether without the phone being set in USB debugging mode. Blame Microsoft for this stupidity, not CM7 (apply hammer to head if you think they will ever care.) I have no clue if the Apple realm knows what RNDIS is or ever will, so YMMV on that. Oh, if you're running into trouble with the Bluetooth tethering on an Apple product blame Apple for that stupidity; the instability is NOT in CM7 or in the specific code I have hacked to working condition in this phone. In short the internal tethering support in CM7 is absolutely bomb-proof - if you're having problems it's NOT the phone.

Do be aware that tethering is a violation of Virgin's TOS; if you get caught don't whine as you're intentionally breaking their rules. Trying to use this as a replacement for a landline connection such as a cable modem is an extraordinarily bad idea as is doing things that are "in their face" like downloading huge files, playing online real-time games on your PC, running P2P connections and similar foolishness. Use this feature with full knowledge and acceptance of the risks. Using it to quickly check email or run a VPN session for a few minutes that is possible to run from the phone (e.g. OpenVPN) but a serious pain in the tush probably does not violate (at least in spirit if not to the letter) what you agreed to, but trying to replace your cable modem certainly does and you deserve it if you get nailed. As a guy with more than 20 years of networking experience I will tell you with certainty that if Sprint is interested in finding out if you're doing this they can detect it, and Sprint was one of the first to offer Internet backbone services - they certainly do have people on their staff that are at least as smart as I am.

On the Beta series of loads (and forward, of course) memory management has been tuned to be much more aggressive. This has significantly improved the user experience at the cost of terminating some backgrounded applications that might otherwise be able to stay open. There's no free lunch - the phone has 512MB of RAM and some of it is taken for shared memory with the graphics subsystem, so you have ~350MB to work with and when it's gone, it's gone. Android gets cranky in terms of responsiveness when free memory goes under ~100MB or so and always has, becoming progressively more-nasty in performance as you approach ~50MB or so of free RAM. Below 50MB free stability becomes "at risk." I've tuned the system's internal process management parameters to get quite aggressive when the 100MB free RAM limit is approached, first killing data providers that have no attached clients (that is, they're currently idle) and then backgrounded applications if that's insufficient.

Custom backlight options (Settings->Cyanogen Mod->Display->Automatic Backlight) are available; you can change the behavior of the LCD backlight, including thresholds and illumination settings, the number of steps, whether averaging is used, whether hysteresis is operational and whether the button backlight is on or off and at what intensity as desired. Please note that unlike many devices the sensor value returned to the code is not in "lux"; it is a raw value and tops out in full sunlight somewhere under 100, with "0" being a fairly dim (but not dark) room. The default table I have loaded has the button backlight dim for very dim ambient conditions, ramping to moderate ambient conditions, and then OFF again (power saving) for ambient light high enough that the backlight has no real purpose. You may change this to suit yourself and your desires.

If overloading the 9/12 (or future builds) you may see an apparent lock-up on first boot. The real issue is that the launcher inclusion has caused the system to ask you which launcher you want. If the screen times out before that prompt comes up it appears you're dead, although the phone is actually running. Pull the battery - it will come up fine the second time and ask for your launcher preference.

Note: As of 9/24 this load is using the "ext4" filesystem. Alternative kernels must support both that filesystem and the options CONFIG_NETFILTER_XT_TARGET_TCPMSS and CONFIG_IP_NF_MANGLE. If they do not MSS clamping will not function. If ext4 is not supported the kernel will not boot.

3g/1x data lock
If you are in a place that often switches down to 1xRTT for data due to questionable signal levels it is possible to lock the RIL to 3g mode. Note that doing so means you either get 3g speed or nothing. You need to access the "Phone Info" menu to do this using either AnyCut (from the market) or from the "Battery Monitor" Widget (go to "Tests" in the selected screen from there.) Note, however, that doing so (1) will not survive a reboot and (2) disables SMS/MMS and incoming phone calls during the time it is active. SMS/MMS will come through if you make a phone call but the EVDO-only mode for data blocks something in the radio that is required to receive and send SMS messages and receive call notifications. Since this "mode change" is actually a request to the radio ROM (which we do not have source for) this probably can't be worked around. However, I am looking into what this mode select does in the hope of being able to detect the 1x switch (which I can easily do with the existing RIL support code) and temporarily force a 3g switchback - which may or may not be highly-disruptive to data transport (if it is it's not worth doing at all, but if not...)


A note on overclocked kernels:
I will not be supporting these in my builds. They work, and some people want them. Isaac has built one that can (theoretically) go to 1.9Ghz.

Here's the issue in a nutshell: It's pretty easy to exceed thermal limits in a CPU doing this, and if you do, the best thing that happens is that the device becomes unstable and reboots. The worst thing that can happen is that the internal junctions in the CPU can be damaged or even destroyed. This damage is not always immediately apparent and can in fact be cumulative.

I understand some people want to overclock, but nobody really knows where "the wall" in this regard, and if you find it you're going to be very unhappy. As such if you want to have fun of this sort you'll need to load your own overclocked kernel over what I build. I respect those who are willing to take the risk but I just don't see the potential reward as being worthwhile and I don't want to be the guy that hands you a build that smokes the CPU in your phone.

 

Basically the sensor pack is hosed - the phone doesn't see them, although the kernel does, so it's a matter of running down the correct "connections" one by one. It'll take a while.

I wouldn't release this now but I know everyone wants something to play with, and once I got the sound working it seemed like a good idea to let people screw with it. I'm not going to chase bugs for a while yet until the feature set is stable. Go ahead and post observations if you want but don't expect any sort of fast response; the list of things in the "broken" list has priority.

 

Rock, no. I need source to that "adjbrightness" tool for a reasonable-time-investment fix to that.

I'll put the headset issue in the queue.