Message-ID: <nycvar.YSQ.7.76.1806202210500.16670@knanqh.ubzr>
Date:   Wed, 20 Jun 2018 22:59:08 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Adam Borowski <kilobyte@...band.pl>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dave Mielke <Dave@...lke.cc>,
        Samuel Thibault <samuel.thibault@...-lyon.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Thu, 21 Jun 2018, Adam Borowski wrote:

> On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote:
> > On Tue, 19 Jun 2018, Adam Borowski wrote:
> > > Thus, it'd be nice to use the structure you add to implement full Unicode
> > > range for the vast majority of people.  This includes even U+2800..FF.  :)
> > 
> > Be my guest if you want to use this structure. As for U+2800..FF, like I 
> > said earlier, this is not what most people use when communicating, so it 
> > is of little interest even to blind users except for displaying native 
> > braille documents, or showing off. ;-)
> 
> It's meant for displaying braille to _sighted_ people.  And in real world,
> the main [ab]use is a way to show images that won't get corrupted by
> proportional fonts. :-þ

⠨⠺⠑⠇⠇⠂ ⠥⠎⠊⠝⠛ ⠇⠁⠞⠑⠎⠞ ⠨⠨⠃⠗⠇⠞⠞⠽ ⠊⠞ ⠊⠎ ⠏⠕⠎⠎⠊⠃⠇⠑ ⠞⠕ ⠞⠽⠏⠑ ⠁⠝⠙ ⠙⠊⠎⠏⠇⠁⠽ ⠝⠁⠞⠊⠧⠑ 
⠃⠗⠁⠊⠇⠇⠑ ⠕⠝ ⠁ ⠃⠗⠁⠊⠇⠇⠑ ⠞⠑⠗⠍⠊⠝⠁⠇ ⠕⠝⠉⠑ ⠞⠓⠊⠎ ⠏⠁⠞⠉⠓ ⠎⠑⠗⠊⠑⠎ ⠊⠎ ⠁⠏⠏⠇⠊⠑⠙ ⠞⠕ ⠞⠓⠑ 
⠅⠑⠗⠝⠑⠇⠂ ⠊⠗⠗⠑⠎⠏⠑⠉⠞⠊⠧⠑ ⠕⠋ ⠞⠓⠑ ⠁⠉⠞⠥⠁⠇ ⠉⠕⠝⠎⠕⠇⠑ ⠋⠕⠝⠞ ⠊⠝ ⠥⠎⠑⠲ ⠨⠁⠝⠙ ⠋⠕⠗ ⠞⠓⠁⠞ ⠺⠑ 
⠥⠎⠑ ⠉⠕⠗⠗⠑⠎⠏⠕⠝⠙⠊⠝⠛ ⠥⠝⠊⠉⠕⠙⠑ ⠉⠓⠁⠗⠁⠉⠞⠑⠗⠎⠲

> > If the core console code makes the switch to full unicode then yes, that 
> > would be the way to go to maintain backward compatibility. However 
> > vgacon users would see a performance drop when switching between VT's 
> > and we used to brag about how fast the Linux console used to be 20 years 
> > ago. Does it still matter today?
> 
> I've seen this slowness.  A long time ago, on a server that someone gave an
> _ISA_ graphics card (it was an old machine, and it was 1.5 decades ago). 
> Indeed, switching VTs took around a second.  But this was drawing speed, not
> Unicode conversion.
> 
> There are three cases when a character can enter the screen:
> * being printed by the tty.  This is the only case not sharply rate-limited.
>   It already has to do the conversion.  If we eliminate the old struct, it
>   might even be a speed-up when lots of text gets blasted to a non-active
>   VT.

That's a good point.

> * VT switch
> * scrollback
> 
> The last two cases are initiated by the user, and within human reaction time
> you need to convert usually 2000 -- up to 20k-ish -- characters.  The
> conversion is done by a 3-level array.  I think a ZX Spectrum can handle
> this fine without a visible slowdown.

In the scrollback case, currently each driver is doing its own thing. 
The vgacon driver is probably the most efficient as it only moves the 
base memory register around without copying anything at all. And that 
part doesn't have to change.

> The primary users would be:
> * people who want symbols uncorrupted (especially if their language uses a
>   non-latin script)
> * CJK people (as discussed below)
> 
> It could also simplify the life for distros -- less required configuration:
> a single font needed for currently supported charsets together has mere
> ~1000 glyphs, at 8x16 that's 16000 bytes (+ mapping).  Obviously for CJK
> that's more.
>  
> > > So I'm only mentioning possible changes; they could possibly go after
> > > your patchset goes in:
> > > 
> > > A) if memory is considered to be at premium, what about storing only one
> > >    32-bit value, masked 21 bits char 11 bits attr?  On non-vgacon, there's
> > >    no reason to keep the old structures.
> > 
> > Absolutely. As soon as vgacon is officially relegated to second class 
> > citizen i.e. perform the glyph translation each time it requires 
> > a refresh instead of dictating how the core console code works then the 
> > central glyph buffer can go.
> 
> Per the analysis above, on-the-fly translation is so unobtrusive that it
> shouldn't be a problem.
> 
> > > B) if being this frugal wrt memory is ridiculous today, what about instead
> > >    going for 32 bits char (wasteful) 32 bits attr?  This would be much nicer
> > >    15 bit fg color + 15 bit bg color + underline + CJK or something.
> > > You already triple memory use; variant A) above would reduce that to 2x,
> > > variant B) to 4x.
> > 
> > You certainly won't find any objections from me.
> 
> Right, let's see if your patchset gets okayed before building atop it.

May I add your ACK to it?


Nicolas

Powered by blists - more mailing lists