[Bug] One-shot Shift and Caps Lock not working with Unicode Map's XP on Linux

[precondition]

Description

I use QMK's Unicode Map feature on Linux (more precisely on Xubuntu) to input accented characters, and as such I am using the XP macro. However, when it comes to capital accented characters, using shift works but one-shot shift and caps lock do not have the expected behaviour.

In the case of the One-Shot Shift, it seems to simply ignore the shift state and produce the lowercase unicode character instead. Note that the One Shot modifier still gets consumed when hitting a XP() key.

In the case of Caps Lock, it is correctly sending the uppercase unicode key but the problem is that Ctrl+Shift+U to input Unicode characters does not work when Caps Lock is activated (which is an issue outside of QMK). Temporarily "swapping" Caps Lock for Shift when typing a capital XP() key could be a potential solution to bypass the problem.

System Information

• Keyboard: Dactyl Manuform 5x6
• Operating system: Linux - Xubuntu
• AVR GCC version: 5.4.0
• ARM GCC version: (15:6.3.1+svn253039-1build1) 6.3.1 20170620
• QMK Firmware version: 0.9.7
• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other: AutoKey

Additional Context

I use One-Shot Shift in the context of a double tap of the dot key which produces "DOT SPACE OSM(Shift)".
I have not enabled the Key Lock feature.
The OS layout is set to US Qwerty

[Ceremony64]

I think XP is broken independent of the underlying OS (I'm on Windows with WinCompose).

I recently updated my Keyboard from some ancient qmk source (~1 year old?) to the current master and now XP is broken for me as well:
Lets assume this unicode map which essentially implements "a" and "A" manually with XP(a,A):

enum unicode_names {
  a,
  A
};

const uint32_t PROGMEM unicode_map[] = {
  [a] = 0x0061,
  [A] = 0x0041
};

It seems to cache shift/caps when pressing XP(a,A) and delays its effect:
Holding shift and then pressing the XP key causes a lc "a" instead of uc "A". Pressing XP again without letting go of shift finally prints uc "A" and every extra shift+XP prints that. Now, when letting go of shift, pressing XP again still prints uc A instead of lc "a", only the second character is the correct lc "a". Also, after holding shift while pressing XP (-> lc "a") and letting go of shift, will not cause an uc "A" when triggering XP again.

[precondition]

Holding shift and then pressing the XP key causes a lc "a" instead of uc "A". Pressing XP again without letting go of shift finally prints uc "A" and every extra shift+XP prints that. Now, when letting go of shift, pressing XP again still prints uc A instead of lc "a", only the second character is the correct lc "a". Also, after holding shift while pressing XP (-> lc "a") and letting go of shift, will not cause an uc "A" when triggering XP again.

I personally do not notice such behaviour. XP works fine when used with my Shift Mod-Tap.

[Ceremony64]

mhh guess its another bug then. I'll open one

EDIT: Opened #9533

[spidey3]

I've done a bit of research on this, and it would appear that on Linux (and also ChromeOS) unicode entry using Ctrl-Shift-U codpoint Enter doesn't work at all when caps lock is on. To fix this, on Linux, QMK will need to temporarily turn off Caps Lock when sending unicode sequences.

[precondition]

I've done a bit of research on this, and it would appear that on Linux (and also ChromeOS) unicode entry using Ctrl-Shift-U codpoint Enter doesn't work at all when caps lock is on. To fix this, on Linux, QMK will need to temporarily turn off Caps Lock when sending unicode sequences.

Yep, as I said in the description of the issue here:

In the case of Caps Lock, it is correctly sending the uppercase unicode key but the problem is that Ctrl+Shift+U to input Unicode characters does not work when Caps Lock is activated (which is an issue outside of QMK). Temporarily "swapping" Caps Lock for Shift when typing a capital XP() key could be a potential solution to bypass the problem.

[spidey3]

With the merging of #11232 and #11220 this bug is completely fixed, and I think it can be closed.