[BRLTTY] BRLTTY in GRUB

Fri Mar 16 14:40:09 EDT 2012

On 16.03.2012 18:57, Dave Mielke wrote:
>> 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.
Yes we need to limit it to few KiB in some way.
> 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.
Would it be unicode values of base codepoint+combining codepoints?
 > Optionally, a VGA-style attributes byte.
And  highlight bit. Color by itself isn't trivial to infer highlight 
info from.
Other than these 2 remarks it sounds good to me.

 > 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.
Most console applications are restricted to 8 vt100 colors.
>>> 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 don't currently cache some attributes like serial number.
>> 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.
Could you perhaps enable -Wformat-security on your codebase? Since you 
have a lot of constructions like
printf (gettext ("Hello"));
This creates a problem if translation contains %. I'm not sure if 
xgettext recognizes such a usage as c-format correctly. If it doesn't 
translator wouldn't even know that adding % is wrong and he has to use 
%% instead.
>> 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.
GRUB's code currently is ok to at least few thousand by few thousand.
>> 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.
Ok.
What's with bidi? Does our code has to supply unicode lines in logical 
or visual order (preferred as the code currently handles reordering 
together with some other tasks)
Is Hebrew/Arabic/Thaana/... braille read from left to right or right to 
left?
>> 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.
How does braille handles a mixture of Latin and National 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.
If we need to adjust it for another use we can add fields later.
>
> 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.
Then I'll include both.
>> 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.
This would make impossible to know which entry is selected. That's 
something that probably has to be fixed in GRUB.
> :-) 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.
Sounds good.
>> 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.
If we go with "infinity" solution it wouldn't be a problem.


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