returning B_SKIP_MESSAGE in my filter let capslocks get through anyway

[stpere]

Here is a filter I'm trying to get working. I can't seem to get around the fact that even if I return B_SKIP_MESSAGE on the right keypressses (I display an alert, to be sure..), the keypress gets through. I suspect a bug in the keyboard device in input_server.

[stpere]

My filter that is supposed to block capslock (the real usage will be to only allow capslock when I'm pressing left shift at the same time)

[leavengood]

I will take a look.

[stpere]

Header file for this filter

[axeld]

The filter is only called after the device had its go, so if there is a bug, it will be in the input_server itself.

[axeld]

BTW instead of specifically testing against some shift key (also, according to our coding style, that would be fShiftPressed instead of _shiftPressed :-)), you can also just check if B_LEFT_SHIFT_KEY is part of the modifiers in B_MODIFIERS_CHANGED.

[korli]

Does this work on R5 ? Because at the moment, the keybord input device addon manages its modifiers state alone, it doesn't check the one from the input_server. Which means that the B_MODIFIERS_CHANGED message will be skipped because of the Capslock filter. But still Capslock will be on.

[leavengood]

Continuing my work on old tickets, I've looked into this more. As korli says, the keyboard device manages the modifiers within itself and also sends the B_MODIFIERS_CHANGED message which gets forwarded to filters by the input_server. But by the time the filters get the message, it is too late to stop the modifiers from being changed. Also I think in general Be did not design this as the sort of message that can be stopped, it is just informative.

In addition, the key down message which would turn on caps lock (or other locks) cannot be intercepted or stopped before the modifiers are changed. This is because the modifier handling is done before the key down handling, and in addition there is not currently any way to stop the keyboard device from getting a key press (which is probably a good thing.)

Given that the behavior wanted in this ticket is actually not bad (avoiding accidental Caps Lock by requiring left shift held), I'd be up for adding it as an optional feature. But since some people may not like that, I also think this is possible to accomplish with the current system.

While looking around the source code to figure this out, I found the set_keyboard_locks function in InterfaceDefs.h. I think that instead of trying to stop the caps lock from being turned on, you can just immediately turn it off with set_keyboard_locks if shift was not pressed. I imagine it would happen so fast that the keyboard caps lock light might not even turn on. In addition you could track the modifiers in your filter and block B_MODIFIERS_CHANGED if nothing has changed except caps lock.

Given that stpere is now a Haiku committer I'll leave that exercise up to you :)

I'll leave this ticket open for now, but please try this and let me know if it works so we can close this.

[leavengood]

Also while using my MacBook Pro I noticed that there is a slight delay when pressing the caps lock before it actually turns on (but when on a quick press will turn it off.) Based on searching this seems to be a ​feature of Apple keyboards. But this might also be another nice (optional) feature to add to Haiku to make caps lock less annoying.

[Pete]

Revised Filter code that disables CapsLock unless the Ctrl key is held. (No header file needed)

[Pete]

On Ryan's suggestion I took a look at this, and have got it working to my satisfaction. I chose to use the Ctrl key, rather that Shift, as the enabler, because a lot of my accidental CapsLocks are when I was aiming for the Shift! Ctrl is one key further away, so should not be hit by mistake. Source attached as CapsLockFilter.2.cpp.

The original approach -- looking for Key Down/Up messages for Shift -- doesn't work, because modifier keys don't send these messages. Instead, this code looks directly at the state when B_MODIFIERS_CHANGED is sent.

[leavengood]

Since it looks like my old suggestion works in Pete's code I am going to close this issue.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed