[BRLTTY] BRLTTY in GRUB

[Dave Mielke]

[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/16 at 17:56 +0100]

>The only problem is relatively important dependencies (On Debian sudo
>aptitude build-dep grub-pc). 

My systems aren't Debian. I guess this'll be a problem.

>grub_dprintf by default discards the messages. If it's activated
>(e.g. debug=brltty) it prints the messages on screen. Is there a risk
>of this making brltty fall into loop over this?

I suppose the only problem would be if the number of lines on the rendered 
screen isn't limited in some way to protect against memory being consumed.

Brltty itself should be okay. It knows which line of the screen it's on. Only 
two things will cause it to move away from that line. One is direct user 
request. The other is a feature it has called cursor tracking. If cursor 
tracking is enabled, which is usually the case, then it automatically jumps to 
where the cursor is whenever the cursor moves.

This reminds me that the rendered screen also needs to know which row and 
column the cursor is at. Another helpful piece of information would be the 
length of the longest line.

So, to collect all of this in one place, we have:

At the screen level:
   The row and column of the cursor location.
   The number of lines.
   The length of the longest line.

For each line:
   The length of the line.
   The characters on the line.

For each character:
   Its Unicode value.
   Optionally, a VGA-style attributes byte.

For the highlighting, you could, of course, use something else which might be 
more generic. Brltty could easily translate whatever you use into what it 
needs. It's use of the VGA-style attributes byte is historical, and something 
we've simply never updated to something more modern.

>Yes, GRUB does the same. It updates config only on an attempt to read
>or write character.

That's exactly what brltty does.

>>I'm not sure what you mean by rescans.
>I mean that you said that it handles hotplug. Does it do so by
>re-enumerating all the devices on the bus?

Yes, in a logical sense. The portable usbFindChannel() ends up calling the 
platform-specific usbFindDevice(), which usb_grub.c would need to implement. 
Each platform-specific implementation of usbFindDevice() can, of course, cache 
data in any way it wants to. I susepct that, for grub, caching wouldn't be 
necessary. We do it in Linux because it saves a lot of open,read,close of files 
under /proc and /sys. There's also usbForgetDevices(), which should clear the 
cache, that the core calls when it knows it needs a fresh look.

>I'm actually now attempting to compile brltty.c + dependencies
>without keyboard stub. Will see how much I have to modify.

Cool! Please let me know if I can make code changes which would resolve any 
problems you encounter.

>Currently the most important additional change was to disable signals.

Yes, I can see the need for that. Maybe we should have a #define for 
HAVE_SIGNALS.

>I will start with 160x24 or 80x24 then. While \infty x 24 is possible
>it needs some code adjustments (disable wrapping, modify rendering,
>...).

I'm fairly sure brltty is safe up to 255x255.

>How do you handle combining sequences (base codepoint + n combining
>codepoints, n>=0)? 

We don't handle them as well as we should at the moment, but that's our 
problem. We should fully support them, and we eventually will. The easiest 
thing to do would probably be to always put the base character first, which 
would then leave us free to fully incorporate the combining characters when 
we're ready to do so.

>In GRUB a cell on the screen is occupied by a combining sequence with 
>attributes (we do allow variations though, e.g. VGA strips all combining 
>combining codepoints and restricts base one to a small subset).

There'd be no need to restrict the base characters.

>Colors are fully used by menu and editor modes if instructed to do so
>(menu_color, menu_color_highlight) but falls back to
>highlighted/non-highlighted version if color isn't available (e.g. on
>some serial terminals).

Full colour would be difficult for brltty. The genereal structure could, of 
course, still include it. If it's really only highlight versus normal, then a 
simple flag would do. Maybe a "type of highlighting" field. In any event, the 
general rendered structure could include both simple and complex colour 
information so that an application can choose which one it wisehs to use.

While full colour doesn't make much sense in braille, brltty does have a 
"describe character" function. It'd be cool if this functin could still give 
the full colour information.

>Default upstream uses standard black/white for best contrast, Debian
>though uses less accessible colors by default.
>Color in GRUB brings no additional information compared to
>highlighted/non-highlighted bit and are configurable for purely
>esthetic reasons. Would it make sense to strip this useless and hard
>to represent on braille info and just have highlight bit.

Brltty would likely only ever use the highlight indicator. As mentioned above, 
though, you may still wish to include the full information in the general 
structure for some other, as yet unconsidered, application. What I'm suggesting 
is that the rendered structure be general in nature, rather than 
brltty-specific, so that the work only need be done once.

>How is this bit represented? Vibrating dots? Since the complete
>selected menu entry is highlighted does it create any discomfort by
>reading it?

There are various options. My personal preference is to have the lowest row of 
dots be briefly raised every second or so. Other users may configure it 
differently. One option, of course, is to turn off such notification.

>Currently the problem is that the hint text is on the bottom and with
>no limits it will be shown somewhere in the neighborhood of Andromeda
>galaxy. So we need either to move it somewhere else (right after all
>the entries?) or have limited number of lines. I think 160x24 will be
>a good starting value and can be adjusted later.

:-) I think a blank line followed by the hint text, right after the last line 
of data, would work. I guess it's all in how we define "bottom". Maybe, rather 
than thinking in terms of infinity, we should think of the screen size as being 
set to the number of required lines, which, of course, could change from one 
rendering to the next.

>What if length of braille device isn't a divisor of length of line?
>It seems it would be suboptimal.

Yes, but that happens all the time. Even with an 80-column screen, some braille 
devices have 12, 20, 24, 32, or 70 cells. And, of course, in the graphical 
world, a window can be any width. Brltty has ways to handle it.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | 2011 May 21 is the End of Salvation.
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://Mielke.cc/now.html
http://FamilyRadio.com/                   | http://Mielke.cc/bible/