Re: Broken arrow keys for browser access to proxmox and ESXi

[RVP <rvp%SDF.ORG@localhost>]

On Sat, 3 Jan 2026, David Brownlee wrote:

> More information.
>
> - Disabling wayland in gtk3 and rebuilding all packages does not
> resolve the issue

Yeah, that wasn't it. I think what's happening is, actually, this:

On NetBSD (recent-ish -HEAD), and, also its close sister, OpenBSD-7.7:

```
$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+ctrl(swapcaps)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

$ fgrep -m1 DOWN /usr/X11R7/lib/X11/xkb/keycodes/xfree86
    <DOWN> = 104;

$ xev -event keyboard
[...]
KeyPress event, serial 28, synthetic NO, window 0x1600001,
    root 0x50e, subw 0x0, time 103222, (89,89), root:(960,600),
    state 0x0, keycode 104 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False
[...]

$ 
```

Note that the keycode for ArrowDown is 104 (0x68).

But, on Linux (Ubuntu 24.04.3) and FreeBSD-14.3 both of which use evdev:

```
$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)+ctrl(swapcaps)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

$ fgrep -m1 DOWN /usr/X11R7/lib/X11/xkb/keycodes/evdev	# checking on NetBSD here
	<DOWN> = 116;

$ xev -event keyboard
[...]
KeyPress event, serial 28, synthetic NO, window 0x1400001,
    root 0x4b2, subw 0x1400002, time 12865061, (21,19), root:(234,130),
    state 0x0, keycode 116 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False
[...]

$
```

And, what evdev keycode is 104 (ie. ArrowDown in wscons)?
```
$ fgrep 104 /usr/X11R7/lib/X11/xkb/keycodes/evdev
	<KPEN> = 104;

$
```

It's KPEN (KeyPad Enter)--QED. And, in the Pale Moon UXP sources:

https://repo.palemoon.org/MoonchildProductions/UXP/src/branch/master/widget/NativeKeyToDOMCodeName.h#L356

we see (hex value):

```
CODE_MAP_X11(ArrowDown,                 0x0074)
```

which matches (only) the evdev scancode as stated here:

https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_code_values#code_values_on_linux_x11


So, it's a "scancode" mismatch--a Linuxism, ultimately.

Fix?

1. Patching the browser source(s) would be one way. (I only checked the
Pale Moon sources--Firefox was 600 MB+; don't even want to know how large
Chrome is!) You can try Pale Moon immediately, then use that as a guide
to figure out where the Firefox equilavent is. Chrome, I leave to someone
else :).

2. Make the kernel generate evdev-compatible scancodes (then use the
evdev keycodes in Xorg) if requested (`wsconsctl -w encoding=us.evdev`)?

HTH,

-RVP