[BRLTTY] chicken and egg situation

[Dave Mielke]

[quoted lines by David Pankhurst on 2011/08/10 at 02:24 -0700]

>I have a question about developing Braille readers - how does
>one start?  It seems that without the device, there can be no driver,
>but without the driver, how can one design/test/configure the device?
>For example, if I was to develop a new Braille device, what could I
>do personally to set up a test bed to connect to a reader (for
>example, NVDA under Windows)? And how could I take it far enough to
>be real driver for brltty? One thought would be the creation of a
>generic 'superdriver' with all the best/ultimate features of the
>different readers, and which a new device may pick settings from like
>a menu - is that possible? Any help would be appreciated.

It wouldn't require a generic super driver of any sort. What it would require 
is the development of a protocol (and driver) which is as general as the brltty 
core is. That means four things:

First: A general way to send braille cells to the device for presentation. This 
packet should use the ISO-11548-1 standard for mapping the bits of a byte to 
the dots in a cell (bit 0 for dot 1, bit 1 for dot 2, ... bit 7 for dot 8). It 
should also have a count field so that the packet can contain an arbitrary 
number of cells. If the device is capable of remembering what's on the display 
then another field contianing the offset at which the new cells start would be 
good so that small portions of the display, rather than always all of it at 
once, can be updated.

Second: A general way to send key events to the host. Brltty uses a general way 
of representing key events which requires two bytes and a boolean. The first 
byte is the key set number, the second byte is the number of the key within 
that set, and the boolean indicates whether the key has been pressed or 
released. The actual mapping of keys and key combinations to brltty functions 
is done via a text-based table which brltty loads when the driver is started. 
Key sets are defined as needed - there's nothing unique about any of them. Each 
should represent a related group of keys on the device, and their use is 
defined within the key table.

Third: A general way to ask the device what it is. For a generic device, a 
character string might be best so that the device can name the key table that 
needs to be loaded. The probe sequence (what the host initially sends) would 
hopefully be something unique, so that it doesn't conflict with existing 
schemes, as that'd allow the device to be autodetected.

Fourth: Additional packets which permit querying device properties (dell count, 
serial number, firmware version, etc), controlling the device (setting cell 
firmness, setting cell touch sensitivity, etc), etc could be added.

-- 
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   | 2011 Oct 21 is the End of the World.
http://FamilyRadio.com/                   | http://Mielke.cc/bible/