Random Linux trivia/story: Back in 2002, I was trying to measure the impact of various long-held spinlocks in the kernel. By random chance, I noticed there was a huge latency spike when I enabled caps-lock. It turns out that it takes about 7 milliseconds to turn a PS/2 keyboard's caps lock LED on (or any of the other LEDs), and the kernel stops what it's doing and waits for it to complete regardless of whatever else it could be doing.
There's a command-line tool to turn the LEDs on or off (I forget what it's called), so I integrated that into a test script we used that measures timer latency with various background loads. (We had our own high-resolution timer implementation based on the APIC.)
I wonder what the latency effect of changing the lights over USB is? Whether it's done at the next polling interval or forces a HID "output report". (The command-line tool you mention is probably xkbleds)
For some reason this discussion reminds me of the way the ZX spectrum handled tape input by using a single bit of a register that was shared with the three bits of screen border colour. Because the default tape loader accumulated bits there by shifting the register along at timed intervals, the data loaded produced patterns in the screen border.
It didn't have any keyboard LEDs, but the Spectrum did have at least five different input "shift" states - the keyboard was modal and auto-tokenizing.
I assume that the usb keyboard driver is completely different code and is unlikely to have the same problem. (One would expect the generic usb implementation to be more carefully designed, since there are so many kinds of usb devices, each with their own unique ways of causing or being adversely affected by scheduling latency.) I haven't done the test, though.
In general, this sort of problem is less of an issue now since the transition to multi-core processors means that a long-held spinlock doesn't actually block all progress on the machine. There are usually plenty of other available cores and it's unlikely that unrelated processes are all stuck at the same time.
I created an Erlang script that allows you to send messages by morse code to the keyboard like this:
./remote_morse "HI,IAMSAM."
(Spaces don't appear to be used in morse code?)
The messages won't be differentiable while the site is under HN-level traffic, but in a few months, you should be able to send arbitrary messages to @lelandbatey using this.
Keyboard lights were pretty useful for debuging back in Turbo Pascal days.
XT had only 640K memory. Borland managed to fit IDE into this memory with code assistant and interactive debugger. But if your program consumed too much memory, IDE would not fit and you had to use other means for debugging; there was speaker, printer and keyboard lights.
This is awesome! I believe it was Bob Metcalf at PARC had a box in his office that would go 'click' when there was a collision on the network. At the time there was great debate that a network where packets could collide would ever be useful (the big competitor, token ring, use to harp on this endlessly). So he rigged it up to click when there were collisions. It sounded a bit like a geiger counter but the relevant bit was it did not sound like a buzz saw (all collisions all the time).
The idea of having a light go off when your network sees certain packets sounds like it could be an art project for a Raspberry Pi :-)
Look at the pricing though. pretty doubtful that it'll take off with a $230 pricetag. there'll never be enough developers keeping the plugins up-to-date to actually leverage it with all your software. And you'll constantly need to (re-)configure it... and forgetting what letter color symbolizes what will be the next problem.
this is a prime example of a product that looks really nice in theory, but would really suck in practice.
Some time ago I worked on a tool for powering on and off USB hub ports. Most hubs don't have the circuitry for the power to work, but you could blink the lights. Hubs might make a nice set of indicator lights for something like this.
There's a command-line tool to turn the LEDs on or off (I forget what it's called), so I integrated that into a test script we used that measures timer latency with various background loads. (We had our own high-resolution timer implementation based on the APIC.)
http://jsnow.bootlegether.net/rtas2002.pdf