From nobody Sat Feb 04 15:19:15 2023 X-Original-To: dev-commits-src-all@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 4P8GQZ13wXz3nW8b for ; Sat, 4 Feb 2023 15:19:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 4P8GQY6XHQz3xRq for ; Sat, 4 Feb 2023 15:19:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62a.google.com with SMTP id dr8so22864132ejc.12 for ; Sat, 04 Feb 2023 07:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.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=lriX9jDJSWYKgc+49R3c7cC/ksDLomGFqiBr4ObcHxY=; b=GGctMCeye+UkksQNVnsaKPkqdMQoFmP7NHfqLAExOXOOrHb6PTvwxaFxYpAGfxn/GQ 0r2oB9Yz9nJ/WfnqIGIBH+0plfvIMHC+aHob88dLRCbY7NIfddaJnB5bO+082IB+LYHu 4k8XytzZImgLmDU4eJq2yIW+J02lWoB0CNh5jAN+/ClI1lOEruP7v1AkD5MUVOFs3euB zWF1Q36VaP3ow+QE7zQ9SyLqZS63IVi0l3WCpqpA4V5i2s2ObwgYct8SyD+USx2aN7aF oNumIfCAZ0V/qtDetablSk4oJ/IsMeavi9bbsYw5MiX+DRjK6ITsHHN8ntoHpA0m+7/g UIDg== 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=lriX9jDJSWYKgc+49R3c7cC/ksDLomGFqiBr4ObcHxY=; b=2edpCqCQntRu0Bo3Xt/CooRBhnaSkz6kmTwkr7AM3dxKTsr2sAYzwzN9VHl3hL3byD yz2uKhj03bj89j7vUo6NDK8VBKEVCteZTBuY7ZIjoZAj+IxuzFIL80wQDEnsT1j2NkW5 FpQzhhxMLm+RaPl2SxJyy1QmgLhLcSmSYcFf4VKRAG5oXlbQAULMuI46ip4Wpjl3gj3W ZUxwGcHAvABxqqvbgrD5xNsPhKUNd+19UIQmFthNZQwg38Ms6N1NziPGklGh4PD371Th TbnQe0QY6DMuP4MzxvW5Oxl6F7eorCBcWab3kGF9x3/I5kd3ksGYwyJKut/+Yyv8ivb6 DvEw== X-Gm-Message-State: AO0yUKVMYNiYCyMQspC7ymGHRsFZPerNCKuQewlCqgTOCI3Pv98N+wFM OeewY0ezCGSMbT641qoRvDQ07AkSTlE48c0Vbo4wNQ== X-Google-Smtp-Source: AK7set+7i0Kr5Ww0nGB4drJ7l6W41bCxHtI4IOMN+4mBTNcYcj9ftvKfpFkX9CM0xjEeFrK6IBW1mHKM18kTqarGsxY= X-Received: by 2002:a17:906:d96d:b0:888:c14e:70b6 with SMTP id rp13-20020a170906d96d00b00888c14e70b6mr4394514ejb.306.1675523956086; Sat, 04 Feb 2023 07:19:16 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202302011630.311GUmt1068106@gitrepo.freebsd.org> <84830C1A-149F-4B05-99DC-1E0B50C8B59A@freebsd.org> <297c877d-2a2f-70cf-604c-e458634cb068@FreeBSD.org> In-Reply-To: <297c877d-2a2f-70cf-604c-e458634cb068@FreeBSD.org> From: Warner Losh Date: Sat, 4 Feb 2023 08:19:15 -0700 Message-ID: Subject: Re: git: 1e0853ee8403 - main - sys/kbio.h: support Unicode key codes in vt keymap files To: =?UTF-8?B?U3RlZmFuIEXDn2Vy?= Cc: Jessica Clarke , Emmanuel Vadot , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000372dcd05f3e15294" X-Rspamd-Queue-Id: 4P8GQY6XHQz3xRq X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000372dcd05f3e15294 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 4, 2023 at 6:35 AM Stefan E=C3=9Fer wrote: > Am 02.02.23 um 08:43 schrieb Jessica Clarke: > > On 1 Feb 2023, at 16:40, Jessica Clarke wrote: > >> > >> On 1 Feb 2023, at 16:30, Stefan E=C3=9Fer wrote: > >>> > >>> The branch main has been updated by se: > >>> > >>> URL: > https://cgit.FreeBSD.org/src/commit/?id=3D1e0853ee84031e4131a0b8cc8737696= f199d3d4c > >>> > >>> commit 1e0853ee84031e4131a0b8cc8737696f199d3d4c > >>> Author: Stefan E=C3=9Fer > >>> AuthorDate: 2023-02-01 16:24:18 +0000 > >>> Commit: Stefan E=C3=9Fer > >>> CommitDate: 2023-02-01 16:24:18 +0000 > >>> > >>> sys/kbio.h: support Unicode key codes in vt keymap files > >>> > >>> Some keyboard definitions return Unicode characters that cannot be > >>> represented in the 8 bits provided by an u_char. > >>> > >>> Extend then width of the keycode entries to 16 bits to allow for a= ll > >>> keycodes currently defined in share/vt/keymaps/*,kbd. > >>> > >>> Reported by: yuri@aetern.org > >>> MFC after: 3 days > >>> --- > >>> sys/sys/kbio.h | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h > >>> index 7f17bda76c51..b0779f5ed114 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]; > >>> + u_short map[NUM_ACCENTCHARS][2]; > >> > >> This breaks ABI for [GP]IO_DEADKEYMAP. > > > > Ping. This is important, especially with the MFC after. > > > > This should be reverted and re-landed with compat IMO. > > The patch has been reverted in commit f7e5465cb597 and a > patch set that offers ABI backwards compatibility has been > uploaded to phabricator for review as: > > https://reviews.freebsd.org/D38381 > > > The ioctl handler in kbd/kbd.c has been extended in the same > way as had been used to support 32 bit key codes in the main > key map (with similar backwards compatibility code). > > Support of kbdcontrol built with the patched kbio.h on an old > kernel could be added to kbdcontrol.c - but we do not support > running a new user land on an old kernel, in general. (The > old kbdcontrol on a new kernel could load the normal keymap, > but the dead key map would be ignored.) > "In general" is true. However, this case is on the edge of being one that we should do, based on how hard it is. You run into needing this if you boot an old kernel because the new kernel is broken on your hardware, but you've already done an install world (this happens, even for people that follow the rules sometimes for problems that aren't fatal to boot, but may be too crashy to build a new kernel). Since this affects one's ability to interact with the system with non-standard keyboards, how hard would it be to retain the old code as a fallback if the new ioctl fails to work? If it's quite hard, then we can skip it. If it isn't too hard, please consider it... Also, what's the behavior of the failure? Warner > I have used u_int for all values to be able to support the > full Unicode range, since this type has already been used for > the normal key code maps. > > > I'd appreciate a quick review to be able to MFC to -STABLE in > time for inclusion in the upcoming 13.2 release ... > > Regards, STefan > --000000000000372dcd05f3e15294 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Feb 4, 2023 at 6:35 AM Stefan= E=C3=9Fer <se@freebsd.org> wro= te:
Am 02.02.23 = um 08:43 schrieb Jessica Clarke:
> On 1 Feb 2023, at 16:40, Jessica Clarke <jrtc27@FreeBSD.org> wro= te:
>>
>> On 1 Feb 2023, at 16:30, Stefan E=C3=9Fer <se@FreeBSD.org> w= rote:
>>>
>>> The branch main has been updated by se:
>>>
>>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D1e0853ee84031e4131a0b8cc8737696f1= 99d3d4c
>>>
>>> commit 1e0853ee84031e4131a0b8cc8737696f199d3d4c
>>> Author:=C2=A0 =C2=A0 =C2=A0Stefan E=C3=9Fer <se@FreeBSD.org= >
>>> AuthorDate: 2023-02-01 16:24:18 +0000
>>> Commit:=C2=A0 =C2=A0 =C2=A0Stefan E=C3=9Fer <se@FreeBSD.org= >
>>> CommitDate: 2023-02-01 16:24:18 +0000
>>>
>>>=C2=A0 =C2=A0 sys/kbio.h: support Unicode key codes in vt keyma= p files
>>>
>>>=C2=A0 =C2=A0 Some keyboard definitions return Unicode characte= rs that cannot be
>>>=C2=A0 =C2=A0 represented in the 8 bits provided by an u_char.<= br> >>>
>>>=C2=A0 =C2=A0 Extend then width of the keycode entries to 16 bi= ts to allow for all
>>>=C2=A0 =C2=A0 keycodes currently defined in share/vt/keymaps/*,= kbd.
>>>
>>>=C2=A0 =C2=A0 Reported by:=C2=A0 =C2=A0 =C2=A0 =C2=A0yuri@aetern.org
>>>=C2=A0 =C2=A0 MFC after:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03 day= s
>>> ---
>>> sys/sys/kbio.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
>>> index 7f17bda76c51..b0779f5ed114 100644
>>> --- a/sys/sys/kbio.h
>>> +++ b/sys/sys/kbio.h
>>> @@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
>>>
>>> struct acc_t {
>>>=C2=A0 =C2=A0 =C2=A0u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ac= cchar;
>>> -=C2=A0 =C2=A0u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 map[NUM= _ACCENTCHARS][2];
>>> +=C2=A0 =C2=A0u_short=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0map[NUM= _ACCENTCHARS][2];
>>
>> This breaks ABI for [GP]IO_DEADKEYMAP.
>
> Ping. This is important, especially with the MFC after.
>
> This should be reverted and re-landed with compat IMO.

The patch has been reverted in commit f7e5465cb597 and a
patch set that offers ABI backwards compatibility has been
uploaded to phabricator for review as:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://reviews.freebsd.org/D38381=


The ioctl handler in kbd/kbd.c has been extended in the same
way as had been used to support 32 bit key codes in the main
key map (with similar backwards compatibility code).

Support of kbdcontrol built with the patched kbio.h on an old
kernel could be added to kbdcontrol.c - but we do not support
running a new user land on an old kernel, in general. (The
old kbdcontrol on a new kernel could load the normal keymap,
but the dead key map would be ignored.)

"In general" is true. However, this case is on the edge of being=
one that we should do, based on how hard it is. You run into
needing this if you boot an old kernel because the new kernel
<= div>is broken on your hardware, but you've already done an install
world (this happens, even for people that follow the rules sometimes<= /div>
for problems that aren't fatal to boot, but may be too crashy=
to build a new kernel). Since this affects one's ability to = interact
with the system with non-standard keyboards, how hard wo= uld
it be to retain the old code as a fallback if the new ioctl f= ails to
work? If it's quite hard, then we can skip it. If it = isn't too hard,
please consider it...=C2=A0 Also, what's = the behavior of the failure?

Warner
= =C2=A0
I have used u_int for all values to be able to support the
full Unicode range, since this type has already been used for
the normal key code maps.


I'd appreciate a quick review to be able to MFC to -STABLE in
time for inclusion in the upcoming 13.2 release ...
= =C2=A0
Regards, STefan
--000000000000372dcd05f3e15294--