Re: [kbd] [PATCH] src/libkeymap: add support for parsing more unicode values

On Mon, Mar 01, 2021 at 03:49:52PM +0100, Anisse Astier wrote:
> On Mon, Mar 01, 2021 at 03:09:39PM +0100, Alexey Gladkov wrote:
> > On Sat, Feb 27, 2021 at 03:36:11PM +0100, Anisse Astier wrote:
> > > The auto-generated (with ckbcomp) file fr-bepo_afnor did not load (even
> > > partially), because of an U+1f12f (copyleft symbol) that is wrongly
> > > parsed, generating this error message:
> > > 
> > > 	too many (160) entries on one line
> > > 
> > > Fix libkeymap so that the keymap can be parsed, even if the offending
> > > character won't be loaded because of the ushort limitation of the
> > > kb_value KDSKBENT uapi.
> > > 
> > > It's better to have the keymap partially loaded than not at all.
> > 
> > Nop. Partially keymap loading is very dangerous. You can get a completely
> > unusable console. The libkeymap shouldn't break the console if it is known
> 
> By partially, I meant that only a single character of a single key
> wouldn't load. I'm curious, what would be the implications here ? How
> could it break ?

In this particular case, nothing will happen. An unicode character will
not be loaded and the user will probably see a warning. And this approach
is the best way to do it.

> I tried loading this keymap, and didn't see any averse effect. The
> character was missing, and that's about it. Why wouldn't we want that ?

>From the point of view of keymap processing in the kernel, such a keymap
is not valid. I believe that the library should report the fact of an
error in the keymap as early as possible.

Speaking of such restrictions, I would like to remind you that libkeymap
also has a restriction on the number of keys, but technically libkeymap
could parse more keys.

> > in advance that the keymap is not correct. You should fix ckbcomp so that
> > it generates the correct keymap.
> > 
> 
> I thought about doing this too, but it would mean not recognizing a
> valid (albeit unsupported) unicode symbol. At least here the parsing
> works, even if this particular symbol isn't loaded because of kernel
> console limitations.
> 
> It feels weird to use the U+ unicode symbol notation, and then refuse to
> load 2/3rd of those.

>From the point of view of the kernel, unicode symbols greater than 0xf000
are not valid.

-- 
Rgrds, legion