Subject: Fluxbox: AltGr not working (azerty keyboard)

From: [email-masked]
Date: Thu, 5 Nov 2020 16:52:25 +0100

Hello,

Fabrice Bellard has developed an emulator in JavaScript, and it is now
possible to have, in a browser, Alpine/i586 running. See:

https://bellard.org/jslinux/

I'm the developper of KerTeX, a TeX and al. distribution and I'd like
to let people try it without installing, thus on Alpine/i586 in 
JSLinux, the X11 version (there is also a console only version).

No problem with kerTeX: it works.

The problem is for non QWERTY users. If I switch the keyboard (right
click menu -> keyboard mapping-> french), all is OK except all the
letters that are accessed with AltGr---and Alt and AltGr simply don't
work (preventing from using backslash or pipe, and this is quite a
problem).

There is no problem with console only (another choice with Alpine Linux
on the page above).

I have searched the Internet about this. There are quite a lot of
similar issues (not only with Alpine or Fluxbox) but no real solution. I
have tried several "solutions" but the result is the same, or worse.

Does somebody have any clue?

TIA
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

---

From: Paul Zillmann <[email-masked]>
Date: Thu, 5 Nov 2020 18:52:30 +0100

Hello Thierry,

I have some issues understanding your problem.

Is your issues that some characters in the linked emulator won't work, 
is the problem specific to your kerTeX software?
Besides that I was unable to locate kerTeX in the Apline repositories.

Anyway I've tried the emulator - Alpine 3.12 X Window - changed the 
keyboard settings to German.
I've opened a terminal and a text editor - both took pipes and other 
characters accessed by the AltGr key.
I'm working with a native German keyboard (QWERTZ) under Manjaro Linux.

I've tried both Firefox 82.0.2 and Chromium 86.0.4240.111 and both 
worked fine.
I'll check on a Windows machine soon.

Can you describe your test-scenario for us?
What OS are you using, which browser, what's your native keyboard layout 
- am I testing this right or wrong?

- Paul

---

From: [email-masked]
Date: Thu, 5 Nov 2020 19:20:32 +0100

Hello Paul,

On Thu, Nov 05, 2020 at 06:52:30PM +0100, Paul Zillmann wrote:
> Is your issues that some characters in the linked emulator won't work, is
> the problem specific to your kerTeX software?

Not with kerTeX but with input from the keyboard in the emulator. As
long as I use an US QWERTY keyboard mapping everything is fine, if I
select, from the Fluxbox menu a "french" mapping, all the characters
accessed composing via AltRight key do not work: I get the normal
character associated with the key; if I use shift+AltRight, the shifted;
and never the character accessed by AltRight+key.

> Besides that I was unable to locate kerTeX in the Apline repositories.

kerTeX is not packaged: it compiles and installs to almost every OS
(Alpine included) using its own framework (Plan9, *BSD, Linuces, MacOSX,
Windows with a POSIX subsystem for now, but "native" soon. It's libre
software under a BSD like licence:

(for the ones who want to try just download the get_mk_install.sh and
run it---caveats you need a true ed(1) and not the one from Busybox that
is sed masquerading as ed(1)).

> Anyway I've tried the emulator - Alpine 3.12 X Window - changed the keyboard
> settings to German.
> I've tried both Firefox 82.0.2 and Chromium 86.0.4240.111 and both worked
> fine.

> What OS are you using, which browser, what's your native keyboard layout -
> am I testing this right or wrong?
> 

I'm on NetBSD/amd64 with Firefox 71.0 and vanilla Xorg with twm and
that's all.

I have a french azerty pc105 keyboard, USB connected.

Firefox gets the correct keys. But the emulator windows not (indeed, the
layers are so numerous that the problem could indeed be in the 
javascript engine and not in the "final" alpine).

Thank you for your help!

---

From: [email-masked]
Date: Thu, 5 Nov 2020 20:07:25 +0100

Just a supplementary note:

I switched under Windows (8.x) with Edge, on the same machine (same
keyboard), and I have the same problem.

If I switch to a German mapping, I don't get AltGr either.

My keyboard is USB connected. Is your keyboard USB or PS/2 connected?
Because, IIRC, there is a USB specific Hid specification for the mapping
and it has nothing to do with what was done before.

Best,

T. Laronde

---

From: Paul Zillmann <[email-masked]>
Date: Thu, 5 Nov 2020 22:30:34 +0100

Hey Thierry,

> keyboard), and I have the same problem.

I had no luck under Windows 10 either. Tried Edge (the older version), 
Chromium and Firefox.

> and it has nothing to do with what was done before.

With Windows that was USB and VirtIO Input (PCIe that is, I guess...).
With Linux both USB native and PS/2 native worked.

The terminal thingy should be really easy - a TTY in a browser is easy 
to code.
Since you can use textareas all inputs can come from the browser natively.

Framebuffer are a completely different story. I don't know what is used 
here, could be WebAssembly, could be different ECMAScript versions 
according to the browser's capabilities.
Maybe they use input libraries - could be a polling method.
Only Fabrice Bellard could give you that info - or someone who read the 
source code.
Have you talked to the developer?

Btw. strangely the third assignment works for some keys. The Y key has a 
third assignment of "»" in the German layout. This works fine in Windows.

Maybe I'm going to check that out with FreeBSD. Unfortunately I've never 
used NetBSD.

Good luck,
- Paul

-- 
H6G
Paul Zillmann
Binzer Str. 17
18107 Rostock

www.h6g.de
[email-masked]

Tel.: (03 81) 36 76 79 27 - 0

---

From: [email-masked]
Date: Fri, 6 Nov 2020 07:19:10 +0100

Hello Paul,

