[Nook Color Android Development] dalingrin:
I see my previous comment calling you a troll fell on deaf ears. You edited your earlier post so I'll just paraphrase it here to help you understand why I have a standoffish attitude towards you. I called you a troll earlier because you essentially said I was either lying or ignorant about SGX acceleration working in CM7. Then went on to say that its amazing that CM7 works at all because of all the failed telephony, DSP and SGX subsystems eating memory and running in the background. Meanwhile, as far as I can tell you haven't used a CM7 nightly and have no empirical evidence to back up your claims. If you had used a CM7 nightly you would see see that SGX acceleration works as intended. DSP does not...as I've stated multiple times. And a quick check of the logs would show telephony systems are not constantly pinging the CPU trying to make a connection.

Your earlier post was trollish for those reasons. Your current post is not...Its simply posted with a bad attitude. I try to answer folks questions to the best of my ability given the amount of time I have to do so. I'm a full time student, have 2 university research projects underway, have a major software development contract and meanwhile I play with kernel and CM7 development for the Nook Color. Nevermind that I have a personal life outside of school and software development. I simply don't have time to write you an essay for each of your posts. If you want me to answer your questions you can at least ask without negative connotations.

The majority of what I see you post about is *****ing about my own and other's work or wanting us to rewrite substantial Android or driver subsystems to please you. This stuff isn't going to happen overnight. Most of the changes you want aren't going to happen until honeycomb source drops. It is unreasonable to expect a team of 4, with only a finite amount of time to devote to the Nook, to fix fundamental problems that Gingerbread has with tablets. We can only do so much.

2.6.32 is booting to the GUI but the touchscreen is not working. The touchscreen driver appears to be functional(events are being broadcast), however Android doesn't respond to touch. Oddly, if the backlight dims touching the screen will bring the backlight back up. This is the biggest show stopping issue with the 2.6.32 kernel port.

SGX works....SGX works.....SGX works. Seriously, how many times do I have to say it?

The DSP on the other hand does not work. Overlay works but is useless without DSP acceleration. The DSP is difficult because we have an archaic kernel driver. The userspace library(libbridge.so) seems to be dependent on the kernel driver. The more recent kernel driver and userspace library have ABI breakage. I believe we won't get legitimate DSP acceleration in stagefright until we have DSPBridge driver v0.2. DSPBridge v0.2 is a significant rewrite of the kernel driver and is not easily backported. I have already backported the DSPBridge driver from sholes' 2.6.32 kernel (DSPBridge v0.1) but it didn't seem to help.

I'm not looking at bluetooth until we have a 2.6.3x kernel. Occip has already tried to get it to work with 2.6.29 with only a small amount of success. FM radio doesn't have an antenna so its a no go.

I'm not entirely sure it will be compatible with the omap3621 but I will definitely try once we have a working DSP.

The VOME engine is a pretty serious task to integrate. If we decide to try to integrate it, I doubt we'll get this done anytime soon.

Is it snake oil when different settings break some apps? I don't expect miracles adjusting lcd density but Maps is broken at 160 with a 1024x600 display. However, other apps are broken with densities >160. It appears we will have to choose between Maps 5.1.x and properly sized applications.

Nope. There are newer drivers that probably won't help but we will try to backport to either the 2.6.29 or 2.6.32 kernel.

Right again, nothing works in CM7. There is nothing to play with...move along nothing to see here.

Perhaps I'm overly sensitive but asking "what is so snappy with the latest (8th) nightly"(emphasis added) comes off as having an attitude or negative connotation to me.

I'll give you the technical explanation why nightly 7 and 8 should be more "snappy."

The ondemand governor is pretty terrible for the ARM achitecture. Tests show that the ondemand governor has a significant performance penalty versus the performance governor(aka no governor). Ideally a cpufreq governor will have 100% of the performance of constantly running at max CPU clock speed while also being able to save power by scaling down when not needed. In practice the ondemand governor works pretty well for x86. Ondemand gets greater than 95% of performance of using no governor. However, on ARM performance can sometimes be cut in half. Especially, in tablet usage cases. We use our tablets and phones in I/O bound situations primarily. This means the CPU sits idle for the majority of the time waiting on a webpage resource to download or waiting for user input. This plays right into the ondemand governor's weakness on the ARM architecture. Ever notice swiping the homescreens of the launcher are choppy at first? This is a combination of the ondemand in 2.6.29 and the fact that we have a 1024x600 display. Try running the performance governor for a few minutes and notice how that choppiness is greatly diminished.

One of the primary issues causing this is the CPU state transition latency. Much of the performance penalty due to the ondemand governor can be fixed by lowering this latency. Though setting the latency too low will cause major problems. The latency set by default in the kernel is very conservative. Testing shows that the latency can be lowered by a factor of 10. This is what I've done with the CM7 kernel and my overclock kernel.

When I say the Nook should be more snappy I mean transitions and responsiveness. Computational intensive tasks should not be affected.