# Qukeys and shiftToLayer

**URL:** https://community.keyboard.io/t/qukeys-and-shifttolayer/2562
**Category:** Help and Getting Started
**Tags:** question, plugin
**Created:** [February 20, 2019, 9:40am UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562 "2019-02-20T09:40:02Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 9:40am UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/1 "2019-02-20T09:40:02Z")

</div>

After a long time I started working on my firmware sketch again. Finally I found the time to try out Qukeys. There are some minor difficulties I ran into that I hope some other experienced Qukeys users might help me with.

I want to put modifiers on the homerow, say shift on F and J (QWERTY). With the standard settings taken from the example for timeout (200) and release delay (20) this does not work as expected. When I intent to type capital F and G, in most cases the letters end up lower case. Is there a general problem when combining keys that are both Qukeys or are there maybe better values for timeout and release delay that I could use?

Another problem that I am facing is that I have a Qukey that shifts to a higher layer where the same key is supposed to be non-transparent. It seems as in such a scenario, the shifted-to layer gets stuck. Is that a known limitation or am I doing something wrong? I found an [old thread](https://community.keyboard.io/t/qukey-for-shift-to-numpad-woes/1752) that seems to be related.

[Edit: In the first version of this post I wrote F and G. I actually meant F and J, which means that I place the Qukey shift on both forefingers.]

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 1:30pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/2 "2019-02-20T13:30:41Z")

</div>

I think you’re probably seeing [Kaleidoscope issue #501](https://github.com/keyboardio/Kaleidoscope/issues/501), which is fixed by PRs [#502](https://github.com/keyboardio/Kaleidoscope/issues/502) & [#505](https://github.com/keyboardio/Kaleidoscope/issues/505), which are waiting to be merged.

It would be great if you could test out #502, in particular (which #505 relies on), because it might break something in Papageno.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 1:37pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/3 "2019-02-20T13:37:37Z")

</div>

Regarding the timeout settings — When you try to type `F`, are you seeing just one letter (`f`) when you do it, or are you getting both (`gf`)? I’ll see if I can come up with a solution, or at least an explanation. Am I right that your habit with modifier chording is to release both keys simultaneously?

[edit: `s/fg/gf/`]

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 2:14pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/4 "2019-02-20T14:14:34Z")

</div>

Thanks for the quick reply. I tried #505 and #502. They both independently seem to fix the shiftToLayer-problem. That’s great news.

Don’t worry about Papageno. Due to a lack of time I had to abandon the work on its Kaleidoscope-integration last summer. Back then I could not find a way to get it working without changes to Kaleidoscopes hid report handling. In the meantime there were quite some changes to the firmware and lately I have followed discussions about alternative strategies for hid reporting. I am happily using a ErgoDox EZ with Papageno integration. With QMK it was comparably easy to get things working. I hadn’t expected it to be that complex with Kaleidoscope whose architecture I favor.

In the meantime I am looking for a keymap that gives me all that I need without Papageno and Qukeys seem promising.

Regarding your questions about my typing habits. Those are difficult to answer. I will use a MIDI sequencer software to analyze my typing. Based on those bar-diagrams I might be able to answer your questions.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 2:50pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/5 "2019-02-20T14:50:04Z")

</div>

Unfortunately, I could not find a sequencer software that allowed me to quickly record using computer-keyboard input.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 2:53pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/6 "2019-02-20T14:53:38Z")

</div>

Re: Papageno and HID report handling – it’s conceivable that the problem is [the mid-cycle reporting problem](https://github.com/keyboardio/Kaleidoscope/issues/568). If so, I’ve also submitted a few PRs to give plugins to safely send reports mid-cycle without dropping information from keys that haven’t yet been processed. If that proposal gets adopted by Kaleidoscope, do you think Papageno might become practical?

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 3:03pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/7 "2019-02-20T15:03:45Z")

</div>

