Ah.. much better 
and before someone asks, no it's not photoshopped !
I used thesethese 0603 leds, not fun to solder. I bought some 0402 replacement resistors too, but looks like I don't need them - good thing, as I wasn't looking forward to soldering those..
and the objects of loathing
Now where did I put the hammer 
You guys are no fun! You're going to lose all your street cred by not liking Vega-luminosity blue LEDs!
Don't you know that retinal evaporation is just the price to be paid for blind peergroup reinforcement? And the adjective is there for a reason.
Like, er, being used literally. 
You guys are no fun! You're going to lose all your street cred by not liking Vega-luminosity blue LEDs!
Don't you know that retinal evaporation is just the price to be paid for blind peergroup reinforcement? And the adjective is there for a reason.
Like, er, being used literally.
There's actually a good issue raised by this wonderful topic, pointing to some extra work that needs doing. The fact that it wasn't possible to configure your requirements (or at least not easy to figure out how) despite these LEDs being programmable suggests that something is lacking.
Maybe it just requires better documentation, but it could also be that the drivers need more functionality, or better utilities, or better coordinated access to shared resources (not only LEDs) so that in-kernel uses like activity monitoring are under better control from user-space. And er, duty-cycle luminance control of course.
Be that as it may, I must say I've thoroughly enjoyed this. 
The kernels led subsystem is actually quite good and reasonably documented. It has hooks to all sorts of things, For example you can make a led flash on particular firewall activity.
There are also the controls available for brightness - haven't checked if that's available for gpio leds, ISTR reading something somewhere about needing an led controller chip for that.
Unfortunately I don't think it will ever be able to make a blue led turn red 
The more usual problem is finding where the distro have hidden the controls - even when you know where /sys/class/leds is, you still need to find out where the distro is overriding your settings.
For a primer on where the whole configuration of resources is going with device tree and overlays, there's a good post over on lkml here http://permalink.gmane.org/gmane.linux.kernel/1389017 and it seems to be largely driven by the needs of beaglebone capes.
The interesting bit that's mentioned is the possibility of the user to override everything at run time without a reboot. That's exactly the sort of thing I'm looking for, and anyone with a breadboard cape that has no eeprom will likely want too.. However I've yet to track down any details of exactly how to do it.
None of that stuff has actually made it into the kernel.org kernel just yet, so we're getting a first look at it on BeagleBone-Red now. I suspect it will evolve into something more useable as it progresses.
