On 10 Apr 2013, at 21:55, Richard Sanders wrote:

> Out of curiosity I did a bit of googling and found this.
> http://www.jveweb.net/en/archives/2010/11/making-better-use-of-the-caps-lock-key-in-linux.html
> It would seem that trying to trap cap locks could be fruitless because
> of key re mapping.

That's quite an interesting article, and mercifully short given the subject 

It had never occurred to me to fire up xev and see what the Mac hosted VM was 
actually seeing, so I just spent a little time staring at that. It's not 

It's also clear that there's *a lot* of "manipulation" of kbd events going on 
"under the covers" for the Caps Lock key - if I press a regular key (say "a") I 
get one press event and one release event, on the "a" key. Fine.

If I press and release Caps Lock, I get a veritable flurry or key press/release 
events (for the Caps Lock key), many with the same time stamp (and interleaved 
with events for the Shift_L, which of course I'm *not* pressing at all.)
The *next* key I press, after releasing the Caps Lock key, is *also* associated 
with a series of Caps Lock and Shift_L events, before the key I actually 
pressed appears... With the correct CAPS/lower state applied.

However, Num Lock; which to me seems conceptually similar, just delivers nice, 
clean key press/release events. (And updates the keyboard state.)

I have no idea why Caps Lock doesn't just do that too. Complicated stuff is 
happening under the covers...

However, for Howard's needs, it possibly does not matter - even key remapping 
may not really matter; I guess that he does not care which physical key is 
acting as Caps Lock, so long as he can detect whether the current keyboard 
state has Caps Lock on or off.

The difficulty is that, at least in my VM's, the keyboard state is not resolved 
fully until the next key after the Caps Lock toggle.

I assume, from the tests reported by others, that "real" PC's return less 
convoluted state and it more or less works?

fltk mailing list

Reply via email to