Re: Braille devices (the problem was DOSemu)
Hi all,
In my specific case where I wasn't able to run a Alva ABT280, this was the
hardware problem + this should be the solution:
- the problem: the DB9 connector on the rear panel didn't have the function
of serial connection for the device; so the only way for the ABT280 was
the parallel port. (No spex from factory, as Nicolas Pitre explained).
But Dosgate, see http://www.cs.unibo.it/~zinie/dosgate uses DOSemu, and
DOSEMU IS NOT IMPLEMENTED FOR PARALLEL PORT.
- The solution was/is: the implementation of DOSemu so that I was able to
run C:\ABT280.EXE 1 (corresponds to lpt1) and that's all,
then returning to Linux.
Project:
it is not promised to me, but I will ask again for confirmation: a student
of the KU-Leuven should start the DOSemu implementation, but not before
November......... During this time, I must try a non-braille solution:
Screader + Festival fails.
I do also had contact with the developer of Speakup
(http://www.linux-speakup.org) for developing his screen reader for usage
in combi with software-speech (Mbrola, TuxTalk, not Festival: too
big/slow/75 % of processor usage for him).
--I'm not on this list, for reactions send it in CC to my address:
olr@xs4all.be or mail@audiobraille.org
Grtnx, Osvaldo La Rosa
---In answer to your session:---
On 2000-08-19 nico@cam.org said:
>cc: VZW AUDIO/BRAILLE <olr@xs4all.be>, debian-devel@lists.debian.
>org,
>> [CCed to linux-kernel, as IMO the best idea would be to implement
>>this at kernel level]
>> On Wed, 16 Aug 2000, VZW AUDIO/BRAILLE wrote:
>> > Hi, I have on one pc the very great chance to use Debian 2.1
>>with a > hardware braille-display. But actually on another pc I'm
>>suffering from > the refusal of my old braille display (not
>>brltty supported) to let > me work under Deb. So on pc1 I've a
>>great pleasure to work, on another > nothing more than
>frustration! >
>> [...]
>> I've seen the request for braille device support during
>>installation here on debian-devel for many times, and IMO the
>>best approach would be to support these devices at kernel level.
>>The reason for this is that a daemon approach would compromise
>>system security, as some (luckily not too many) braille devices
>>have special interface cards which require hardware access. Also,
>>a daemon has to be started in order to be useful, so that you
>cannot see anything if the boot fails. >
>> Comments?
>First, let me say that I'm actually the maintainer of BRLTTY
>(http://www.cam.org/~nico/brltty) and used it most everyday on
>Linux for nearly six years now. I would like to take this
>opportunity to answer some questions and kill some common myths
>that I keep encountering over and over. All this rambling also
>applies to other packages similar to BRLTTY...
>Braille Display Support
>-----------------------
>BRLTTY is quite modular and actually support over 10 different
>brands of braille display families. Adding another is just a
>matter of having the protocol specification from the manufacturer
>(you know the classic problem?) and someone to implement it. So
>the user space vs kernel space argument is a non-issue for "my
>display isn't supported" statements. The scarce braille displays
>requireing a special interface card are mostly using firmware on
>the card that emulates a VGA text display, or that retrieve data
>directly from the video memory of your VGA card, in order to send
>it directly to the braille display thus not relying on software
>support at all. In the case where kernel support is absolutely
>required, only the raw low-level communication support must be in
>the kernel, nothing more. System Security
>---------------
>BRLTTY only requires access to /dev/vcsa0, /dev/tty0 and /dev/ttyS0.
>It is intended to be used by the person at the console only and
>that person usually has root access. If you don't want to run
>BRLTTY as root, you just have to adjust permissions on the above
>devices. Braille-Enabled Linux Installation
>----------------------------------
>The fastest and easiest way to have Linux installed for a blind
>person might still consist of a sighted person assisting the
>instalation up to the activation of BRLTTY. Has anyone been able
>to install NT or W2K with braille support during the OS
>installation anyway? But... since Linux is also about freedom...
>Linux installation may even be done with BRLTTY on bootdisks! I've
>installed many version of Red Hat in the past without any sighted
>help and also got reports of success stories for Slackware and
>Debian as well. The current development version of BRLTTY contains
>a mini-howto on installation bootdisks hacking. I encourage every
>interested distributors to have a look at it and maintain a special
>bootdisk for braille-enabled Linux installation. I did it for me,
>the recipee is available, but don't ask me to do it for you please.
>Here again, the kernel solution isn't much of an advantage because
>you'll typically have BRLTTY reside on an initial ramdisk (initrd)
>which contents is executed before any kind of installation
>procedure. When the loading of the initrd fails, it'll most
>probably be the case for the kernel as well, and the blind person
>will remain clueless either ways. The "in the kernel approach"
>doesn't bring an advantage worth its cost. Since BRLTTY uses
>/dev/vcsa0, all kernel messages are available from the console's
>scrollback function. Even the BIOS boot messages can be consulted
>that way! Conclusion ----------
>BRLTTY is a daemon simply because its job can be done outside the
>kernel. It has been like that since 1995 and you know what? the
>first old version from 1995 still can run unmodified on a 2.4.x
>kernel. So please always look at what can be done in user space
>before advocating kernel solutions. Putting this into the kernel
>would simply be a maintenance overhead. My pay job consists of
>kernel hacking and I also maintain kernel support for the StrongARM
>SA1100 in my free time. Therefore I'm quite familiar with it and
>don't think adaptive applications belongs there. Some will argue
>that Speakup is in kernel space but speech is a different matter
>than braille, and I'm still not convinced anyway. As a sidenote,
>people used to their good old DOS TSR for their braille/speech
>hardware could have a look at DOSgate (http://www.cs.unibo.
>it/~zinie/dosgate/). It lets you access the Linux console
>transparently through a dosemu session using your DOS adaptation
>tools. This might be an alternative to the lack of native Linux
>support for some hardware... or lack of good enough Linux screen
>reader package for one's taste. Nicolas
--tcpsmtp080200200010026006
Reply to: