[Linux] Bug: Ö only with right shift key

[MaxGyver83]

I found a strange bug: I can only emit a capital Ö using the right shift key. The left shift key works for others letters, though.

Minimal config for testing:

(defcfg
  ;; For Linux
  input  (device-file "/dev/input/by-path/platform-i8042-serio-0-event-kbd")
  output (uinput-sink "KMonad output"
    "/bin/sleep 1 && /bin/setxkbmap us -option compose:ralt")

  fallthrough true
)

(defsrc          lsft ; rsft)
(deflayer level1 lsft ö rsft)

If you test this on a US keyboard, press shift + ;.

(Same problem when I remove lsft and rsft from the config.)

[david-janssen]

That's a cool bug you've found. I am going to leave this open until I find some time to test this, but well spotted!

[tyalie]

I know this is off-topic, but how did you @MaxGyver83 manage the permissions on the by-path device? Mine is in root:root and I'm yet unwilling to start the service with root permissions at boot time.

[MaxGyver83]

Hi @Gansgar ,
have you seen the section about uinput permissions in the FAQ?
On my machine, /dev/input/by-path/ belongs to root:root, too. But this seems not to be a problem here.

[tyalie]

Yeah have seen it. I thought it's mostly needed, when uinput doesn't exist yet.

Edit: I'm stupid. /dev/input/by-path is 777... It's only uinput write access that is causing trouble.

[focusaurus]

@Gansgar FYI I run this as my own user with a systemd user unit. File is here if you want to study and adapt for your specifics.

[tyalie]

I can confirm, that I've the same issue when using Compose Key Sequences.

[slotThe]

I'm pretty sure that this is due to the way we emit Unicode on X11 (via
tap macros) and ultimately how these macros are handled; not only by
use, but also by QMK (at least on my board). The TL;DR is that
Unicode sucks pressing buttons twice without releasing them first
really messes things up.

Try it yourself: hold down a button that's part of some macro (e.g. I
have a macro for <$>, so if I hold down $ and press that button I
will only get a <> instead). This is because when a key is already
held down, pressed it again doesn't do anything (this also means that
the "second" release when we really release the key is a unit action).

Because we are handling Unicode entry via compose-key sequences and
those use the left shift key for the entry, hence if we use the left
shift key trying to get a capital Umlaut we run into exactly that same
issue.

A possible solution could be to somehow keep track of the history of
button presses¹ and then do smart™ things in case a button that's
present in the macro is pressed already (although even now I can think
of situation where there's no smart thing to do...) However, we are
currently deciding on the general structure of the macro when joining it
(in the J monad) and we obviously do not have the needed additional
information until runtime (which would be something like RIO KEnv).

This touches upon a lot of internals, and I'm not familiar enough with
the code base as a whole right now to say whether there is a good
solution for this. Maybe someone else can weigh in here, if not I'll
definitely come back to this from time to time as I get more familiar
with the code base.

¹ We are currently doing this within a BEnv, but the problem is that,
as least as far as I can tell, this is only for the immediately
enclosing environment (i.e. If we press shift, layer3 this would
already be a little bit hairy).