[BRLTTY] BRLTTY in GRUB

Fri Mar 16 12:56:19 EDT 2012

On 16.03.2012 17:09, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/16 at 15:16 +0100]
>
>> First of all I want to apologise for my tone. I was under severe lack
>> of sleep these days and will be happy if we could forget my
>> out-of-place remarks and get on with real stuff.
> I never heard them. :-) The past is the past.
>
> Likewise, if I said anything rude in haste, I'm sorry for having done so. I'm
> only qualifying my statement with "if" because I don't feel like going back and
> rereading evrything. I know it's possible that I did speak in an improper way.
>
> I do have a very direct way of speaking, though. That's just part of the way I
> am. Sometimes, those who don't know me very well accideentally take my remarks
> personally when they were really only ever meant with respect to the issue
> itself.
Being direct is good, it's a way to cut the unnecessary text.
>> bzr branch http://bzr.savannah.gnu.org/r/grub/branches/brltty/
>> Rest of instructions are in INSTALL. I can upload a tarball if you prefer.
> I'll have a look. Hopefully it'll tell me how to run the right compiler, point
> to the right headers, etc.
The only problem is relatively important dependencies (On Debian sudo 
aptitude build-dep grub-pc). Other than that
./autogen.sh
./configure --disable-werror
make -j3 > /dev/null

>
>> Another thing I forgot to mention is that GRUB's exit (), fatal ()
>> and so on calls can be used only in critical situation like an
>> important memory corruption. I have #if 0-ed out few function which
>> use exit ().
> Yes, that'd make sense. If it's all running in one main thread then I guess an
> exit() within a component would kill all of Grub.
>
> In fact, brltty itself shouldn't have to many places where it exists. Any which
> remain may well need to be reviewed.
>
>> The prefered way to handle logs in GRUB is grub_dprintf. I'll see how
>> I can abstract it for brltty.
> That should be possible. Brltty already has a different way of logging for
> Windows. I'm not a Windows person, but I believe it logs to the Windows event
> log.
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?
>
>> GRUB already caches attributes but double caching makes no harm.
> Brltty's main goal is to only update the attributes once even if the user makes
> several individual changes.
>
Yes, GRUB does the same. It updates config only on an attempt to read or 
write character.
>> I'm currently not able to make it work at all. I got this impression
> >from reading the code. But if async code does a rescan then we'll
>> need a cache layer to avoid real rescans.
> 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?
> I never have problems with intirim states. I just try to prevent what 
> I believe to be wrong goals. 
I'm actually now attempting to compile brltty.c + dependencies without 
keyboard stub. Will see how much I have to modify.
Currently the most important additional change was to disable signals.
>> GRUB can work in one of three modes:
>> - menu mode. In this case a model is the list of entries and
>> currently chosen entry
>> - editor mode. In this case a model is the list of lines and current
>> position.
>> - cmdline editing mode. In this case the model is current line and position.
>> - text mode. In this case a model is the incoming flow of strings
>> (not characters as characters aren't enough for bidi), some of them
>> highlighted. Some of them contain line breaks.
>> In any of the modes then one instance of renderer is attached per
>> output terminal which takes its characteristics into account. In case
>> of menu we have 2 different renderers: textual and graphical.
>> Terminal code also keeping previous text output while in text or
>> cmdline mode.
>> We already use this to represent the same info on different
>> terminals: E.g.
>> http://robertmh.wordpress.com/2009/12/25/multiple-grub-terminals/
>> So the may not even be a textual representation like what you refer
>> to (e.g. in case of gfxmenu). So we probably need some wrap renderer
>> between GRUB and BRLTTY. One possibility is to render to 80x24 using
>> textual renderer but skipping some decorations like borders.
> Yes, that'd probably work. Brltty can handle much longer lines than 80, though,
> even if the user's actual device has far fewer cells. It may even be that you
> can simlly let each line be as long as it needs to be. This would give you a
> very generic text renderer which could be used by wbo knows what other
> applications in the future.
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 guessing that the actual screen has more on it than what you describe
> above. For example, I know that, somewhere on the screen, it says to press tab
> (or something) to open a menu entry for editing. These helpful hints, plus
> whatever else is on the screen, all need to be on the screen that brltty sees.
They are static and are part of renderer template (hardcoded for text 
renderer, part of theme.txt for graphical).
> Grub should render this version of the screen into some shared place that an
> application can find. Then, brltty's Grub screen driver can access this
> location and return data to the core as needed.
>
> I believe I mentioned earlier that brltty's screen drivers like to find Unicode
> characters. I think this is good for Grub. They also support each individual
> character being associated with a VGA-style foreground/background colours byte.
How do you handle combining sequences (base codepoint + n combining 
codepoints, n>=0)? 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).
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).
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.
How is this bit represented? Vibrating dots? Since the complete selected 
menu entry is highlighted does it create any discomfort by reading it?
>
>> We can choose any size which results in best brltty results, even infty x
>> infty, or give brltty raw model but it would break the structure to use a
>> parameter from another terminal which may or may not exist.
> I think we should probably start with no limits. We can alays add in limits if
> we encounter them, though I'd probably prefer to find ways to remove those
> limits within brltty's core, actually.
>
> Brltty will need to know how many lines are on the screen, and how long each
> individual line is.
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 still maintain that Grub shouldn't need to care about the properties of the
>>> braille device. Rendering good braille isn't as simple as putting text on the
>>> display.
>> It may make sense to tweak text renderer to a given brltty device.
> I don't think that'll be necessary. It hasn't been necessary to date in any
> other environment. Brltty's core offers the user what he needs to move around
> the screen quite freely and quickly.
>
What if length of braille device isn't a divisor of length of line? It 
seems it would be suboptimal.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko