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