Search Issue Tracker
By Design
Votes
0
Found in [Package]
0.0.9-preview
Issue ID
1091536
Regression
No
[OSX][Keyboard] When Caps Lock is active, the key is always read as pressed.
Migrated bug from GitHub: https://github.com/Unity-Technologies/InputSystem/issues/143
The Control.ReadValue() is always bigger than 0 for CapsLock key when the cap lock is active, which also affects the Control.isPressed value.
This is different from the Windows standalone build.
Rene-Damm commented on Jun 15
Not sure we'll be able to get a different read here. Pretty sure that on the OS side, given that it's a key with a "lock" state, the press and release we get is for the lock state and not the key press. But maybe we can drop a level lower and look at the actual key state to still read press and release.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [Dragon Crashers] Build fails in U6
- [Dragon Crashers] 4 Shader error messages on import
- [Dragon Crashers] Readme text is white on light grey
- Cursor stays in front of the first character when entering text in the TextMeshPro field
- Searching in Hierarchy causes unwanted component calls
Resolution Note:
I think if there is a way to get this information, it would be to query the keys directly via HID. But I see too many downsides. HID does not let us map character info, it may not work consistently with all keyboards, and is generally harder to maintain. All that to read one key differently is not worth it, IMO. In the behavior seen on OS X is not "incorrect" - but it is different from windows. What we could consider if we want to make it consistent would be to make the behavior on windows match Mac (which would not require additional information). But I don't think that's worth it either.