From nobody Sun Jan 29 07:52:08 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P4Np555cgz3blkC for ; Sun, 29 Jan 2023 07:52:45 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P4Np52JFmz3C6C for ; Sun, 29 Jan 2023 07:52:45 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc2a.google.com with SMTP id y26-20020a4ad65a000000b005173859761dso487079oos.1 for ; Sat, 28 Jan 2023 23:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fv9Nr0lm/pu4oVPmdUAE9gassrSYhhk1+nu8LolCops=; b=Tp/cKhOfDayRhTXi4FYi064y3BQSxBPWSIqszwg9DVT2ayMCSo9rW9H4lLjqdAS2hA WNdcmkoWJ4kbTlsXICBM+T2udANCNUtHc/+/xvJeHiyDNtmWKN0kwiRKvWe4WHyUCnfF Uet0+v70HZcFlB7UV5ymEGv37/gMTF850e3DtSeLp2IwA4QpYsoQe6zkXw+P1HOj+6Ug rfhidHVOX32plqCaEhkNCxvqK13nKOERYiMeCowYgvZBAZ7LjLPeqgw+VZPegZl5N+lo Ly74ZhML3Pyug0IrguT060ZC7QxXvDzdstrnYVeircFCRgXQWwCbJTy3HGkY7mJsAEz+ wSBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fv9Nr0lm/pu4oVPmdUAE9gassrSYhhk1+nu8LolCops=; b=pJ23xRMpFOSxQ+SMcZcZQ4Fc+L4lBCtRaM/F1sgNQV7mqeZqhidP7qdF7Tw2s5CRPP mweGX6hrN6A7rDtKMIAMjWzj/gZzcc8Vz9oc6SxhVhIOJBCqIdyRu18wd55QC5cYqKKZ 2Yb8Gz+DYgdeYlYUv4fm5gFJwsQm4o5FAA8kJYYxZ8k3mLVLnwHS8o1DO53Womd9237c aLOqrAsUWnHDmZ8nCaAA9Iu3ubmUgZ6kx4xH160uKe03X3WRTk2/1dxWfJb55DQN+RKb cyTXG/+6Wb4j0dsREguFJvIdHs8izzy82zSb7wPHWHw0+E6Knpjq2R8kgw5j5ZSg192l rk7g== X-Gm-Message-State: AFqh2kpRHNXVsXB3uOQnG4f7Dm2HWCO6mU/yh2XPpyefhuFvG23GDk5r kWrX//Njqr1sh4gyiVPWRlpMnU2Kr/IkRkKwc5p/9cPxGXQ= X-Google-Smtp-Source: AMrXdXt3YGn3Bwg739gr6Qs8ifDSI8tSuxgyIZRuC3ediZiCNFPz6fVX64FtrKKP1jPSsCeSIfIeK3bvvgKIDyl46NA= X-Received: by 2002:a4a:b790:0:b0:4ff:6314:ed87 with SMTP id a16-20020a4ab790000000b004ff6314ed87mr1498477oop.35.1674978764047; Sat, 28 Jan 2023 23:52:44 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <70f53d17-46eb-c299-1a93-bf28858c1685@aetern.org> In-Reply-To: From: Mehmet Erol Sanliturk Date: Sun, 29 Jan 2023 10:52:08 +0300 Message-ID: Subject: Re: vt and keyboard accents To: Hans Petter Selasky Cc: Yuri , current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003cc82805f3626254" X-Rspamd-Queue-Id: 4P4Np52JFmz3C6C X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000003cc82805f3626254 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 29, 2023 at 10:16 AM 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 readin= g: > > > > 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=C3=9Fer > > 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)! > > --HPS > > I am not an expert on UNICODE . When character sets are considered , a homogeneous definition for all of the FreeBSD system would be more useful . There are mainly three types of Unicode : UTF-8 , UTF-16 , and UTF-32 where numbers are bit sizes of the characters . Some pages about Unicode where they have many linked sub pages : https://en.wikipedia.org/wiki/Category:Unicode Category:Unicode https://en.wikipedia.org/wiki/Unicode Unicode https://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings Comparison of Unicode encodings https://en.wikipedia.org/wiki/List_of_binary_codes List of binary codes https://en.wikipedia.org/wiki/List_of_information_system_character_sets List of information system character sets and other related pages ... With my best wishes for all . Mehmet Erol Sanliturk --0000000000003cc82805f3626254 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 29, 2023 at 10:16= AM Hans Petter Selasky <hps@selasky.= org> 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 readi= ng:
>
> kbdcontrol:
>=C2=A0 =C2=A0 dacu=C2=A0 180=C2=A0 ( 180 180 ) ( 'S' 'Z'= ; ) ( 'Z' 'y' ) ( 's' '[' )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'z' &#= 39;z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' &= #39;9' )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'C' 00= 6 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'O' 21= 1 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'a' 22= 5 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'i' 23= 7 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'y' 25= 3 )
>
> keymap:
>=C2=A0 =C2=A0 dacu 0xb4=C2=A0 =C2=A0 ( 0xb4=C2=A0 =C2=A00xb4=C2=A0 =C2= =A0 ) ( 'S'=C2=A0 =C2=A0 0x015a=C2=A0 ) ( 'Z'=C2=A0 =C2=A0 = 0x0179=C2=A0 )
> ( 's'=C2=A0 =C2=A0 0x015b=C2=A0 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'z&= #39;=C2=A0 =C2=A0 0x017a=C2=A0 ) ( 'R'=C2=A0 =C2=A0 0x0154=C2=A0 ) = ( 'A'=C2=A0 =C2=A0 0xc1=C2=A0 =C2=A0 )
> ( 'L'=C2=A0 =C2=A0 0x0139=C2=A0 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'C&= #39;=C2=A0 =C2=A0 0x0106=C2=A0 ) ( 'E'=C2=A0 =C2=A0 0xc9=C2=A0 =C2= =A0 ) ( 'I'=C2=A0 =C2=A0 0xcd=C2=A0 =C2=A0 )
> ( 'N'=C2=A0 =C2=A0 0x0143=C2=A0 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'O&= #39;=C2=A0 =C2=A0 0xd3=C2=A0 =C2=A0 ) ( 'U'=C2=A0 =C2=A0 0xda=C2=A0= =C2=A0 ) ( 'Y'=C2=A0 =C2=A0 0xdd=C2=A0 =C2=A0 )
> ( 'r'=C2=A0 =C2=A0 0x0155=C2=A0 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'a&= #39;=C2=A0 =C2=A0 0xe1=C2=A0 =C2=A0 ) ( 'l'=C2=A0 =C2=A0 0x013a=C2= =A0 ) ( 'c'=C2=A0 =C2=A0 0x0107=C2=A0 )
> ( 'e'=C2=A0 =C2=A0 0xe9=C2=A0 =C2=A0 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'i&= #39;=C2=A0 =C2=A0 0xed=C2=A0 =C2=A0 ) ( 'n'=C2=A0 =C2=A0 0x0144=C2= =A0 ) ( 'o'=C2=A0 =C2=A0 0xf3=C2=A0 =C2=A0 )
> ( 'u'=C2=A0 =C2=A0 0xfa=C2=A0 =C2=A0 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( 'y&= #39;=C2=A0 =C2=A0 0xfd=C2=A0 =C2=A0 )
>
> Source of the problem is the following definition in sys/sys/kbio.h: >
> struct acc_t {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 accchar;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 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<= br> > there a reason for this?
>
> ---
> commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
> Author: Stefan E=C3=9Fer <se@FreeBSD.org>
> Date:=C2=A0 =C2=A0Sun Aug 17 19:54:21 2014 +0000
>
>=C2=A0 =C2=A0 =C2=A0 Attempt at converting the SYSCONS keymaps to Unico= de for use with
> NEWCONS.
>=C2=A0 =C2=A0 =C2=A0 I have spent many hours comparing source and desti= nation formats,
> and hope
>=C2=A0 =C2=A0 =C2=A0 to have caught the most severe conversion errors.<= br> > ---
>
> 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;
>
>=C2=A0 =C2=A0struct acc_t {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 accchar;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= ap[NUM_ACCENTCHARS][2];
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0int=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0map[NUM_ACCENTCHARS][2];
>=C2=A0 =C2=A0};
>

Hi,

Using "int" for unicode characters is probably good for now. Your= patch
looks good, but please also consider the "umlaut" case while at i= t
(multiple characters that become one)!

--HPS




=
I am not an expert on UNICODE .

When character sets ar= e considered , a homogeneous definition for all of the FreeBSD system would= be more useful .
There are mainly three types of Unicode : UTF-8 , = UTF-16 , and UTF-32 where numbers are bit sizes of the characters .


Some pages about Unicode where they have many l= inked sub pages :



https://en.wikipedia.org/wiki/= Category:Unicode
Category:Unicode


Unicode

Comparison of Unic= ode encodings

List of binary codes

<= br>
List of information system character sets=


and other related pages ...


With my best wishes for all .

<= div style=3D"font-family:monospace;font-size:large" class=3D"gmail_default"= >
Mehmet Erol Sanliturk



<= /div>


=C2=A0
--0000000000003cc82805f3626254--