> [@merlin](#):
>
> If that proposal gets adopted by Kaleidoscope, do you think Papageno might become practical?

Right now I am lacking time to really concentrate on Kaleidoscope/Papageno. That’s why I cannot really answer your question. I submitted a PR [#311](https://github.com/keyboardio/Kaleidoscope/pull/311) last year that was meant to add what I needed. But maybe there is a smarter, less intrusive solution. I hope I can get back to this soon and then I will think it over.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 3:05pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/8 "2019-02-20T15:05:23Z")

</div>

> [@merlin](#):
>
> When you try to type `F` , are you seeing just one letter ( `f` ) when you do it, or are you getting both ( `gf` )?

Mostly I see just one letter, the lower case version of what I intended to type uppercase.

Do you use Qukeys in homerow?

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 3:10pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/9 "2019-02-20T15:10:45Z")

</div>

> [@noseglasses](#):
>
> Mostly I see just one letter, the lower case version of what I intended to type uppercase.

Aha! Unless you’re somehow failing to engage the G fully (which seems highly unlikely), that’s a bug, so it should be fixable. The only other way you should get just `f` is if you hold G long enough for it to time out (i.e. 200ms), then release it before pressing F. Also highly unlikey.

I will try to fix it today. Can you provide a link to your current sketch?

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 3:14pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/10 "2019-02-20T15:14:19Z")

</div>

> [@noseglasses](#):
>
> Do you use Qukeys in homerow?

I do…but as I’m just finishing the third of my three “essential” Kaleidoglyph plugins, I still haven’t got around to using my Model01 as my primary keyboard, so I do very little actual typing on it.

Also, I’m certain that I type very, very slow compared to you. Top speed (unsustainable) for me is maybe as high as 40wpm, and I’m habitually very deliberate about releasing modifiers _after_ the keys they modify.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 3:23pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/11 "2019-02-20T15:23:10Z")

</div>

> [@merlin](#):
>
> Aha! Unless you’re somehow failing to engage the G fully (which seems highly unlikely), that’s a bug, so it should be fixable. The only other way you should get just `f` is if you hold G long enough for it to time out (i.e. 200ms), then release it before pressing F. Also highly unlikey.
> 
> I will try to fix it today. Can you provide a link to your current sketch?

I did some more typing experiments. Sometimes I get only one lower case key, sometimes both. That’s why I would like to record as precise as possible what I am actually doing. Last year I successfully used my keyboard-simulator to track down errors in the Papageno-integration. This could also help with Qukeys if it is actually a bug. But for this to work I need precise measured data of cases where something actually goes wrong.

I will start a new topic, asking for ideas about how to measure key sequences. As long as I am not sure what’s going on, let’s treat it as a timing issue, thus no need for you to start fixing it.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 3:24pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/12 "2019-02-20T15:24:53Z")

</div>

> [@merlin](#):
>
> Also, I’m certain that I type very, very slow compared to you. Top speed (unsustainable) for me is maybe as high as 40wpm, and I’m habitually very deliberate about releasing modifiers _after_ the keys they modify.

I am not a very fast typist as well maybe around 60wpm and I am probably quite sloppy. But I don’t mind doing some training to get accustomed to something new.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 3:31pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/13 "2019-02-20T15:31:39Z")

</div>

> [@noseglasses](#):
>
> I will start a new topic, asking for ideas about how to measure key sequences. As long as I am not sure what’s going on, let’s treat it as a timing issue, thus no need for you to start fixing it.

I’m not as adept as I ought to be with debuggers, so I generally puzzle things out in my head while looking through the code (more or less, I run an emulator in my brain). So I’ll probably start looking at it anyway, but I’ll wait for more information on the trigger if nothing occurs to me right away.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 3:36pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/14 "2019-02-20T15:36:09Z")

</div>

> [@noseglasses](#):
>
> I am not a very fast typist as well maybe around 60wpm and I am probably quite sloppy. But I don’t mind doing some training to get accustomed to something new.

The main thing that _should_ help make Qukeys work reliably is always releasing the modifier after the modified key. I did my best to make it work for “simultaneous” releases, but there’s only so far that will go.

This bug is probably a corner case involving the release grace period, which didn’t even occur to me would be useful because of my own habits.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 3:58pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/15 "2019-02-20T15:58:01Z")

</div>

If I type the two Qukeys for shift (assigned to the two forefingers in homerow, F and J on QWERTY) in a sequence press F (that’s supposed to be the modifier), press J, release F, release J the keyboard outputs nothing. This appears to be, as far as I can reproduce it, independent of timing. No matter if I do it fast or slow, no key is output. On the other hand everything works as expected if the key whose character is supposed to be capitalized is not a Qukey.

My current sketch that uses Qukeys is here: [https://github.com/noseglasses/Noseglasses-Model01-Firmware/tree/with\_qukeys](https://github.com/noseglasses/Noseglasses-Model01-Firmware/tree/with_qukeys)

In the above examples I use QWERTY-keys while in reality I am a Norman-Layout-typist. That’s why in the sketch the two forefinger-keys are T and N.

BTW, I corrected my initial post where I wrote F and G instead of F and J for QWERTY.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 4:17pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/16 "2019-02-20T16:17:18Z")

</div>

> [@noseglasses](#):
>
> If I type the two Qukeys for shift (assigned to the two forefingers in homerow, F and J on QWERTY) in a sequence press F (that’s supposed to be the modifier), press J, release F, release J the keyboard outputs nothing. This appears to be, as far as I can reproduce it, independent of timing. No matter if I do it fast or slow, no key is output. On the other hand everything works as expected if the key whose character is supposed to be capitalized is not a Qukey.

I’m confident that I’ll be able to fix this. It’s possible there’s another bug in there, too, though.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 4:45pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/17 "2019-02-20T16:45:47Z")

</div>

I had to comment out FunctionalColor from your sketch because I was getting linker errors, and I’m using my fixes for the Qukeys layer-shift bugs (#505) instead of the master branch of Kaleidoscope, so I may have an important difference in my version of your sketch, but I’m suspecting this could be a configuration issue.

If I’m fast enough, I can get both letters, but if I’m a bit slower with both keys, I get just the modifiers. When I turned up the timeout value to 1s, like so:

```auto
   Qukeys.setTimeout(1000);

```

…I could more easily control the timing, because the qukey wouldn’t fall into the alternate state prematurely, and I got all the expected behaviours.

The Qukeys timeout is mainly there so that you can use a Qukey as a modifier in combination with another input device (i.e. modified mouse clicks). It’s not meant to be the factor that decides which state the Qukey falls into – ideally, that’s only determined by the order of key press and release events. So it’s generally okay to set it to a pretty high number if you don’t mind waiting a bit to use those modifiers with a mouse (or whatever).

I recommend trying out higher timeout values and see if that helps. Maybe FunctionalColor slows down the scan cycle by enough to have an effect, though I doubt that. It’s also possible that it has some interaction with Qukeys, but that also seems unlikely.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 20, 2019, 5:10pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/18 "2019-02-20T17:10:16Z")

</div>

Increasing timeout to 1000 ms already helps a lot. Now as I know in which order I need to release the keys to generate uppercase letters, I will train a bit. Let’s see if this is more successful than the attempt I made two years ago with Dual Use keys on QMK where I finally gave up.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [February 20, 2019, 5:15pm UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/19 "2019-02-20T17:15:42Z")

</div>

I imagine that, for some people, it would work best to have `shift` keys on the thumb arcs, but other modifiers would work fine on the home row.

---

<div class="post-metadata">

### Author: ![noseglasses](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/noseglasses/32/429_2.png) [@noseglasses](https://community.keyboard.io/u/noseglasses)
#### Post date: [February 22, 2019, 9:31am UTC](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562/20 "2019-02-22T09:31:32Z")

</div>

I finally moved shift back to the thumb keys as you suggested. The other modifiers on the remaining fingers of homerow are less problematic as I tend to enter chorded shortcuts much slower and less sloppy than I usually type. Only in rare cases I accidentally enter a shortcut and suddenly something unexpected happens (like the editor trying to close a window with unsafed work 😉) but I am getting more and more accustomed to this setup and find it pretty convenient. It feels much better than what I had when I tried the same with QMK and DualUse keys.

Qukeys are really great. Thank you @merlin for all the work you put into their development and maintenance!

[Next page](https://community.keyboard.io/t/qukeys-and-shifttolayer/2562.md?page=2)
