Debian Talking Install?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30 Jan 2003, Kirk Reiser wrote:

> Nicholus, Could you please repost your last message?  I read through
> it quickly late last night and thought I marked it unread so I might
> respond this morning but at las, it appears to have bit the bit
> bucket.

Here it is:

Date: Wed, 29 Jan 2003 22:13:57 -0500 (EST)
From: Nicolas Pitre <nico@cam.org>
To: Kirk Reiser <kirk@braille.uwo.ca>
Cc: blinux-list@redhat.com
Subject: Re: Debian Talking Install?

On 29 Jan 2003, Kirk Reiser wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > It's way more valuable for a blind person to have a much greater choice of
> > speech synths, including much cheaper ones, than having speech output from
> > the very milisecond the kernel starts using printk().  IMHO persisting with
> > a kernel solution is what actually makes second class citizens in the end.
> 
> Well, there are very few hardware synths speakup does not support but
> it should support all of them in an ideal world.  As far as a software
> synth and sound card being the ultimate choice because of it's
> relative inexpense to a hardware synth, you have to also consider that
> a machine powerful enough to make a software synth truly as responsive
> as a hardware synth costs a lot more than just dropping a sound card
> in a 486.  So there are trade offs for each solution.

Of course.  But if you look for used PC shops you should be able to find a 
great choice of extra cheap Pentiums at a price often lower than a mid range 
sound card.  Yet those old Pentiums are powerful enough to drive a software 
synth.

Yet blind students are often equiped with (rather should I say loaded with) 
heavy stuff to carry around.  If they own a laptop it's way more enjoyable 
not to drag all sort of external peripherals with it.  That's where the 
software synth comes really handy.

And just to have a view into the future: most PCs won't have anymore serial 
ports nor ISA slots soon enough to hook all those hardware synths.  The 
world is going towards USB peripherals only.  So the future for all those 
good old hardware speech boxes is a simple dead end.

That's why Speakup must focus on supporting software speech technologies or 
its users will be orphaned sooner or later.

> Actually, I'd like to have a nice long discussion with you in person

We're not too far apart you know.

> I have a hard time finding the time to sit down and write out all my
> beliefs and perspectives in an on going discussion.  I don't find I write
> as eloquently as I'd like. 'grin'

Well, not being a native English speaker it's easier for me to write.  I 
don't find my spoken english as eloquent as I'd wish.

> We may have to also agree to disagree on some items as well.  One of
> your points is that the kernel is no place for access technology.  My
> view is why not?  If you postulate that kernel console code should be
> in the kernel at all then where is a blink any different than a
> sighty?  

Because we talk about Linux which shares the Unix philosophy.  We don't have 
to cram the kernel because it can't be done otherwise... like they do with 
that other OS.

The idea is simple: if it can be done in user space, do so.  It will always 
be better for your developer's mental health.

Kernel space code must be considered only if it can't be done in user space.  
Take x window for example: entirely user space.  Web servers: user space.  
Those are only two examples of things that are in the kernel on Windows.  
On Linux we managed to make good software abstractions so those things can
live in user space and still blow Windows away performance wise.

> If you are taking the code expense to drive video cards of
> many flavours then why not voice synthesizers?

Simply because it can't be done from user space.

> Console code has to support vt100 or linux terminal sequences then why not
> synth control codes?

Because historically Unix was used with terminals that were separate devices
from the actual main computer.  Applications have been written with that
model for over 30 years now.  When the computer <-> terminal model was
transposed to a PC they made the actual console just like if it was a VT320
on a serial port.  So the Linux console supports VT100 sequences just to
comply with the Unix tty model and be transparent to applications that just
work the same way regardless if they're interacting with the user over a
network, a terminal on a serial line or on the actual same machine.

I don't see speech synths fitting into that model at all.  Trying to apply 
the tty model to them is a bit far fetched -- it was never meant for that.

> If you are going to have scroll lock, numlock, print screen
> and many other special keyboard functions then why not screen review
> keyboard functions?

Oh that's different.  I never said that there shouldn't be any screen review
keyboard functions.  The keyboard on your PC may as well serve two purposes:  
be part of the terminal emulation (even if most people aren't aware of this
layering happening behind the scene), and serve as a special event device
for a screen review application, or any other applications for that matter.

With the new input API in Linux you can do just that: open the keyboard
device and have all the raw key events sent your way for your enjoyment.

>  Why should a blind person not deserve the same
> access to the kernel that any sighted person has?  

