loadkeys: Auto-convert “traditional”/Unicode keysyms
PATCH 1/1 loadkeys: Auto-convert “traditional”/Unicode keysyms
The Linux kernel distinguishes between K(KTYP, KVAL) keysyms and Unicode characters. This patch makes loadkeys query the console’s Unicode mode and convert between the two keysym types according to the result. The theoretical advantage is that less keymaps need both an 8-bit and a Unicode variant (cf. trq[u], ua[-utf]).
A similar patch (read_keymaps_fmt) has been in use in Debian’s version of kbd since 2004; see <http://bugs.debian.org/251550> for a discussion. Credit for this goes to Denis Barbier <[email protected]>.
---
Alexey, may I ask you to keep the Cc when you reply to this mail? I’d like to keep a record in the Debian BTS <http://bugs.debian.org/524057>.
I tried my best to check that this patch does no harm, but it is quite invasive. I think you really have to triple-check before you git-am – I don’t want to lock out users from their machines because I missed one or the other corner case.
src/loadkeys.c is not included in this patch for readability reasons.
src/dumpkeys.c | 3 +- src/ksyms.c | 112 ++++++++++++++++++++++++++++++++------------------------ src/ksyms.h | 4 +- src/loadkeys.y | 72 ++++++++++++++---------------------- 4 files changed, 95 insertions(+), 96 deletions(-)
src/dumpkeys.c +1 -2
@@ -135,8 +135,7 @@ print_keysym(int code, char numeric) { t =KTYP (code); v =KVAL (code);if (t >= syms_size) { - code = code ^0xf000 ; -if (!numeric && (p =unicodetoksym (code)) !=NULL ) +if (!numeric && (p =codetoksym (code)) !=NULL )printf ("%-16s" , p);else printf ("U+%04x " , code);
src/ksyms.c +64 -48
175 lines not on this page · raw message
src/ksyms.h +2 -2
@@ -26,10 +26,10 @@ extern const unsigned int syn_size;#define CODE_FOR_UNKNOWN_KSYM (-1)extern int set_charset (const char *name); -extern const char *unicodetoksym (int code); +extern const char *codetoksym (int code);extern void list_charsets (FILE *f);extern int ksymtocode (const char *s); -extern int unicodetocode (int code); +extern int convert_code (int code);extern int add_capslock (int code);#endif
src/loadkeys.y +28 -44
152 lines not on this page · raw message
Signature · 5 lines
1.6.2.1 -- Michael Schutte <[email protected]>
Quoted 5 lines · Michael Schutte
The Linux kernel distinguishes between
K(KTYP, KVAL)keysyms and Unicode characters. This patch makes loadkeys query the console’s Unicode mode and convert between the two keysym types according to the result. The theoretical advantage is that less keymaps need both an 8-bit and a Unicode variant (cf. trq[u], ua[-utf]).
I have a problem with your patch:
LANG: ru_RU.UTF-8
keymap: data/keymaps/i386/qwerty/ruwin_cplk-UTF-8.map
The difference between the old and the new behavior is attached. This is 'dumpkeys -n' output.
For example keycode 52 = U+044e -> U+f44e:
$ /usr/bin/printf '\u044e\n\uf44e\n' ю
First character is cyrillic 'yu':
http://www.fileformat.info/info/unicode/char/044e/index.htm
Second is:
http://www.fileformat.info/info/unicode/char/f44e/index.htm
And also, you have not updated the documentation for new behaviour.
Signature · 1 line
Rgrds, legion
new.dump renamed from old.dump +33 -33
@@ -74,81 +74,81 @@ keycode 15 = 0x0009 0x0009 0x0009 0x0009 alt keycode 15 = 0x0809 altgr alt keycode 15 = 0x0809 -keycode 16 = +0x0b71 +0x0b51 U+0439 U+0419 0x0011 0x0011 0x0011 +keycode 16 = +0x0b71 +0x0b51 U+f439 U+f419 0x0011 0x0011 0x0011 alt keycode 16 = 0x0871 shift alt keycode 16 = 0x0851 altgr alt keycode 16 = 0x0871 shift altgr alt keycode 16 = 0x0851 control alt keycode 16 = 0x0811 altgr control alt keycode 16 = 0x0811 -keycode 17 = +0x0b77 +0x0b57 U+0446 U+0426 0x0017 0x0017 0x0017 +keycode 17 = +0x0b77 +0x0b57 U+f446 U+f426 0x0017 0x0017 0x0017 alt keycode 17 = 0x0877 shift alt keycode 17 = 0x0857 altgr alt keycode 17 = 0x0877 shift altgr alt keycode 17 = 0x0857 control alt keycode 17 = 0x0817 altgr control alt keycode 17 = 0x0817 -keycode 18 = +0x0b65 +0x0b45 U+0443 U+0423 0x0005 0x0005 0x0005 +keycode 18 = +0x0b65 +0x0b45 U+f443 U+f423 0x0005 0x0005 0x0005 alt keycode 18 = 0x0865 shift alt keycode 18 = 0x0845 altgr alt keycode 18 = 0x0865 shift altgr alt keycode 18 = 0x0845 control alt keycode 18 = 0x0805 altgr control alt keycode 18 = 0x0805 -keycode 19 = +0x0b72 +0x0b52 U+043a U+041a 0x0012 0x0012 0x0012 +keycode 19 = +0x0b72 +0x0b52 U+f43a U+f41a 0x0012 0x0012 0x0012 alt keycode 19 = 0x0872 shift alt keycode 19 = 0x0852 altgr alt keycode 19 = 0x0872 shift altgr alt keycode 19 = 0x0852 control alt keycode 19 = 0x0812 altgr control alt keycode 19 = 0x0812 -keycode 20 = +0x0b74 +0x0b54 U+0435 U+0415 0x0014 0x0014 0x0014 +keycode 20 = +0x0b74 +0x0b54 U+f435 U+f415 0x0014 0x0014 0x0014 alt keycode 20 = 0x0874 shift alt keycode 20 = 0x0854 altgr alt keycode 20 = 0x0874 shift altgr alt keycode 20 = 0x0854 control alt keycode 20 = 0x0814 altgr control alt keycode 20 = 0x0814 -keycode 21 = +0x0b79 +0x0b59 U+043d U+041d 0x0019 0x0019 0x0019 +keycode 21 = +0x0b79 +0x0b59 U+f43d U+f41d 0x0019 0x0019 0x0019 alt keycode 21 = 0x0879 shift alt keycode 21 = 0x0859 altgr alt keycode 21 = 0x0879 shift altgr alt keycode 21 = 0x0859 control alt keycode 21 = 0x0819 altgr control alt keycode 21 = 0x0819 -keycode 22 = +0x0b75 +0x0b55 U+0433 U+0413 0x0015 0x0015 0x0015 +keycode 22 = +0x0b75 +0x0b55 U+f433 U+f413 0x0015 0x0015 0x0015 alt keycode 22 = 0x0875 shift alt keycode 22 = 0x0855 altgr alt keycode 22 = 0x0875 shift altgr alt keycode 22 = 0x0855 control alt keycode 22 = 0x0815 altgr control alt keycode 22 = 0x0815 -keycode 23 = +0x0b69 +0x0b49 U+0448 U+0428 0x0009 0x0009 0x0009 +keycode 23 = +0x0b69 +0x0b49 U+f448 U+f428 0x0009 0x0009 0x0009 alt keycode 23 = 0x0869 shift alt keycode 23 = 0x0849 altgr alt keycode 23 = 0x0869 shift altgr alt keycode 23 = 0x0849 control alt keycode 23 = 0x0809 altgr control alt keycode 23 = 0x0809 -keycode 24 = +0x0b6f +0x0b4f U+0449 U+0429 0x000f 0x000f 0x000f +keycode 24 = +0x0b6f +0x0b4f U+f449 U+f429 0x000f 0x000f 0x000f alt keycode 24 = 0x086f shift alt keycode 24 = 0x084f altgr alt keycode 24 = 0x086f shift altgr alt keycode 24 = 0x084f control alt keycode 24 = 0x080f altgr control alt keycode 24 = 0x080f -keycode 25 = +0x0b70 +0x0b50 U+0437 U+0417 0x0010 0x0010 0x0010 +keycode 25 = +0x0b70 +0x0b50 U+f437 U+f417 0x0010 0x0010 0x0010 alt keycode 25 = 0x0870 shift alt keycode 25 = 0x0850 altgr alt keycode 25 = 0x0870 shift altgr alt keycode 25 = 0x0850 control alt keycode 25 = 0x0810 altgr control alt keycode 25 = 0x0810 -keycode 26 = 0x005b 0x007b U+0445 U+0425 0x001b +keycode 26 = 0x005b 0x007b U+f445 U+f425 0x001b altgr control keycode 26 = 0x001b alt keycode 26 = 0x085b altgr alt keycode 26 = 0x085b -keycode 27 = 0x005d 0x007d U+044a U+042a 0x001d +keycode 27 = 0x005d 0x007d U+f44a U+f42a 0x001d altgr control keycode 27 = 0x001d alt keycode 27 = 0x085d altgr alt keycode 27 = 0x085d
@@ -166,77 +166,77 @@ shift altgr alt keycode 29 = 0x0702 control alt keycode 29 = 0x0702 altgr control alt keycode 29 = 0x0702 -keycode 30 = +0x0b61 +0x0b41 U+0444 U+0424 0x0001 0x0001 0x0001 +keycode 30 = +0x0b61 +0x0b41 U+f444 U+f424 0x0001 0x0001 0x0001 alt keycode 30 = 0x0861 shift alt keycode 30 = 0x0841 altgr alt keycode 30 = 0x0861 shift altgr alt keycode 30 = 0x0841 control alt keycode 30 = 0x0801 altgr control alt keycode 30 = 0x0801 -keycode 31 = +0x0b73 +0x0b53 U+044b U+042b 0x0013 0x0013 0x0013 +keycode 31 = +0x0b73 +0x0b53 U+f44b U+f42b 0x0013 0x0013 0x0013 alt keycode 31 = 0x0873 shift alt keycode 31 = 0x0853 altgr alt keycode 31 = 0x0873 shift altgr alt keycode 31 = 0x0853 control alt keycode 31 = 0x0813 altgr control alt keycode 31 = 0x0813 -keycode 32 = +0x0b64 +0x0b44 U+0432 U+0412 0x0004 0x0004 0x0004 +keycode 32 = +0x0b64 +0x0b44 U+f432 U+f412 0x0004 0x0004 0x0004 alt keycode 32 = 0x0864 shift alt keycode 32 = 0x0844 altgr alt keycode 32 = 0x0864 shift altgr alt keycode 32 = 0x0844 control alt keycode 32 = 0x0804 altgr control alt keycode 32 = 0x0804 -keycode 33 = +0x0b66 +0x0b46 U+0430 U+0410 0x0006 0x0006 0x0006 +keycode 33 = +0x0b66 +0x0b46 U+f430 U+f410 0x0006 0x0006 0x0006 alt keycode 33 = 0x0866 shift alt keycode 33 = 0x0846 altgr alt keycode 33 = 0x0866 shift altgr alt keycode 33 = 0x0846 control alt keycode 33 = 0x0806 altgr control alt keycode 33 = 0x0806 -keycode 34 = +0x0b67 +0x0b47 U+043f U+041f 0x0007 0x0007 0x0007 +keycode 34 = +0x0b67 +0x0b47 U+f43f U+f41f 0x0007 0x0007 0x0007 alt keycode 34 = 0x0867 shift alt keycode 34 = 0x0847 altgr alt keycode 34 = 0x0867 shift altgr alt keycode 34 = 0x0847 control alt keycode 34 = 0x0807 altgr control alt keycode 34 = 0x0807 -keycode 35 = +0x0b68 +0x0b48 U+0440 U+0420 0x0008 0x0008 0x0008 +keycode 35 = +0x0b68 +0x0b48 U+f440 U+f420 0x0008 0x0008 0x0008 alt keycode 35 = 0x0868 shift alt keycode 35 = 0x0848 altgr alt keycode 35 = 0x0868 shift altgr alt keycode 35 = 0x0848 control alt keycode 35 = 0x0808 altgr control alt keycode 35 = 0x0808 -keycode 36 = +0x0b6a +0x0b4a U+043e U+041e 0x000a 0x000a 0x000a +keycode 36 = +0x0b6a +0x0b4a U+f43e U+f41e 0x000a 0x000a 0x000a alt keycode 36 = 0x086a shift alt keycode 36 = 0x084a altgr alt keycode 36 = 0x086a shift altgr alt keycode 36 = 0x084a control alt keycode 36 = 0x080a altgr control alt keycode 36 = 0x080a -keycode 37 = +0x0b6b +0x0b4b U+043b U+041b 0x000b 0x000b 0x000b +keycode 37 = +0x0b6b +0x0b4b U+f43b U+f41b 0x000b 0x000b 0x000b alt keycode 37 = 0x086b shift alt keycode 37 = 0x084b altgr alt keycode 37 = 0x086b shift altgr alt keycode 37 = 0x084b control alt keycode 37 = 0x080b altgr control alt keycode 37 = 0x080b -keycode 38 = +0x0b6c +0x0b4c U+0434 U+0414 0x000c 0x000c 0x000c +keycode 38 = +0x0b6c +0x0b4c U+f434 U+f414 0x000c 0x000c 0x000c alt keycode 38 = 0x086c shift alt keycode 38 = 0x084c altgr alt keycode 38 = 0x086c shift altgr alt keycode 38 = 0x084c control alt keycode 38 = 0x080c altgr control alt keycode 38 = 0x080c -keycode 39 = 0x003b 0x003a U+0436 U+0416 +keycode 39 = 0x003b 0x003a U+f436 U+f416 alt keycode 39 = 0x083b altgr alt keycode 39 = 0x083b -keycode 40 = 0x0027 0x0022 U+044d U+042d 0x0007 +keycode 40 = 0x0027 0x0022 U+f44d U+f42d 0x0007 altgr control keycode 40 = 0x0007 alt keycode 40 = 0x0827 altgr alt keycode 40 = 0x0827 -keycode 41 = 0x0060 0x007e U+0451 U+0401 0x0000 +keycode 41 = 0x0060 0x007e U+f451 U+f401 0x0000 altgr control keycode 41 = 0x0000 alt keycode 41 = 0x0860 altgr alt keycode 41 = 0x0860
@@ -253,61 +253,61 @@ shift alt keycode 43 = 0x087c altgr alt keycode 43 = 0x085c shift altgr alt keycode 43 = 0x087c -keycode 44 = +0x0b7a +0x0b5a U+044f U+042f 0x001a 0x001a 0x001a +keycode 44 = +0x0b7a +0x0b5a U+f44f U+f42f 0x001a 0x001a 0x001a alt keycode 44 = 0x087a shift alt keycode 44 = 0x085a altgr alt keycode 44 = 0x087a shift altgr alt keycode 44 = 0x085a control alt keycode 44 = 0x081a altgr control alt keycode 44 = 0x081a -keycode 45 = +0x0b78 +0x0b58 U+0447 U+0427 0x0018 0x0018 0x0018 +keycode 45 = +0x0b78 +0x0b58 U+f447 U+f427 0x0018 0x0018 0x0018 alt keycode 45 = 0x0878 shift alt keycode 45 = 0x0858 altgr alt keycode 45 = 0x0878 shift altgr alt keycode 45 = 0x0858 control alt keycode 45 = 0x0818 altgr control alt keycode 45 = 0x0818 -keycode 46 = +0x0b63 +0x0b43 U+0441 U+0421 0x0003 0x0003 0x0003 +keycode 46 = +0x0b63 +0x0b43 U+f441 U+f421 0x0003 0x0003 0x0003 alt keycode 46 = 0x0863 shift alt keycode 46 = 0x0843 altgr alt keycode 46 = 0x0863 shift altgr alt keycode 46 = 0x0843 control alt keycode 46 = 0x0803 altgr control alt keycode 46 = 0x0803 -keycode 47 = +0x0b76 +0x0b56 U+043c U+041c 0x0016 0x0016 0x0016 +keycode 47 = +0x0b76 +0x0b56 U+f43c U+f41c 0x0016 0x0016 0x0016 alt keycode 47 = 0x0876 shift alt keycode 47 = 0x0856 altgr alt keycode 47 = 0x0876 shift altgr alt keycode 47 = 0x0856 control alt keycode 47 = 0x0816 altgr control alt keycode 47 = 0x0816 -keycode 48 = +0x0b62 +0x0b42 U+0438 U+0418 0x0002 0x0002 0x0002 +keycode 48 = +0x0b62 +0x0b42 U+f438 U+f418 0x0002 0x0002 0x0002 alt keycode 48 = 0x0862 shift alt keycode 48 = 0x0842 altgr alt keycode 48 = 0x0862 shift altgr alt keycode 48 = 0x0842 control alt keycode 48 = 0x0802 altgr control alt keycode 48 = 0x0802 -keycode 49 = +0x0b6e +0x0b4e U+0442 U+0422 0x000e 0x000e 0x000e +keycode 49 = +0x0b6e +0x0b4e U+f442 U+f422 0x000e 0x000e 0x000e alt keycode 49 = 0x086e shift alt keycode 49 = 0x084e altgr alt keycode 49 = 0x086e shift altgr alt keycode 49 = 0x084e control alt keycode 49 = 0x080e altgr control alt keycode 49 = 0x080e -keycode 50 = +0x0b6d +0x0b4d U+044c U+042c 0x000d 0x000d 0x000d +keycode 50 = +0x0b6d +0x0b4d U+f44c U+f42c 0x000d 0x000d 0x000d alt keycode 50 = 0x086d shift alt keycode 50 = 0x084d altgr alt keycode 50 = 0x086d shift altgr alt keycode 50 = 0x084d control alt keycode 50 = 0x080d altgr control alt keycode 50 = 0x080d -keycode 51 = 0x002c 0x003c U+0431 U+0411 +keycode 51 = 0x002c 0x003c U+f431 U+f411 alt keycode 51 = 0x082c shift alt keycode 51 = 0x083c altgr alt keycode 51 = 0x082c shift altgr alt keycode 51 = 0x083c -keycode 52 = 0x002e 0x003e U+044e U+042e 0x020e +keycode 52 = 0x002e 0x003e U+f44e U+f42e 0x020e alt keycode 52 = 0x082e shift alt keycode 52 = 0x083e altgr alt keycode 52 = 0x082e
Hi Alexey,
Quoted 7 lines · Alexey Gladkov
Quoted 5 lines · Michael Schutte
The Linux kernel distinguishes between
K(KTYP, KVAL)keysyms and Unicode characters. This patch makes loadkeys query the console’s Unicode mode and convert between the two keysym types according to the result. The theoretical advantage is that less keymaps need both an 8-bit and a Unicode variant (cf. trq[u], ua[-utf]).
Quoted 7 lines
I have a problem with your patch:
LANG: ru_RU.UTF-8
keymap: data/keymaps/i386/qwerty/ruwin_cplk-UTF-8.mapThe difference between the old and the new behavior is attached. This is 'dumpkeys -n' output.
Thanks for your testing, I completely missed this. But you can still type the affected characters, right? As far as I can tell, it’s only dumpkeys which is wrong here.
Quoted 1 line
And also, you have not updated the documentation for new behaviour.
loadkeys(1) didn’t even document the old meaning of -u. I’ve added a short section about the features of this patch. If you want me to add more information, please let me know.
A fixed version of the patch is attached to this mail.
Cheers,
Signature · 1 line
Michael Schutte <[email protected]>
From 8139d872c6797d73da3465c9839ee98ae865396d Mon Sep 17 00:00:00 2001
From: Michael Schutte <[email protected]>
Date: Tue, 14 Apr 2009 10:46:32 +0200
Subject: [PATCH] loadkeys: Auto-convert “traditional”/Unicode keysyms
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
The Linux kernel distinguishes between K(KTYP, KVAL) keysyms and Unicode characters. This patch makes loadkeys query the console’s Unicode mode and convert between the two keysym types according to the result. The theoretical advantage is that less keymaps need both an 8-bit and a Unicode variant (cf. trq[u], ua[-utf]).
A similar patch (read_keymaps_fmt) has been in use in Debian’s version of kbd since 2004; see <http://bugs.debian.org/251550> for a discussion. Credit for this goes to Denis Barbier <[email protected]>.
--- man/man1/loadkeys.1.in | 19 ++++++++ src/dumpkeys.c | 5 +- src/ksyms.c | 113 +++++++++++++++++++++++++++-------------------- src/ksyms.h | 4 +- src/loadkeys.y | 74 ++++++++++++------------------- 5 files changed, 117 insertions(+), 98 deletions(-)
man/man1/loadkeys.1.in +19 -0
@@ -23,6 +23,8 @@ loadkeys \- load keyboard translation tables ] [ .I -s --clearstrings ] [ +.I -u --unicode +] [ .I -v --verbose ] [ .I filename...
@@ -144,6 +146,23 @@ prints to the standard output a file that may be used as a binary keymap as expected by Busybox .B loadkmap command (and does not modify the current keymap). +.SH "UNICODE MODE" +.B loadkeys +automatically detects whether the console is in Unicode or +ASCII (XLATE) mode. When a keymap is loaded, literal +keysyms (such as +.BR section ) +are resolved accordingly; numerical keysyms are converted to +fit the current console mode, regardless of the way they are +specified (decimal, octal, hexadecimal or Unicode). +.LP +The +.I -u +(or +.IR --unicode ) +switch tells +.B loadkeys +to bypass the check and assume that the console is in Unicode mode. .SH "OTHER OPTIONS" .TP .B \-h \-\-help
src/dumpkeys.c +2 -3
@@ -135,11 +135,10 @@ print_keysym(int code, char numeric) { t =KTYP (code); v =KVAL (code);if (t >= syms_size) { - code = code ^0xf000 ; -if (!numeric && (p =unicodetoksym (code)) !=NULL ) +if (!numeric && (p =codetoksym (code)) !=NULL )printf ("%-16s" , p);else -printf ("U+%04x " , code); +printf ("U+%04x " , code ^0xf000 );return ; } plus =0 ;
src/ksyms.c +65 -48
176 lines not on this page · raw message
src/ksyms.h +2 -2
@@ -26,10 +26,10 @@ extern const unsigned int syn_size;#define CODE_FOR_UNKNOWN_KSYM (-1)extern int set_charset (const char *name); -extern const char *unicodetoksym (int code); +extern const char *codetoksym (int code);extern void list_charsets (FILE *f);extern int ksymtocode (const char *s); -extern int unicodetocode (int code); +extern int convert_code (int code);extern int add_capslock (int code);#endif
src/loadkeys.y +29 -45
160 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Quoted 3 lines · Michael Schutte
Thanks for your testing, I completely missed this. But you can still type the affected characters, right? As far as I can tell, it’s only dumpkeys which is wrong here.
Your patch still does not work for me.
$ kbd_mode -a $ export LANG=ru_RU.koi8r $ setfont data/consolefonts/koi8r-8x16 # loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
When typing characters are visible correctly.
But with your patch:
# src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
When I typing the characters displayed incorrectly.
How do you test this patch?
Can you show how loadkeys with this patch to be used in the examples?
I'm not sure that understand this. Do you want to load 8-bit keymaps for UTF locales and unicode keymaps for non-UTF locales ? Am i right ?
Signature · 1 line
Rgrds, legion
Quoted 7 lines · Alexey Gladkov
Your patch still does not work for me.
$ kbd_mode -a $ export LANG=ru_RU.koi8r $ setfont data/consolefonts/koi8r-8x16 # loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
Quoted 5 lines
When typing characters are visible correctly.
But with your patch:
# src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
Do you do this right after the above commands, or after you restored Unicode mode? I guess it’s the latter; at least as far as I can see, the two commands behave identically when they are run in immediate succession.
Quoted 1 line
When I typing the characters displayed incorrectly.
Oh, alright! This is the problem: There is no way to automatically figure out that this keymap is written in the koi8-r encoding, so the characters are taken from the wrong charset tables (the ones in ksyms.c and *.syms.h) and converted into Unicode. The patched version of loadkeys seems to do the right thing when you add
charset "koi8-r"
at the beginning of ruwin_cplk-KOI8-R.map. Can you confirm this?
Quoted 1 line
How do you test this patch?
Pretty much the way you do: loadkeys, typing some things, verifying that dumpkeys doesn’t show different results (and if so, whether the differences are intended by my patch).
Quoted 1 line
Can you show how loadkeys with this patch to be used in the examples?
I’d say it should be used just the same way as before, just that it should work regardless of the input file’s encoding. As long as this keymap file has a “charset” specification, that is; I have to admit that I didn’t consider that so many .map files don’t feature such a line. Still, this shouldn’t be a regression: When the input encoding and the console mode (XLATE/Unicode) are compatible, my patch shouldn’t change the behaviour.
Quoted 2 lines
I'm not sure that understand this. Do you want to load 8-bit keymaps for UTF locales and unicode keymaps for non-UTF locales ? Am i right ?
Yup, that’s exactly what I want it to do. It strikes me as a quite sensible thing to do, given that there are a few keymaps that differ only in their encodings.
The true reason why I want to push this, though, is that Debian’s version of kbd has had a similar patch since 2004. I’d like to get rid of this divergence without losing its useful features. This is why I’ve cleaned it up and why I’m discussing it with you now.
Thanks for you patience :-)
Signature · 1 line
Michael Schutte <[email protected]>
Quoted 4 lines · Michael Schutte
Do you do this right after the above commands, or after you restored Unicode mode? I guess it’s the latter; at least as far as I can see, the two commands behave identically when they are run in immediate succession.
I tested exactly like that:
<user>$ src/unicode_stop
<user>$ export LANG=ru_RU.koi8r
<user>$ setfont data/consolefonts/koi8r-8x16
<root># loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
<user>$ < I getting correct chars when I typing a russian text > <user>$ dumpkeys -n > dump-loadkeys.old
<root># src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
<user>$ < I getting wrong chars when I typing a russian text > <user>$ dumpkeys -n > dump-loadkeys.new
<root># loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
<user>$ < correct chars again >
Quoted 3 lines
charset "koi8-r"
at the beginning of ruwin_cplk-KOI8-R.map. Can you confirm this?
It does not help. But the broken simbols are different. I see difference in "dumpkeys -n" output (see attach). Did I miss something?
Quoted 2 lines
Quoted 1 line
How do you test this patch?
Pretty much the way you do: loadkeys, typing some things,
Hmmm ... you typing in what language?
Quoted 2 lines
verifying that dumpkeys doesn’t show different results (and if so, whether the differences are intended by my patch).
see attach.
Quoted 7 lines
I’d say it should be used just the same way as before, just that it should work regardless of the input file’s encoding. As long as this keymap file has a “charset” specification, that is; I have to admit that I didn’t consider that so many .map files don’t feature such a line. Still, this shouldn’t be a regression: When the input encoding and the console mode (XLATE/Unicode) are compatible, my patch shouldn’t change the behaviour.
Your patch will change the behaviour. At least for the russian keymaps will need to add "charset" directive. We have 4 charsets (koi8-r, cp1251, cp855, iso8859-5 and utf8). Without "charset" you do not know what encoding is used in keymap.
Quoted 2 lines
The true reason why I want to push this, though, is that Debian’s version of kbd has had a similar patch since 2004.
I want to be completely sure it's working with old keymaps.
Quoted 1 line
I’d like to get rid of this divergence without losing its useful features.
This is a good reason. :)
Quoted 1 line
This is why I’ve cleaned it up and why I’m discussing it with you now.
I am concerned keymaps legacy. We have a lot of keymaps that are not added to the kbd package. Your patch should support the old behaviour for them. Probably would be better to implement a new option to enable/disable autodetection.
Quoted 1 line
Thanks for you patience :-)
No problem :)
Signature · 1 line
Rgrds, legion
src/ksyms.c set_charset(const char *charset) { · line 1701
Quoted 9 lines · Michael Schutte
src/ksyms.c +1
-1@@ -1700,7 +1695,7 @@ set_charset(const char *charset) {if (p->name[0 ]) syms[0 ].table[i] = p->name; } - chosen_charset = charset; + chosen_charset =strdup (charset);return 0 ; } }
You have memory leak here. Try this for example:
./dumpkeys -c koi8-r -c koi8-u -c mazovia -c cp-1250 -n
Signature · 1 line
Rgrds, legion
Quoted 6 lines · Alexey Gladkov
<root># loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map <user>$ < I getting correct chars when I typing a russian text > <user>$ dumpkeys -n > dump-loadkeys.old
<root># src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map<user>$ < I getting wrong chars when I typing a russian text >
I see a strange thing. Characters on the console in unicode mode, after the src/loadkeys has been executed.
Signature · 1 line
Rgrds, legion
Quoted 11 lines · Alexey Gladkov
I tested exactly like that:
<user>$ src/unicode_stop
<user>$ export LANG=ru_RU.koi8r
<user>$ setfont data/consolefonts/koi8r-8x16<root># loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
<user>$ < I getting correct chars when I typing a russian text > <user>$ dumpkeys -n > dump-loadkeys.old
Quoted 8 lines
<root># src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
<user>$ < I getting wrong chars when I typing a russian text > <user>$ dumpkeys -n > dump-loadkeys.new
<root># loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map
<user>$ < correct chars again >
This is just weird :-(
Here’s what I get:
$ src/unicode_stop $ export LANG=ru_RU.koi8r $ setfont data/consolefonts/koi8r-8x16 # loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map # [some chars] # dumpkeys -n >dumpkeys.old # src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map # [the same chars] # dumpkeys -n >dumpkeys.new $ diff dumpkeys.* $
No differences at all. I fail to see what is going on here.
loadkeys is from master (86d0ca1) and src/loadkeys from master plus my patch, right? Just so we don’t talk about different codebases here.
Quoted 5 lines
Quoted 2 lines
Quoted 1 line
How do you test this patch?
Pretty much the way you do: loadkeys, typing some things,
Hmmm ... you typing in what language?
I tried it some with some Latin alphabets (the German, French, and Turkish keymaps), Cyrillic and Greek.
Quoted 4 lines
Your patch will change the behaviour. At least for the russian keymaps will need to add "charset" directive. We have 4 charsets (koi8-r, cp1251, cp855, iso8859-5 and utf8). Without "charset" you do not know what encoding is used in keymap.
The point is, my patch should not change the behaviour of loadkeys when it is called in the “traditional” way. If the console is in Unicode mode and the user loads a Unicode keymap, or if the console is in XLATE mode and the user loads a non-Unicode keymap, everything should work as
before: In these cases, loadkeys should perform no conversion at all. So there’s no problem if a file is missing a “charset” line as long as the user doesn’t change the way they use loadkeys – hence, no regression. And indeed, that’s exactly what the patch does on my system. I have yet to figure out why you are getting entirely different results.
Quoted 4 lines
Quoted 2 lines
The true reason why I want to push this, though, is that Debian’s version of kbd has had a similar patch since 2004.
I want to be completely sure it's working with old keymaps.
That is a top priority for me as well, of course. I would hate to break everyone’s systems in fancy unexpected ways.
Quoted 10 lines
Quoted 1 line
I’d like to get rid of this divergence without losing its useful features.
This is a good reason. :)
Quoted 1 line
This is why I’ve cleaned it up and why I’m discussing it with you now.
I am concerned keymaps legacy. We have a lot of keymaps that are not added to the kbd package. Your patch should support the old behaviour for them. Probably would be better to implement a new option to enable/disable autodetection.
I’m completely with you on the legacy part. Whether to make the auto-detection an opt-in feature, I leave for you to decide. First of all, I think that the bloody thing should work on every machine :-)
Quoted 10 lines · Alexey Gladkov
Quoted 6 lines · Alexey Gladkov
<root># loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map <user>$ < I getting correct chars when I typing a russian text > <user>$ dumpkeys -n > dump-loadkeys.old
<root># src/loadkeys data/keymaps/i386/qwerty/ruwin_cplk-KOI8-R.map<user>$ < I getting wrong chars when I typing a russian text >
I see a strange thing. Characters on the console in unicode mode, after the src/loadkeys has been executed.
This is very strange indeed. Firstly, this is not reflected in the dumps you sent me. And second, the KDSKBENT ioctls should fail if loadkeys even tries to assign Unicode keysyms in XLATE mode.
I’ll try to come up with an idea for what I am missing during this weekend. If you have got any thoughts as to what is going wrong, I would be glad to hear them.
Cheers,
Signature · 1 line
Michael Schutte <[email protected]>
Quoted 10 lines · Michael Schutte
Quoted 2 lines
I see a strange thing. Characters on the console in unicode mode, after the src/loadkeys has been executed.
This is very strange indeed. Firstly, this is not reflected in the dumps you sent me. And second, the KDSKBENT ioctls should fail if loadkeys even tries to assign Unicode keysyms in XLATE mode.
I’ll try to come up with an idea for what I am missing during this weekend. If you have got any thoughts as to what is going wrong, I would be glad to hear them.
I asked my friend for help and I confirm that your patch works correctly for debian.
Can you send me a url of your kernel package ?
Signature · 1 line
Rgrds, legion
Hi!
Quoted 10 lines · Alexey Gladkov
Quoted 3 lines · Michael Schutte
I’ll try to come up with an idea for what I am missing during this weekend. If you have got any thoughts as to what is going wrong, I would be glad to hear them.
I asked my friend for help and I confirm that your patch works correctly for debian.
Can you send me a url of your kernel package ?
I tested these:
http://packages.debian.org/lenny/linux-image-2.6.26-2-686 http://packages.ubuntu.com/intrepid/base/linux-image-2.6.27-11-generic http://packages.debian.org/sid/linux-image-2.6.29-1-686
I just checked the kernel patches for the last one: Only two of them affect drivers/char, but they don’t seem interesting as far as our problem is concerned. What’s your distro/kernel?
Could this be an architectural issue? I run only x86 machines here, perhaps you use amd64 or something else entirely? (Then again, your User-Agent header tells me you also run on i686.)
Regards,
Signature · 1 line
Michael Schutte <[email protected]>
Quoted 9 lines · Michael Schutte
I tested these:
http://packages.debian.org/lenny/linux-image-2.6.26-2-686 http://packages.ubuntu.com/intrepid/base/linux-image-2.6.27-11-generic http://packages.debian.org/sid/linux-image-2.6.29-1-686I just checked the kernel patches for the last one: Only two of them affect
drivers/char, but they don’t seem interesting as far as our problem is concerned. What’s your distro/kernel?
I use ALTLinux. Kernel is:
Do not shy of domain name. :)
Quoted 3 lines
Could this be an architectural issue? I run only x86 machines here, perhaps you use amd64 or something else entirely? (Then again, your User-Agent header tells me you also run on i686.)
Yes. i686
Signature · 1 line
Rgrds, legion
Quoted 1 line · Alexey Gladkov
I use ALTLinux.
Humm. I could have guessed that.
Quoted 5 lines
Kernel is:
Do not shy of domain name. :)
:-D
On Debian userland plus kernel-image-lks-wks-2.6.28-alt4, my patch still works. I also downloaded the ALTLinux 4.1.0 live CD from [1]; this one uses kernel 2.6.25-std-def-alt8.M41.1. I started it in qemu, copied over the patched loadkeys binary and tested it again. Still no problem!
I’m seriously confused why you are getting these weird results :-(
[1] http://en.altlinux.org/ALT_Linux_4.1_Desktop
Signature · 1 line
Michael Schutte <[email protected]>
Quoted 1 line · Alexey Gladkov
I use ALTLinux. Kernel is:
I terribly sorry. About two month ago I have tried to use the console-setup on my laptop and forgot to cleanup after this. I found a local regression in console scripts.
I confirm your patch.
Signature · 1 line
Rgrds, legion
tag 524057 fixed-upstream
thanks
Quoted 7 lines · Alexey Gladkov
I terribly sorry. About two month ago I have tried to use the console-setup on my laptop and forgot to cleanup after this. I found a local regression in console scripts.
I confirm your patch.
No problem, thanks for you work on this. Another patch, regarding the composition of Unicode characters, will follow soon :-)
Cheers,
Signature · 1 line
Michael Schutte <[email protected]>