[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. >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: d...@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@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
