Date: Sat, 4 Feb 2023 08:19:15 -0700 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?B?U3RlZmFuIEXDn2Vy?= <se@freebsd.org> Cc: Jessica Clarke <jrtc27@freebsd.org>, Emmanuel Vadot <manu@bidouilliste.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: 1e0853ee8403 - main - sys/kbio.h: support Unicode key codes in vt keymap files Message-ID: <CANCZdfofADsJg7ODDO1UbkKdau9V_TSA4psAsDjNf_1-=CrHQg@mail.gmail.com> In-Reply-To: <297c877d-2a2f-70cf-604c-e458634cb068@FreeBSD.org> References: <202302011630.311GUmt1068106@gitrepo.freebsd.org> <B18FC1EA-29B9-45A8-A666-35F975424256@freebsd.org> <84830C1A-149F-4B05-99DC-1E0B50C8B59A@freebsd.org> <297c877d-2a2f-70cf-604c-e458634cb068@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <se@freebsd.org> wrote: > Am 02.02.23 um 08:43 schrieb Jessica Clarke: > > On 1 Feb 2023, at 16:40, Jessica Clarke <jrtc27@FreeBSD.org> wrote: > >> > >> On 1 Feb 2023, at 16:30, Stefan E=C3=9Fer <se@FreeBSD.org> 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 <se@FreeBSD.org> > >>> AuthorDate: 2023-02-01 16:24:18 +0000 > >>> Commit: Stefan E=C3=9Fer <se@FreeBSD.org> > >>> 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb 4, 2023 at 6:35 AM Stefan= E=C3=9Fer <<a href=3D"mailto:se@freebsd.org">se@freebsd.org</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 02.02.23 = um 08:43 schrieb Jessica Clarke:<br> > On 1 Feb 2023, at 16:40, Jessica Clarke <jrtc27@FreeBSD.org> wro= te:<br> >><br> >> On 1 Feb 2023, at 16:30, Stefan E=C3=9Fer <se@FreeBSD.org> w= rote:<br> >>><br> >>> The branch main has been updated by se:<br> >>><br> >>> URL: <a href=3D"https://cgit.FreeBSD.org/src/commit/?id=3D1e08= 53ee84031e4131a0b8cc8737696f199d3d4c" rel=3D"noreferrer" target=3D"_blank">= https://cgit.FreeBSD.org/src/commit/?id=3D1e0853ee84031e4131a0b8cc8737696f1= 99d3d4c</a><br> >>><br> >>> commit 1e0853ee84031e4131a0b8cc8737696f199d3d4c<br> >>> Author:=C2=A0 =C2=A0 =C2=A0Stefan E=C3=9Fer <se@FreeBSD.org= ><br> >>> AuthorDate: 2023-02-01 16:24:18 +0000<br> >>> Commit:=C2=A0 =C2=A0 =C2=A0Stefan E=C3=9Fer <se@FreeBSD.org= ><br> >>> CommitDate: 2023-02-01 16:24:18 +0000<br> >>><br> >>>=C2=A0 =C2=A0 sys/kbio.h: support Unicode key codes in vt keyma= p files<br> >>><br> >>>=C2=A0 =C2=A0 Some keyboard definitions return Unicode characte= rs that cannot be<br> >>>=C2=A0 =C2=A0 represented in the 8 bits provided by an u_char.<= br> >>><br> >>>=C2=A0 =C2=A0 Extend then width of the keycode entries to 16 bi= ts to allow for all<br> >>>=C2=A0 =C2=A0 keycodes currently defined in share/vt/keymaps/*,= kbd.<br> >>><br> >>>=C2=A0 =C2=A0 Reported by:=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D= "mailto:yuri@aetern.org" target=3D"_blank">yuri@aetern.org</a><br> >>>=C2=A0 =C2=A0 MFC after:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03 day= s<br> >>> ---<br> >>> sys/sys/kbio.h | 2 +-<br> >>> 1 file changed, 1 insertion(+), 1 deletion(-)<br> >>><br> >>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h<br> >>> index 7f17bda76c51..b0779f5ed114 100644<br> >>> --- a/sys/sys/kbio.h<br> >>> +++ b/sys/sys/kbio.h<br> >>> @@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;<br> >>><br> >>> struct acc_t {<br> >>>=C2=A0 =C2=A0 =C2=A0u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ac= cchar;<br> >>> -=C2=A0 =C2=A0u_char=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 map[NUM= _ACCENTCHARS][2];<br> >>> +=C2=A0 =C2=A0u_short=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0map[NUM= _ACCENTCHARS][2];<br> >><br> >> This breaks ABI for [GP]IO_DEADKEYMAP.<br> > <br> > Ping. This is important, especially with the MFC after.<br> > <br> > This should be reverted and re-landed with compat IMO.<br> <br> The patch has been reverted in commit f7e5465cb597 and a<br> patch set that offers ABI backwards compatibility has been<br> uploaded to phabricator for review as:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://reviews.freebsd.org/D38381" = rel=3D"noreferrer" target=3D"_blank">https://reviews.freebsd.org/D38381</a>= <br> <br> <br> The ioctl handler in kbd/kbd.c has been extended in the same<br> way as had been used to support 32 bit key codes in the main<br> key map (with similar backwards compatibility code).<br> <br> Support of kbdcontrol built with the patched kbio.h on an old<br> kernel could be added to kbdcontrol.c - but we do not support<br> running a new user land on an old kernel, in general. (The<br> old kbdcontrol on a new kernel could load the normal keymap,<br> but the dead key map would be ignored.)<br></blockquote><div><br></div><div= >"In general" is true. However, this case is on the edge of being= </div><div>one that we should do, based on how hard it is. You run into</di= v><div>needing this if you boot an old kernel because the new kernel</div><= div>is broken on your hardware, but you've already done an install</div= ><div>world (this happens, even for people that follow the rules sometimes<= /div><div>for problems that aren't fatal to boot, but may be too crashy= </div><div>to build a new kernel). Since this affects one's ability to = interact</div><div>with the system with non-standard keyboards, how hard wo= uld</div><div>it be to retain the old code as a fallback if the new ioctl f= ails to</div><div>work? If it's quite hard, then we can skip it. If it = isn't too hard,</div><div>please consider it...=C2=A0 Also, what's = the behavior of the failure?</div><div><br></div><div>Warner<br></div><div>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I have used u_int for all values to be able to support the<br> full Unicode range, since this type has already been used for<br> the normal key code maps.<br> <br> <br> I'd appreciate a quick review to be able to MFC to -STABLE in<br> time for inclusion in the upcoming 13.2 release ...<br></blockquote><div>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Regards, STefan<br> </blockquote></div></div> --000000000000372dcd05f3e15294--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfofADsJg7ODDO1UbkKdau9V_TSA4psAsDjNf_1-=CrHQg>