[BRLTTY] qemu/vmware/... virtual braille devices?

[Nicolas Pitre]

On Thu, 10 Jan 2008, Dave Mielke wrote:

> [quoted lines by Samuel Thibault on 2008/01/10 at 14:15 +0000]
> 
> >What made me think that is the definitions array in the openUsbPort
> >function.  The problem is that the guest screen reader is not
> >necessarily brltty, it's possible that JAWS or WindowEyes requires the
> >size and the USB ID to match.  That said, the given possibilities (24,
> >32, 40, 64, and 80) are numerous enough so that it's not so big a
> >problem.  We could hence have a "size-free" mode which uses the
> >arbitrary display size, and a legacy mode which repects USB IDs and thus
> >restricts the available sizes.
> 
> We could always return the USB ID for the largest size <= the actual display 
> size. The length of the bytes written to the display could then be 
> appropriately padded so that as much of the display as possible is used.
> 
> >Just the same: remember that the guest is not necessarily brltty, but
> >could be any screen reader, so the key meanings must be generic enough.
> >In the case of brltty, to get full support we could just use the brlapi
> >protocol instead.
> 
> The problem with keys is that each type of display tends to have a 
> fundamentally different layout so it may not be possible to map one display's 
> keys nicely to those of another.

I've been pondering about this for a while, and came to the conclusion 
that no braille device could properly masquerade all the others in a 
generic way.

So I think you should either create a truly generic virtual braille 
display and have Windows applications support it (difficult), or create 
a pass-through mechanism to let the virtual machine access the real 
display when it is on the foreground, and simulate an USB disconnect 
when BRLTTY needs to get control of the display back.


Nicolas