tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Xmodmap intra and inter-systems woes



Hello,

I have stumbled (it took me hours to find the solution) upon this 
problem with the keyboard keycodes and the xmodmap mapping.

Context (yes! it has something to do with NetBSD; please bear with me):
Fabrice Bellard has developed a VM in JavaScript and has put a
demonstration with various systems amongst which AlpineLinux.

A teacher, in the USA, has asked me about the possibility to run kerTeX
(my TeX small distribution) in this restrained environment, in order to
be able to teach without requiring any installation from the students: a
browser is sufficient.

So, as far as kerTeX is concerned, no problem: neither for compilation
nor for size. And it is made so that even in this constrained
environment (it runs approximately 200x slower for compilation for
example...), it manages to work quite fast.

So the NetBSD part: since my main development plateform is NetBSD, I
tested under NetBSD (8.0), amd64, with native Xorg, almost bare (I use
twm) and firefox 71.0.

When under jslinux, the Alpine X11 version, I switched the keyboard
for a french azerty mapping, I was then unable to access the
characters that are obtained after composing with AltGr. Without pipe
or backslash, one enters a rough time...

So for US qwerty users, OK, but for others, the experience was not
great...

I skip the tale of the Net search; I asked to the alpine developers
and even to Fabrice Bellard.

And I finally found:

1) For the NetBSD puzzling part:

If I run xmodmap(X1) with the -pm option, I see that AltGr (called
ISO_Level3_Shift) is associated with the keycode 0x7c.

But if I run xev(X1) to get the keycode of my AltGr, it is 0x71! And
nonetheless it works ?!!!

Does anyone have any clue about why it simply works?

2) When running jslinux hence NetBSD->Firefox->JavaScript
engine->jslinux->Alpine->X11, if I run xmodmap in jslinux, it maps
ISO_Level3_Shift to 0x5c! So "my" AltGr is not recognized as a
ISO_Level3_Shift, hence not associated to Mod5, hence no action at all.

If I add the rules (in jslinux):

keycode 0x71 = ISO_Level3_Shift
add mod5  = ISO_Level3_Shift

then everything works.

So the question: I thought that with USB Hid there was some
standardization. Why do different systems use different keycodes? And
does NetBSD (and others) customize the mapping in order to be compatible
with wscons or whatever?

I have found the solution (well at least for me; if there are 256
possible variations for every OS...) but I'd like to understand the
logic.

[I'm not saying that Linux is "right" and the others wrong, or
vice-versa, I'm just puzzled that the same Xorg code does things
differently under different OSes and that there is no normalization.]

Thanks for any clue!
-- 
        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


Home | Main Index | Thread Index | Old Index