search

legionus / kbd

Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git
https://kbd-project.org
Other
85 stars 40 forks source link

fa layout cannot be loaded due to U+FDFC character #62

Closed AdamWill closed 2 years ago

AdamWill commented 3 years ago

In 2019, fa.map was added to kbd in response to my https://github.com/legionus/kbd/issues/14 . I can only imagine nobody actually tested it, though, because if you try to load it, this happens:

unicode keysym out of range: U+FDFC
syntax error, unexpected ERROR, expecting NUMBER or LITERAL or PLUS or UNUMBER

...and it doesn't work. The layout appears to be falling foul of this change from 2008 which was made on the basis that codepoints above U+F000 are not valid or not properly supported by the kernel(?), but all references I can find - like the approved proposal that the symbol be added in the first place - seem to think that U+FDFC is a perfectly valid codepoint. According to the GNOME Character Map app, there are a bunch of valid codepoints from U+FB50 to U+1EEF1.

Not sure what the correct fix is here, but kbd shipping a keymap it cannot load doesn't seem sane.

AdamWill commented 3 years ago

Note same problem mentioned at https://bbs.archlinux.org/viewtopic.php?id=263591 .

legionus commented 3 years ago

@AdamWill Yes, it looks like the fa.map is useless because it uses characters greater than U+F000. To fix it, you need to replace symbols from the range below U+F000 or I can remove such bindings.

AdamWill commented 3 years ago

Well, that's what I did downstream (I just patched out that symbol), but I wasn't sure if that's the right solution. The symbol is clearly one it would make sense to be able to type (it's a regional currency sign). Is is truly still the case that some technical limitation makes it impossible for a console layout to type such a character? Could that limitation be fixed?

legionus commented 3 years ago

This is a kernel limitation. loadkeys does not allow loading a keymap that cannot be fully loaded. This is dangerous. This limitation can be removed by implementing support for > U+F000 in the kernel.

AdamWill commented 3 years ago

Are you sure the kernel limitations are still as they were? https://mjmwired.net/kernel/Documentation/admin-guide/unicode.rst seems to suggest things might have changed. Note this part:

[v1.2]: The Unicodes range from U+F000 and up to U+F7FF have been
hard-coded to map directly to the loaded font, bypassing the
translation table.  The user-defined map now defaults to U+F000 to
U+F0FF, emulating the previous behaviour.  In practice, this range
might be shorter; for example, vgacon can only handle 256-character
(U+F000..U+F0FF) or 512-character (U+F000..U+F1FF) fonts."
AdamWill commented 3 years ago

well, hmm, that's dated 2005 and the patch was 2008, so maybe I'm misunderstanding it. If there's no prospect of the kernel supporting this, I guess the thing to do is to patch that single line out of the keymap.

I wonder how this goes on Debian, where we got the keymap...maybe it's broken there and nobody noticed?

legionus commented 3 years ago

Yes. I'm pretty sure. In this area nothing has changed in the kernel for a very long time.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kbd_kern.h#n122

AdamWill commented 2 years ago

For the record, this was closed by https://github.com/legionus/kbd/commit/027dd67526bd762a242992cf595916a174096649 , which removes the problematic character entirely.