Re: Braille devices
/* I'm not on l-k at the moment, please Cc replies */ On Sat, Aug 19, 2000 at 09:48:03PM +0200, Simon Richter wrote: 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? Agreed. I have been pleading with anyone I came across willing to listen for quite some time now to consider the idea of alternate console device in the kernel for quite some time. The same concept that applies to multihead also applies here except that the alt console would allow for some secondary I/O device to be used in addition to the primary one. This would allow for custom alternate output devices such as braile terminals or possibly speech synthesis drivers to be written as kernel drivers and essentially always working. It'd also allow such things as use of an input device similar to the DARCI hardware (but much less expensive) right in the kernel and as far as the console driver of the kernel is concerned, anything sent and processed by the driver came directly from the local keyboard. Much more flexible than the serial console driver is today. For those who don't know, devices like the DARCI boxes are insanely expensive - they cost more than twice the average machine of a person reading this message. What it does is simulate a keyboard. It's extremely flexible in its hardware implementation and extremely complex in its configuration. It can use all sorts of inputs from custom matrix keyboards to a few switches to a surplus morse code key - use your imagination a bit. It outputs a standard keyboard signal. In your choice of PC, Mac, and I think also Sun formats. It's purpose is adaptive input for people who cannot use a traditional keyboard. They may also have alternative ways to simulate a mouse in newer models. Most of these special purpose devices can be connected to parallel or serial ports with very little electronics no more complex than wiring up a playstation controller for your favorite game emulator. The possibilities for output have I think already begun to register. Besides the obvious things like braille displays and speech, there are a million different embedded applications for this. Wearables anyone? This is really the kind of thing that would not be very hard to do (I hope) but it seems like it is also the kind of thing that must be agreed upon because it will certainly affect a lot of things even if the effect on them is not major. Nonetheless, I feel it is something that should be done because it is important to make Linux as accessable as possible. It should also be done because it'd be cool and open the door for a lot of cool stuff. (Ye personal-stake-in-this disclaimer: I am myself legally blind, but do not read Braille or use a speech synthesizer. I have enough vision that the fact that my wterm has a font half an inch high on a 21 monitor I'm less than 10 away from is fairly comfortable reading. My vision is 20/310 and cannot be reasonably corrected at this time. So yes I want to see this done for other people with disabilities - but I'd never use such a kernel device for that reason. Not necessary. I might use such a thing to write a kernel driver for handling I/O for the wearable I've been planning to build at some point, however.) -- Joseph Carter [EMAIL PROTECTED] GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 Thoth_ Yeah, well that's why it's numbered 2.3.1... it's for those of us who miss NT-like uptimes
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: [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
Re: Braille devices (the problem was DOSemu)
On Sun, 20 Aug 2000, VZW AUDIO/BRAILLE wrote: 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. Please read carefully the documentation for dosemu! You can configure it so dosemu (and the Linux kernel) lets DOS applications access the parallel port hardware directly. I used an Alva ABT340 over the parallel port that way in the past. Nicolas
Re: Braille devices
From: Simon Richter [EMAIL PROTECTED] [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
