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
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