On Thu, Nov 05, 2020 at 10:30:34PM +0100, Paul Zillmann wrote:
> The terminal thingy should be really easy - a TTY in a browser is easy to
> code.
> here, could be WebAssembly, could be different ECMAScript versions according
> to the browser's capabilities.

Thank you to have taken the time to test and to confirm that there is
indeed a problem (i.e. it's not only a weird hardware problem on my side).

From a cursory look to the sources, there is a keymap mapping in the JS
code so I will indeed ask Fabrice Bellard if he has some clue.

Best,

T. Laronde

---

From: [email-masked]
Date: Fri, 6 Nov 2020 18:44:02 +0100

Hello,

I finally found it and it has nothing to do with jslinux.

The problem is that NetBSD (and obviously Windows) associates a 
different keycode to ISO_Level3_Shift (aka AltGr).

On my NetBSD, it associates keycode 0x7c to it, while my keyboard sends
0x71 (and nonetheless, it works ?!!!).

On AlpineLinux, it associates 0x5c to it. So "my" AltGr is not
considered a ISO_Level3_Shift, so not a mod5 hence pressing the key 
does nothing.

If I send the following rules to xmodmap (under jslinux):

keycode 0x71 = ISO_Level3_Shift
add mod5  = ISO_Level3_Shift

everything works! (The add rule simply updates the mod5 adding _too_
the new binding.)

So it works under Linux by chance because the mapping is probably the
same.

To verify what one's xmodmap associates run:

xmodmap -pm

(the keycode are in parentheses).

To know what your keyboard is sending, run xev(1), give the focus in a
Xterm and press the key(s).

I wonder how many variations there are around there? I stupidly thought
that the mapping was fixed because of the standardization of USB Hid...

And I wonder how one could find what the different OSes use about
it so that I can add the rules to the xmodmap in order for users
to not have this kind of surprise and to not have the burden to
try to find what the keyboard is sending (there is no xev(1) in
jslinux so one can not resort to this).

HTH

T. Laronde

---

From: [email-masked]
Date: Sat, 7 Nov 2020 18:41:15 +0100

FWIW, here is a script to adapt xmodmap to the keyboard. It needs
xev(X1). I don't know if this can be of any use to Alpine, but for
completeness for the thread, it is included here.

------8-<-----
#!/bin/sh
# C) 2020 Thierry Laronde <[email-masked]>
# Public Domain.
# No warranty! Use at your own risk!

: ${TMPDIR:=/tmp}

cat <<EOT >&2
When the window will appear, click first in the xterm
and then in the window (the square in the blank window).

You can then start to press Meta keys: "Windows",
Alt, AltGr, arrows, home, end, page up, page down...
so that we can generate the xmodmap rules.

Press any key to start. Kill the xev window when done.
EOT
read ans

# Get keycode keysym name from xev.
#
xev -event keyboard 2>&1\
	| sed -n -e 's/^Outer window is \(0x[^,]*\).*$/\1/p' \
		-e 's/^.*keycode \([0-9][0-9]*\) (keysym 0x\([a-f0-9][a-f0-9]*\), \([^)][^)]*\)).*$/\1 \2 \3/p'\
	| sort | uniq\
	| while read keycode keysym name; do
		test "$keysym" || { wid=$keycode; continue; } # unused
		echo "keycode $keycode = $name"
		case $name in
			Shift_[LR]) echo "add shift = $name";;
			Control_[LR]) echo "add control = $name";;
			Alt_L|Meta_L) echo "add mod1 = $name";;
			Super_[LR]|Hyper_L) echo "add mod4 = $name";;
			ISO_Level3_Shift|Mode_switch) echo "add mod5 = $name";;
		esac\
	>$TMPDIR/xmodmap
done

xmodmap $TMPDIR/xmodmap
----->8-----

---

From: [email-masked]
Date: Sat, 7 Nov 2020 20:00:39 +0100

There was a typo (redirection in the wrong place), please find the
corrected version here:

-----8<-----
#!/bin/sh

: ${TMPDIR:=/tmp}

cat <<EOT >&2

		esac
	done >$TMPDIR/xmodmap

xmodmap $TMPDIR/xmodmap
----->8-----

---

From: Ariadne Conill <[email-masked]>
Date: Thu, 05 Nov 2020 12:33:35 -0700

> work (preventing from using backslash or pipe, and this is quite a

Are you experiencing this problem in Alpine itself or in Alpine while running 
under JSLinux?  If the latter, it is probably JSLinux itself having issues 
with your keyboard input.

Ariadne

---

From: [email-masked]
Date: Thu, 5 Nov 2020 20:58:46 +0100

> with your keyboard input.

But the problem is that Alpine comes in two flavors under jslinux: one
command line only; one with X11. In command line only, I have no
problem (I have even not to set the keyboard mapping: it works as is).
The problem appears with the X11 version. Since it is a VM, the js
machine is the same; the difference if the stack of things running on
it.

Before asking, I have verified that similar problems have been
reported (not only with fluxbox and not only for Alpine) before. These
problems, always weird, had nothing to do with JavaScript...

You are right that this doesn't exclude a problem with JavaScript. But
this doesn't exclude either a problem with Fluxbox since there is a case
where everything works with the VM (command line). So the culprit seems
to be higher in the stack of things...

Note: this doesn't exclude either that for some reason my keyboard does
strange things. Unfortunately, it doesn't work when plugging a USB-PS/2
adapter---since the virtual machine is a 586, perhaps X11 is trying to
do smart things with something that can not be USB and since the 
keyboard doesn't understand legacy PS/2 not
everything is correctly emulated, while, with command line only, a more
simple and direct approach is used (raw scancodes or whatever) with
less smartness and interpretation or dialog with the device and it 
happens to work...
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C