Re: git: 1e0853ee8403 - main - sys/kbio.h: support Unicode key codes in vt keymap files

On Sat, Feb 4, 2023 at 6:35 AM Stefan Eßer <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ßer <se@FreeBSD.org> wrote:
> >>>
> >>> The branch main has been updated by se:
> >>>
> >>> URL:
> https://cgit.FreeBSD.org/src/commit/?id=1e0853ee84031e4131a0b8cc8737696f199d3d4c
> >>>
> >>> commit 1e0853ee84031e4131a0b8cc8737696f199d3d4c
> >>> Author:     Stefan Eßer <se@FreeBSD.org>
> >>> AuthorDate: 2023-02-01 16:24:18 +0000
> >>> Commit:     Stefan Eßer <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 all
> >>>    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
>