[Samsung Galaxy Nexus] Entropy512:
Yes, on AMOLED the power usage is reduced for a black pixel.

HOWEVER: Do note that most of the items in the Android battery usage screen are estimates, and those estimates do not take into account corner cases where rules have exceptions. The Android method for estimating display power usage is derived ONLY from the display brightness settings, it is not content-aware. It is also dependent on the manufacturer getting power_profile.xml right (luckily for you guys, this SHOULD be correct on a GNex. On other devices like the Galaxy S II, it has a bunch of holes that make me not trust a lot of it.) So any content-based (black wallpaper, etc.) power savings won't get taken into account in the battery usage estimates.

As to the other discussion relating to tradeoffs between idle states - I think Ezekeel has a great concept in terms of trying to choose clock frequencies using additional metrics beyond CPU load. The problem is that without good estimates for all states, one must be careful not to create a governor that has "corner cases" where it just goes out the window. I think in its current state, Wheatley has some nasty flaws but it DOES have quite a bit of potential, especially on OMAP4 where you can hit your deepest idle state fairly rapidly. (I'm not sure if it'll ever be useful on, for example, Exynos, where our deepest idle state has a target_residency of 40ms, AND that state has lots of odd restrictions on when it can be entered so you're not even guaranteed to hit it when the cpuidle menu governor decides it's available.)

The formula for CPU power consumption is something like:

P = (static power constant * dynamic power constant*frequency) * voltage^2

So in a CPU with no idle states, you want to keep your frequency as low as possible for two reasons:

1) The lower the frequency, the lower the voltage you can apply, which reduces both static and dynamic power

2) The lower the frequency, the lower the dynamic power constant

Of course, idle states drastically alter the formula in unpredictable ways. Basic clock gating reduces the dynamic power significantly. Depending on how a given idle state works, power gating could come into play, affecting static power too.

Keep in mind that in the above equation, you can rewrite it a bit (basically, divide everything by time per clock tick) and wind up with a different way of looking at things, effectively "energy per clock tick" - this is your cost to do work.

That one is going to be:

Etick = )(something related to static power that makes my head hurt) + (constant related to power-per-clock-tick))*voltage^2

Since your voltage is dependent on clock frequency - no matter what you do, ramping up to maximum clock is going to maximize (bad) your cost-per-unit-of-work.

FYI, this is the whole idea behind ARM's big.LITTLE approach of a paired Cortex-A7 and Cortex-A15 - the A7 is "slow" but its cost-per-unit-of-work is MUCH lower than the A15. Nvidia's Tegra3 "companion core" is a similar idea except achieved using different process technology instead of a different core architecture for the low-power core.

So a governor that takes sleep states into account can provide some interesting benefits - but those benefits require careful consideration of the CPU architecture and what factors contribute to power consumption.

(This is why the overhyped blind port of Wheatley to the Galaxy S 2 by an irresponsible kernel developer is something I consider to be stupid - there are too many differences between OMAP4 and Exynos for this to work properly, especially considering the craptastic state of sleep support in Gingerbread Exynos kernels.)

As an example on the Galaxy S II - some kernel developers added 100 MHz support to kernels based on the "old way" of thinking of things. Since 100 MHz only allows minimal voltage reductions compared to 200 MHz - it actually uses more power in nearly all cases because the CPU never hits the deeper idle states. Static power dominates even at 200 MHz.

However, as you get higher in frequency, voltage and dynamic power dominate the power consumption. So 200 MHz vs. 500 MHz provides some power savings, 500 vs 800 even more, and so on.

So an "idle-aware" governor could hit a "sweet spot" on some workloads where ramping up a step or two would be good - however I believe a "start at maximum and work down" approach will lead to increased power consumption in many scenarios.

And this all reminds me that I need to put together an order from Sparkfun and build a dummy battery.