[BRLTTY] BRLTTY in GRUB

Fri Mar 16 10:16:25 EDT 2012

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.
On 15.03.2012 23:40, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/15 at 22:27 +0100]
>
>> Samuel already said it: I just want to have something that works at
>> least minimally to begin with. To make whole brltty at least compile
>> would mean twice as much work.
> As I've already said, I'd be glad to do the work of making brltty compile if
> you'd be so kind as to tell me how to set up a build environment for Grub. I
> think it's the better approach, and I'm not just compliaining - I'm offering to
> help.
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.
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 ().
>
>> If you think that it's better to have nothing at all rather than something to
>> start with then I'm at wrong address.
> That's your judgement call. If you aren't interested in my thoughts, opinions,
> and suggestions, then perhaps you are.
I'm, lack of sleep :(.
>>>>   common = braille/brltty_wrap/log.c;
>>>> GRUB has no file writing facilities
>>> AGain, replacing a whole file just for that isn't good.
>> Again, putting a dummy there to get something working at all for the
>> first stage is more important than to get tiny bits right and the
>> whole not compiling at all.
> You've been speaking as though this is your permanent goal. If my understanding
> has been incorrect on this point then I stand corrected.
The prefered way to handle logs in GRUB is grub_dprintf. I'll see how I 
can abstract it for brltty.
>>>>   common = braille/brltty_wrap/serial.c;
>>>> Platform-specific.
>>> Parts of it, yes, but not all of it. Again, replacinb the whole file isn't
>>> right.
>> Most of this file should be split the same way as usb.c is.
> I've already said that I know serial.c to be one of the three biggest offenders
> in this area. One of the problems with splitting it up, though, is the fact
> that platform-dependent type definitions are used internally so that things
> like attribute caching can be all done in common, portable code.
GRUB already caches attributes but double caching makes no harm.
>>> No threads. The whole point of async is to let a single thread handle many
>>> events.
>> GRUB works completely differently from POSIX-compliant OSes. GRUB is
>> at most similar to msdos in some aspects (like being single-thread)
>> but offers full features in others (like Unicode).
> As I said, async doesn't rely on threads. It allows the single main program
> thread to handle multiple tasks.
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.
>>>>   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.
>>>> In GRUB renderer is separated from info. It's easier to have good
>>>> Braille display by making braille another renderer rather than rendering
>>>> in standard screen and then having a reader.
>>> Why not render the screen content into a string array,
>> It's possible to make a virtual 80x24 terminal. However special
>> structure of GRUB and its small code size has already allowed us to
>> find better solutions to problems than what is applicable to a big OS
>> where you can't change all components to improve input to your
>> command. In this case I thought that having the complete model would
>> allow better braille rendering. The solution of rendering into 80x24
>> and then attempting to parse seems to me as a kludge.
> A braille user needs to be able to see the whole screen, just like you like to
> see the whole screen. Do you really think it's somehow better to have two
> completely different renders, both of which, independently, know what should be
> on the whole screen? Isn't it better for the screen to be rendered logically
> once, and then to have various presenation layers to turn that logical
> representation into physical ones?
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.
>
> It's not good, by the way, to go down a path which would allow the braille
> screen to have different content than what's shown on the monitor. If a braille
> user and a sighted person are working together, it's critical that they're both
> seeing exactly the same data in exactly the same layout. The importance of this
> cannot be understated.
>
> Given the above, can you now see the sense in first rendering the screen into a
> logical representation? It doesn't need to be something hard-coded like 80x24.
As referenced before the may be no textual screen at all. Or the may be 
several. 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.
>>> Also, given the lack of core support, no user with a braille display smaller
>>> than 40 cells will be able to use it.
>> 40 is a parameter
> 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.


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