Keyboard keys < and > do not work

[danisla]

Pressing either < or > results in > being pressed on the remote.

This breaks tasks like writing HTML in the session.

May need to re-write the python keyboard input handler to use the Xlib directly rather than relying on pynput to do the right thing.
Example

[ehfd]

Proposed workaround is adding sudo xmodmap -e "keycode 94 shift = less less" to the OS where selkies-gstreamer is running. @danisla
Might be a change in the entrypoint instead of the source.

[ehfd]

Example:
selkies-project/docker-nvidia-glx-desktop@22bd4ca#diff-6f9d41d046756f0ddc2fcee0626bdb50100d12b88f293734eff742818e03efa2R88
selkies-project/docker-nvidia-egl-desktop@d7691bc#diff-6f9d41d046756f0ddc2fcee0626bdb50100d12b88f293734eff742818e03efa2R42

[ehfd]

xmodmap -e "keycode 94 shift = less less"
Need to understand how this can be integrated to the main code.

Relevant code: https://github.com/selkies-project/selkies-gstreamer/blob/master/src/selkies_gstreamer/webrtc_input.py

[ehfd]

https://github.com/boppreh/keyboard
https://github.com/boppreh/mouse
https://github.com/maliit/keyboard
Looks interesting.

[ehfd]

So far:
input.js of gst-web sends 60 as < and 62 as > correctly with the below debug check. Therefore, it is not something with the Guacamole Keyboard module.

        // Using guacamole keyboard because it has the keysym translations.
        this.keyboard = new Guacamole.Keyboard(window);
        this.keyboard.onkeydown = (keysym) => {
            console.log("keyboard symbol down: ", keysym);
            this.send("kd," + keysym);
        };
        this.keyboard.onkeyup = (keysym) => {
            console.log("keyboard symbol up: ", keysym);
            this.send("ku," + keysym);
        };

When using keyboard test with noVNC instead of Selkies, input is definitely correct.

Receiving the keysyms in webrtc_input are also done correctly, where < receives 60 and > receives 62.

        logger.warning(str(msg))
        toks = msg.split(",")
        if toks[0] == "pong":
            if self.ping_start is None:
                logger.warning('received pong before ping')
                return

[ehfd]

Xorg keycode should be 59 if we are to type < properly. But it gets 94 out of nowhere, which corresponds to a different type of key that shows < when without shift and > when with shift.

>>> from Xlib import display
>>> xdisplay = display.Display()
>>> keycode = xdisplay.keysym_to_keycode(60)
>>> print(keycode)
94
>>> print(xdisplay.keysym_to_keycode(62))
60
>>>

[ehfd]

From an ancient x11vnc documentation from 2010:

   Q-88: When I try to type a "<" (i.e. less than) instead I get ">"
   (i.e. greater than)! Strangely, typing ">" works OK!!

   Does your keyboard have a single key with both "<" and ">" on it? Even
   if it doesn't, your X server may think your keyboard has such a key
   (e.g. pc105 in the XF86Config file when it should be something else,
   say pc104.)

   Short Cut: Try the -xkb or -sloppy_keys options and see if that helps
   the situation. The discussion below is a bit outdated (e.g. -modtweak
   is now the default) but it is useful reference for various tricks and
   so is kept.


   The problem here is that on the Xserver where x11vnc is run there are
   two keycodes that correspond to the "<" keysym. Run something like
   this to see:

  xmodmap -pk | egrep -i 'KeyCode|less|greater'
  There are 4 KeySyms per KeyCode; KeyCodes range from 8 to 255.
      KeyCode     Keysym (Keysym) ...
       59         0x002c (comma)  0x003c (less)
       60         0x002e (period) 0x003e (greater)
       94         0x003c (less)   0x003e (greater)

   That keycode 94 is the special key with both "<" and ">". When x11vnc
   receives the "<" keysym over the wire from the remote VNC client, it
   unfortunately maps it to keycode 94 instead of 59, and sends 94 to the
   X server. Since Shift is down (i.e. you are Shifting the comma key),
   the X server interprets this as Shifted-94, which is ">".

   A workaround in the X server configuration is to "deaden" that special
   key:

  xmodmap -e "keycode 94 = "

   However, one user said he had to do this:

  xmodmap -e "keycode 94 = 0x002c 0x003c"

   (If the numerical values are different for your setup, substitute the
   ones that correspond to your display. The above xmodmap scheme can
   often be used to work around other ambiguous keysym to keycode
   mappings.)

   Alternatively, here are some x11vnc options to try to work around the
   problem:
   -modtweak

   and
   -remap less-comma

   These are convenient in that they do not modify the actual X server
   settings. The former (-modtweak) is a mode that monitors the state of
   the Shift and AltGr modifiers and tries to deduce the correct keycode
   sequence to send. Since Jul/2004 -modtweak is now the default. The
   latter (-remap less-comma) is an immediate remapping of the keysym
   less to the keysym comma when it comes in from a client (so when Shift
   is down the comma press will yield "<".)

   See also the FAQ about the -xkb option as a possible workaround using
   the XKEYBOARD extension.

   Note that the -debug_keyboard option prints out much info for every
   keystroke to aid debugging keyboard problems.

[ehfd]

And the x11vnc man:

-modtweak, -nomodtweak

Option -modtweak automatically tries to adjust the AltGr
and Shift modifiers for differing language keyboards between client and host. Otherwise, only a single key press/release of a Keycode is simulated (i.e. ignoring the state of the modifiers: this usually works for identical keyboards). Also useful in resolving cases where a Keysym is bound to multiple keys (e.g. "<" + ">" and "," + "<" keys). Default: -modtweak
If you are having trouble with with keys and -xkb or
-noxkb, and similar things don't help, try -nomodtweak.
On some HP-UX systems it is been noted that they have
an odd keymapping where a single keycode will have a keysym, e.g. "#", up to three times. You can check via "xmodmap -pk" or the -dk option. The failure is when you try to type "#" it yields "3". If you see this problem try setting the environment variable MODTWEAK_LOWEST=1 to see if it helps.