[BRLTTY] BRLTTY in GRUB

Fri Mar 16 14:49:40 EDT 2012

On Fri, 16 Mar 2012, Dave Mielke wrote:

> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/16 at 17:56 +0100]
> 
> >The only problem is relatively important dependencies (On Debian sudo
> >aptitude build-dep grub-pc). 
> 
> My systems aren't Debian. I guess this'll be a problem.

Fedora builds and ships grub too, so all the prerequisites are 
available.  The INSTALL file says:

But to get you started quickly, you may only have to do:

	yum-builddep grub

Nicolas

For instance, I had to install the following packages (using yum install 
as usual):

	autogen

> 
> >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.
> 
> 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.
>    Optionally, a VGA-style attributes byte.
> 
> 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.
> 
> >Yes, GRUB does the same. It updates config only on an attempt to read
> >or write character.
> 
> That's exactly what brltty does.
> 
> >>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 do it in Linux because it saves a lot of open,read,close of files 
> under /proc and /sys. There's also usbForgetDevices(), which should clear the 
> cache, that the core calls when it knows it needs a fresh look.
> 
> >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.
> 
> >Currently the most important additional change was to disable signals.
> 
> Yes, I can see the need for that. Maybe we should have a #define for 
> HAVE_SIGNALS.
> 
> >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.
> 
> >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.
> 
> >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.
> 
> >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.
> 
> 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.
> 
> >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.
> 
> Brltty would likely only ever use the highlight indicator. As mentioned above, 
> though, you may still wish to include the full information in the general 
> structure for some other, as yet unconsidered, application. What I'm suggesting 
> is that the rendered structure be general in nature, rather than 
> brltty-specific, so that the work only need be done once.
> 
> >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.
> 
> >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 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.
> 
> >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.
> 
> -- 
> 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/
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty