Left & right shift mapped to open & close parens in experimental firmware

[miwallr]

I’m using the experimental firmware, installed via Chrysalis. This was so that I can use the full modifier when held functionality etc., which isn’t enabled on the default firmware yet.

Over a week or so of (much enjoyed) usage, I noticed that the shift key was behaving strangely, e.g. in finder on mac, I often do shift mouse click to select multiple files. This was giving erratic behaviour, I tried another keyboard, and the other keyboard worked as normal.

Just now I’ve discovered that left and right shift are actually mapped to open and close parens, only on release; so, it’s effectively shift as modifier when held, otherwise parens.

However, this doesn’t show up in my Chrysalis key map display.
It’s quite a nice idea actually, I may try using these keys this way.
However, this seems to be an undocumented feature!

Also, I just tried mapping shift to another key (the any key). It also prints a paren when used as a normal key, but acts as shift when held. Same odd selection-click behaviour in finder.

Update: this is a very clever feature, and as far as I can make out not entirely possible to do in the current chrysalis ui, which may explain it.

The problem if I understand it correctly is that while it is possible to make a key be a regular key when tapped (here, 9), and a modifier when held (here, shift), the issue is that, if we want a key when tapped to emit the code for, say, ‘(’, then we need a shift on the tap (shift 9), plus a modifier when held as shift. That would seem to entail adding more to the Chrysalis ui, i.e. an additional row of modifiers above the current one which applied when tapped. i.e. the ui might look like this:

Thus, it is possible in Chrysalis currently to map, say, ‘[’ combined with left ctrl as modifier when held as here:

but we can’t do the same for ‘{’, which requires a shift, or parens, which is currently hardwired in this way onto shift with the experimental firmware (very nice…).

Update: I’ve found that the problem with shift click not working correctly in mac finder is solved by waiting for a short time between holding down shift and clicking - my habit had been to click almost immediately after holding shift, which doesn’t work in this case. But if one learns just to wait a short moment before the click, it works…

[merlin (Michael Richters)]

The firmware you’ve got appears to be using either Qukeys or SpaceCadet. I’m not as familiar with the internal workings of SpaceCadet, so I’m not sure, but Qukeys is consistent with the behaviour you’re describing. It’s also the plugin used for keys defined in Chrysalis as “modifier when held, normal key otherwise”. Qukeys can also be used to define keys that include modifier flags when tapped. However, Chrysalis can’t be used to configure Qukeys for those keys, unfortunately.

That limitation is not merely an oversight. The qukeys that can be configured in Chrysalis are special DualUse keys, and those keys only have eight bits to encode the keycode used when the key is tapped, rather than held. That means that there are no bits available to store modifiers that should also be held. Full-fledged Qukey definitions can send any Key value on both tap and hold, but use twice as much memory, and currently can only be stored in program memory, not in EEPROM (on the Model01). This means that changing those definitions requires flashing new firmware, and can’t be done in Chrysalis.

It’s theoretically possible to add that capability to Chrysalis, but it would mean adding quite a lot of code to Qukeys, which I’m not interested in doing unless some much more fundamental design changes are made to Kaleidoscope.

The good news (for your delayed shift problem) is that Qukeys is configurable. It’s likely that you can reduce the delay without causing any problems, making it easier to use those keys in combination with a mouse click. The default timeout value is 250ms, which is quite conservative. Unless you tend to hold keys down unusually long on a tap, it’s likely that you’ll have no problems even with a timeout as low as 100ms, like so:

Qukeys.seHoldTimeout(100);

That’s also only configurable in the firmware, not via Chrysalis.

[flussence]

I’ve got the [{()}] keys mapped to the thumb row using SpaceCadet. From the description, this doesn’t sound like the plugin being used there.

Something maybe worth pointing out though: the firmware has two different ways of defining () and {} keys: there’s regular ones that send shift + some other key to the OS, and Key_Keypad[Left|Right][Paren|CurlyBracket] that each send a single on-the-wire keycode. While the latter sound better in principle, I couldn’t get the {} ones to work for some reason; my notes say it’s “probably X11’s fault”.

(I had a Microsoft keyboard with separate () keys but I haven’t seen any with {} in the wild. Anyone know where they’re from?)

[algernon (Gergely Nagy)]

FWIW, the experimental firmware is built with the SpaceCadet plugin, but it is explicitly disabled in the latest build. It was always supposed to be disabled by default, and require a key to turn it on, but… mistakes were made, and some versions of the experimental firmware had it enabled by default.