[BRLTTY] BRLTTY in GRUB

[Dave Mielke]

[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.

>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.

>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 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.

>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.

The most important part of async which will need to work is the alarms part. 
Right now, it uses either poll() or select() because that lets it also wait for 
I/O events. I can think of a way to make just the alarms part work, though. 
This should, of course, be driven by HAVE_SELECT and HAVE_POLL both being 
undefined. That's the best way to keep magic out of the code. It can simply 
know that it should still support alarms even if there's no way to wait for 
I/O, and, in that case, it should return an error to places in the code which 
try to use it for waiting on I/O.

>>>>>  common = braille/brltty_wrap/ktb.c;
>>>>>Currently dummy for keys.
>>>>Totally bad idea.
>>>It makes the whole compile.
>>It also renders the controls on the braille devices entirely useless.
>For the first prototype I want to make keys useless. Just so I can
>check only half of the code.

I never have problems with intirim states. I just try to prevent what I believe 
to be wrong goals.

>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'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.

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. 
There's a way, therefore, to even indicate highlighting which brltty can 
handle. If the colours byte isn't available then the screen drivers assume 0X07 
(the normal white on black).

>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.

>>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.

-- 
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/