[BRLTTY] ‘empty console’

[Sebastian Humenda]

Hi

Nicolas Pitre schrieb am Wed, Nov 27, 2019 at 12:38:29PM -0500:
> On Wed, 27 Nov 2019, Sebastian Humenda wrote:
> > Nicolas Pitre schrieb am Tue, Nov 26, 2019 at 04:44:42PM -0500:
> > > What does "stty -a" give you, with and without the font change? More
> > > specifically, what are the reported rows and columns values on the first
> > > output line?
> >
> > Font size 8 x 16 (non-frame buffer font)
> >
> > speed 38400 baud; rows 90; columns 320; line = 0;
> >
> > From small to large, the smallest working font size is  11 x 22, terminus:
> >
> > speed 38400 baud; rows 65; columns 232; line = 0;
>
> OK! That's it.
>
> The /dev/vcsa device from which BRLTTY gets screen dimensions and the
> cursor position uses a header which fields are only 8-bit wide.  When
> this header was created (must be more than 20 years ago at this point)
> no one expected screens to hold more than 255 rows and/or lines.
>
> More recently, to avoid returning random garbage, the kernel code
> started clamping those values to 255 if the actual value is larger. Your
> 320 columns therefore gets clamped to 255 and that's what BRLTTY uses.
>
> So, in practice, your braille window is probably located in the middle
> of the actual screen where there is no content.  For example, BRLTTY
> would seek content for line 2 column 1 from the screen location that
> actually corresponds to line 1 column 256.

Your description is far better then what I could have described. All your bets
you won.

> On the BRLTTY's side, there could possibly be a way to use TIOCGWINSZ on
> the console device when vcsa returns 255 on the screen dimension. But
> that won't help with cursor position beyond 255 though. At least the
> user could then be warned.

How do other applications work around this limitation? E.g. Tmux? Wouldn't
they need to tinker with overlong lines as  well?
Limiting BRLTTY users to screens with a larger font just because Linux cannot
deal with it doesn't seem appealing. I suppose the vcsa header cannot be fixed
due to backward compatibility concerns. What about the vcsu headers, do they
expose similar information, would it be worth discussing with Linux devs
changing it there?


Thanks
Sebastian