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: [EMAIL PROTECTED] or [EMAIL PROTECTED] Grtnx, Osvaldo La Rosa ---In answer to your session:--- On 2000-08-19 [EMAIL PROTECTED] said: >cc: VZW AUDIO/BRAILLE <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >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
