Report accurate state of * lock keys

[boppreh]

Caps lock, num lock, scroll lock are all toggle modifiers, so if their state is unexpected at the start of the program it'll never be fixed. There should be a way to poll their actual status.

This may be expanded to include other modifiers, so the library starts more ready.

This may require update the functions that handle modifier keys, to take into account 'toggle' keys too.

[boppreh]

https://msdn.microsoft.com/en-us/library/ms646301(VS.85).aspx

http://jwilk.net/software/python-keyboardleds

[glitchassassin]

Taking a poke at this tonight to see what it will take. The Windows piece looks easy.

On OSX, caps lock is the only relevant "lock" as num/scroll don't actually have corresponding keyboard states.

The xset command does identify num lock state, e.g. with xset q | grep LED, at least on OSX and I believe on Linux as well. But I'll play around with the keyboardleds sample and try to poll the device itself instead to see if that will work reliably.

edit: xset is installed with XQuartz and isn't part of the standard OSX distribution, so this is not a viable solution on non-Linux platforms.

[glitchassassin]

Incidentally, investigating this, I've discovered that the current code for OSX doesn't actually toggle the capslock state - it just functions like a shift modifier. A quirk of the API, there's probably another way to actually toggle the state for the device.

[glitchassassin]

Aha. Carbon.GetCurrentKeyModifiers() will do the trick on OSX.

[glitchassassin]

Opened PR #263 to track this work. I have Windows and OSX drafted, and I'm spinning up a Linux VM to test the snippets I've found for Linux.

[glitchassassin]

I was not able to get the keyboardleds sample working consistently in non-TTY terminals (e.g., Gnome Terminal). Instead, I opted to call xset and parse the reported LED Flags. This should work at least for any X-based Linux GUI.