They certainly do deserve that access -- don't take me wrong.  It's the
_implementation_ for that access that needs discussing.

> Access technology doesn't make sense or belong in the kernel is not a
> reason.  I want blinks to have speech from power up to power down.  I
> don't know that I'll ever accomplish that goal, but if the sighted
> community deserves it then so do other handicapped communities.  There is
> nothing intrinsicly holy about the kernel and console code that we should
> keep our hands off.

But if you don't have to touch it why bother?  My point is that access from
startup to shutdown is virtually possible from user space as well.  I say
"virtualy" because even sighted people don't have access to their kernel as
you put it from the very begining.  There is always a window where even
sighted people won't have a clue on their screen if the kernel crashes
simply because conventional output devices are not initialized/accessible
from the very beginning either.  It just happens that the code that goes all
way through that window has been debugged long time ago and is pretty much
unlikely to crash these days.

That's the same for access technologies -- you can easily manage to have the 
kernel boot all way through to user space without any failure.  Once there, 
you simply start your accessibility application as the very first user 
process, grab a log of what the kernel printed out before that point from 
/proc/kmsg, monitor screen activity from /dev/vcsa0, sniff keyboard events 
from /dev/input/eventX, access the spech synth through /dev/ttyS0 if serial 
port, /dev/usb* if USB, /dev/whatever if that's an ISA card, or launch that 
software library that will eventually use /dev/dsp to use the soundcard.

All this can be made into an initial ramdisk.  That's what Red Hat uses to
load appropriate required drivers, from user space, to be able to drive that
special hardware where your actual root filesystem lives.  Note that all
this is happening _before_ the real root is mounter and where the real life
boot failures are.

Loading of the ramdisk can fail?  Sure!  But that's the same of the kernel 
itself.  And since both the kernel and the ramdisk are put into memory by 
the bootloader, you can be sure that the ramdisk will be available if the 
kernel is.  So whether the speech solution is in the kernel or in user space 
just doesn't make any difference here.  Oh and the initramfs support that is 
being merged into 2.5 at the moment will be a tar-like archive of a 
filesystem that will be glued to the kernel binary at compile time.  This 
will replace the initial ramdisk and incidentally remove a _lot_ of code 
from the kernel, like mounting the actual root device, obtaining a dynamic 
IP adress from a DHCP server, etc.  Plenty of things that kernel developers 
just don't want to see in the kernel anymore since user space can handle 
those tasks much better.

> Now saying that, having to stay on top of all the kernel changes
> certainly gets prosaic.  To that end writing it once and having it
> stay compatible like brltty definitely has its advantages.  Maybe a
> better approach would be to have a separate screen review console
> which wouldn't need to change with each small modification to the
> standard console code.

That just won't scale.  There are simply too many non-blind kernel 
developers out there that just don't care to preserve stable kernel 
interfaces for accessibility usage.  They even don't care about breaking 
binary modules provided by big companies that have much more influence than 
the few blind developers that we are (I assume you are blind too?).

The only thing that is assured to remain stable is the user space interface
into the kernel i.e. system calls.  So by making Speakup live in user space
you can focus on enhancing Speakup itself while others are enhancing the
kernel internals.

> I need to rewrite speakups interface to the kernel for the 2.5.x and
> above kernels so I am trying to determine the best way to approach the
> rewrite.  

Believe me it's the user space way.  If you still have objections please
tell me so I can understand them and propose a solution.  This doesn't mean
that the kernel will never need modifications to accommodate user space
accessibility needs, but those mods must be kept to a minimum and as generic
as possible.  Of course some synths will require a kernel driver, like the
Dectalk PC, if the hardware must be accessed directly.  But the driver must
only provide a read/write abstraction to the hardware, no more.  User space 
should take care of knowing about mastering the Dectalk escape sequence 
simply because it doesn't need to be in the kernel.

> I liked Alan's suggestion of writing a select patch for vsca0 but I am not
> totally comfortable with the new console code yet so it is probably to
> early to tell for sure.

The select() support for /dev/vcsa0 as I discussed with Alan is exactly
that: a really simple and small kernel modification to help user space
behave better.  It should be around 10 lines of kernel code.

> I am certainly happy to
> hear reasoned suggestions on various options.

Looking forward to your reply.


Nicolas






[Index of Archives]     [Linux Speakup]     [Fedora]     [Linux Kernel]     [Yosemite News]     [Big List of Linux Books]