Show HN: Blink my keyboard lights when you visit this page • Hacker News Board

Re: Show HN: Blink my keyboard lights when you visit this page

#21

Post by pjc50 » Mon, Jan 02, 2017, 1:18 PM UTC

elihu wrote: post #3

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…

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.

Re: Show HN: Blink my keyboard lights when you visit this page

#22

Post by codazoda » Mon, Jan 02, 2017, 1:32 PM UTC

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.

https://github.com/codazoda/hub-ctrl.c

Re: Show HN: Blink my keyboard lights when you visit this page

#23

Post by elihu » Mon, Jan 02, 2017, 7:00 PM UTC

pjc50 wrote: post #21

elihu wrote: post #3

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…

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 load…

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.