Re: vt and keyboard accents

Hans Petter Selasky wrote:
> On 1/29/23 01:54, Yuri wrote:
>> Looking into an issue with accents input for vt and cz (so
>> /usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
>> working and other result weird unrelated characters output.
>>
>> Checking kbdcontrol -d output, there is an obvious difference with
>> keymap contents -- all mappings are trimmed down to 1 byte after reading:
>>
>> kbdcontrol:
>>    dacu  180  ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
>>               ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
>>               ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
>>               ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
>>               ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
>>               ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
>>               ( 'y' 253 )
>>
>> keymap:
>>    dacu 0xb4    ( 0xb4   0xb4    ) ( 'S'    0x015a  ) ( 'Z'    0x0179  )
>> ( 's'    0x015b  )
>>                 ( 'z'    0x017a  ) ( 'R'    0x0154  ) ( 'A'    0xc1    )
>> ( 'L'    0x0139  )
>>                 ( 'C'    0x0106  ) ( 'E'    0xc9    ) ( 'I'    0xcd    )
>> ( 'N'    0x0143  )
>>                 ( 'O'    0xd3    ) ( 'U'    0xda    ) ( 'Y'    0xdd    )
>> ( 'r'    0x0155  )
>>                 ( 'a'    0xe1    ) ( 'l'    0x013a  ) ( 'c'    0x0107  )
>> ( 'e'    0xe9    )
>>                 ( 'i'    0xed    ) ( 'n'    0x0144  ) ( 'o'    0xf3    )
>> ( 'u'    0xfa    )
>>                 ( 'y'    0xfd    )
>>
>> Source of the problem is the following definition in sys/sys/kbio.h:
>>
>> struct acc_t {
>>          u_char          accchar;
>>          u_char          map[NUM_ACCENTCHARS][2];
>> };
>>
>> While the keymaps were converted to have the unicode characters for vt
>> in the commit below, the array to store them (map) was missed, or was
>> there a reason for this?
>>
>> ---
>> commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
>> Author: Stefan Eßer <se@FreeBSD.org>
>> Date:   Sun Aug 17 19:54:21 2014 +0000
>>
>>      Attempt at converting the SYSCONS keymaps to Unicode for use with
>> NEWCONS.
>>      I have spent many hours comparing source and destination formats,
>> and hope
>>      to have caught the most severe conversion errors.
>> ---
>>
>> I have tried the following patch and it allows me to enter all accents
>> documented in the keymap, though I must admit I'm not sure it does not
>> have hidden issues:
>>
>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
>> index 7f17bda76c5..fffeb63e226 100644
>> --- a/sys/sys/kbio.h
>> +++ b/sys/sys/kbio.h
>> @@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
>>
>>   struct acc_t {
>>          u_char          accchar;
>> -       u_char          map[NUM_ACCENTCHARS][2];
>> +       int             map[NUM_ACCENTCHARS][2];
>>   };
>>
> 
> Hi,
> 
> Using "int" for unicode characters is probably good for now. Your patch
> looks good, but please also consider the "umlaut" case while at it
> (multiple characters that become one)!

I think umlauts are already part of "accents" (duml keyword), e.g. in
cz.kbd:

  duml 0xa8    ( 0xa8   0xa8    ) ( 'A'    0xc4    ) ( 'E'    0xcb    )
( 'O'    0xd6    )
               ( 'U'    0xdc    ) ( 'a'    0xe4    ) ( 'e'    0xeb    )
( 'o'    0xf6    )
               ( 'u'    0xfc    )

So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
of the ÄËÖÜäëöü characters can be written as single-byte unicode.

And the following dcar (that is, "caron") characters are all broken as
they need at least 2 bytes, pressing Shift and "=/+" key, and any of the
LSTZlstzCEDNRcednrUu would print nothing at all, produce garbage, or
print some control character (last byte only):

  dcar 0x02c7  ( 0x02c7 0x02c7  ) ( 'L'    0x013d  ) ( 'S'    0x0160  )
( 'T'    0x0164  )
               ( 'Z'    0x017d  ) ( 'l'    0x013e  ) ( 's'    0x0161  )
( 't'    0x0165  )
               ( 'z'    0x017e  ) ( 'C'    0x010c  ) ( 'E'    0x011a  )
( 'D'    0x010e  )
               ( 'N'    0x0147  ) ( 'R'    0x0158  ) ( 'c'    0x010d  )
( 'e'    0x011b  )
               ( 'd'    0x010f  ) ( 'n'    0x0148  ) ( 'r'    0x0159  )
( 'U'    0x016e  )
               ( 'u'    0x016f  )