Curly braces don't unshift right away about model01-firmware HOT 11 CLOSED

Now, there may be ways to fix this. For example, we could release shift (and the keys it was chorded with), provided they were triggered by a single key (eg, LSHIFT(Key_A) would trigger this, but Shift + A would not), as soon as any other, non-shifted key is pressed.

This would allow { to repeat, pressing [ later would stop } from repeating, and [ would start. Trilling would also work.

The downside of this is that the code required for this may be a tad complicated, at least that's my gut feeling.

This is exactly what I have in mind for the "Unshifter" plugin that I have planned, but isn't done. The hard part is that it's impossible to tell for sure where the shift bit in the HID report came from, so I was planning on implementing a keycode mask for the report. It would work the same was as the keyswitch mask – unmasking automatically when the keycode(s) stop appearing in the report on the input side.

This would require (in my opinion) a redesign of the hooks, with a true pre-report hook that gets called whenever a HID keyboard report is about to be sent.

from model01-firmware.

This also misbehaves if you try to type }\ too quickly: you get }| instead.

from model01-firmware.

from model01-firmware.

Ubuntu 14.04, with the version of the firmware that came pre-installed on my Keyboardio. (S/N 010049 if that is relevant)

from model01-firmware.

@algernon @bergey - This is the -opposite- of the problem we had just after PVT, right?

from model01-firmware.

I can reproduce this, and there is a perfectly clear explanation for why this happens. The good news is, this is not necessarily a bug (depends on how you look at it)!

I reproduced with trilling } and [, which sometimes resulted in }{. So I added some key logging, and it turns out that this happens when [ is pressed while } is still releasing, but has not released yet. This means that the Shift is still pressed, so that's why [ gets it too. It's like if you were typing very fast, and you released shift, but the key is travelling up, and you hit another key: shift will still be applied, even though your finger is not on the key anymore.

This is exactly what happens here.

from model01-firmware.

Now, there may be ways to fix this. For example, we could release shift (and the keys it was chorded with), provided they were triggered by a single key (eg, LSHIFT(Key_A) would trigger this, but Shift + A would not), as soon as any other, non-shifted key is pressed.

This would allow { to repeat, pressing [ later would stop } from repeating, and [ would start. Trilling would also work.

The downside of this is that the code required for this may be a tad complicated, at least that's my gut feeling.

from model01-firmware.

@obra What do you think about my idea above? Would this be a desirable feature? If so, I'll have a go at implementing it.

from model01-firmware.

from model01-firmware.

Do you even have to send the shift-on and shift-off scancodes at all? There is a shift bit attached to each character scancode, isn't there? Are there some OSes that won't respect that unless you've sent the shift-on scancode before it?

from model01-firmware.

from model01-firmware.