kernel pre-emption and software speech

kernel pre-emption and software speech

[Joshua Lambert]

Hi all,
I have noticed that kernel pre-emption wreaks havoc with software speech, 
causing symptoms like spelling out commands or even the output of commands 
like ls letter by letter along with slow responsiveness.  I am trying to 
find a way to turn off kernel pre-emption on the fly if that is even 
possible so that distributers of livecd linux flavors can still keep their 
fast x performance and we can have our accessibility.  Is it possible to 
do this, or would there need to be a separate, non-pre-emptable kernel in 
a distro?
Cheers,
Josh

Re: kernel pre-emption and software speech

[Samuel Thibault]

Hi,

Joshua Lambert, le Wed 04 Oct 2006 02:33:27 -0400, a écrit :
> I have noticed that kernel pre-emption wreaks havoc with software speech, 
> causing symptoms like spelling out commands or even the output of commands 
> like ls letter by letter along with slow responsiveness.  I am trying to 
> find a way to turn off kernel pre-emption on the fly if that is even 
> possible so that distributers of livecd linux flavors can still keep their 
> fast x performance and we can have our accessibility.  Is it possible to 
> do this, or would there need to be a separate, non-pre-emptable kernel in 
> a distro?

There is currently no way to disable preemption on the fly.  And I doubt
Linux people will add the possibility.

That said, this shouldn't be hard to have speakup work nicely
on a preemptible kernel. I should just be a matter of adding
preempt_disable() / preempt_enable() calls around speakup code...

Samuel

Re: kernel pre-emption and software speech

[Henrik Nilsen Omma]

Samuel Thibault wrote:
> That said, this shouldn't be hard to have speakup work nicely
> on a preemptible kernel. I should just be a matter of adding
> preempt_disable() / preempt_enable() calls around speakup code...
>   

I don't know much about how this particular code works, but I'd like to 
chime in and agree with Samuel that it's always better to try to merge 
in with what is commonly used instead of creating a separate custom version.

On that point, could someone explain to me the reasons why speakup is 
not in the default kernel? Is it very intrusive, or known to have 
serious stability bugs? Is it not maintained actively enough to be 
considered?

Henrik

Re: kernel pre-emption and software speech

[Justin Ekis]

On Wed, Oct 04, 2006 at 12:24:38PM +0200, Henrik Nilsen Omma wrote:
> On that point, could someone explain to me the reasons why speakup is 
> not in the default kernel? Is it very intrusive, or known to have 
> serious stability bugs? Is it not maintained actively enough to be 
> considered?

It was actually included in the mm development kernel for several months 
last year. I guess some things just didn't work out and it was dropped. 

For one thing, the speakup snapshot they took was several months out of 
date to start with, and never updated the entire time it was in there. I 
guess someone was working on it because the size of the speakup patch 
file kept changing, but cvsversion.h never changed so they didn't update 
from cvs. I get the impression from reading mailing lists that kernel 
developers don't care for cvs.

I've done some digging and found this message from the kernel list. two 
developers list there problems with speakup. I got curious when I first 
saw this and brought it to Kirk's attention off list that speakup was in 
mm. It seemed like it came as a surprise. How do they expect to get 
things fixed if they don't contact the maintainer? The patch adds his 
address in the Maintainers file. On top of that to work from an ancient 
version and never update. Considering all that, and the fact that 
speakup seems to be very stable, I think this message is overly harsh 
but I'm pasting it below anyway. I don't know how much is still relevant 
but maybe someone could take a look and we can try again to get it in. 
It's from Greg K-H, quoting another from Adrian Bunk. It seems to be 
mostly style concerns. It works, I say it should go. Oh well.

Justin


On Sat, Jul 09, 2005 at 04:07:18AM +0200, Adrian Bunk wrote:
> On Thu, Jul 07, 2005 at 04:00:37AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.13-rc1-mm1:
> >...
> > +gregkh-driver-speakup-docs.patch
> > +gregkh-driver-speakup-core.patch
> > 
> >  driver-core updates
> >...
> 
> These aren't driver-core updates, these are new drivers.

Yeah, sorry, I put them in my tree, in order for me to work on them.

> It seems I missed when this was sent for review to linus-kernel.

Heh, it's no where ready for such review, it needs a lot of cleanup.  I
did a lot of it about 12 months ago, but lost it somehow, don't want to
do that again...

I would not recommend reading the code just yet, unless you want to feel
ill...

> Some random nitpicks:
> 
> - SPEAKUP_DEFAULT shouldn't be asked if SPEAKUP=n
> - "make namespacecheck" shows tons of needlessly global code
> - the static variable special_handler is EXPORT_SYMBOL'ed
> - #define MIN should be removed
> - the file cvsversion.h only for keeping a CVS date is a bit
>   overkill
> - spk_con_module.h is not exactly how we use header files in the kernel
> - many of the #ifdef MODULE's point to things that could be done better
>   (especially the #include "mod_code.c"'s)
> - the things in synthlist.h could be done less ugly
> - speakupconf is a userspace script that belongs under Documentation/
> - dtload.c is not kernel code, and should therefore not be in that
>   directory
> - the code should follow Documentation/CodingStyle better
>   (no spaces between the braces and function arguments)
> - building speakup_keyhelp.c modular even in a kernel that doesn't
>   support modules is silly
> - #include <linux/...> belongs before #include <asm/...>

Yes, that's just the start of what needs to be done.  But I like it in
the -mm tree for now to at least give it wider testing to users who rely
on this hardware in order to have access to their machines.  I'll be
slowly working on it over the next month or so to fix these issues and
the placement of where it hooks into the main kernel.  Then I will
submit the driver for review by all of lkml.  I will not send it to
Linus until everyone agrees that it is acceptable.

thanks,

greg k-h

Re: kernel pre-emption and software speech

[Samuel Thibault]

Hi,

Justin Ekis, le Wed 04 Oct 2006 10:39:41 -0400, a écrit :
> Considering all that, and the fact that speakup seems to be very
> stable, I think this message is overly harsh but I'm pasting it below
> anyway.

Mmm, it is not.  Really.  "Working" code doesn't mean "acceptable"
code.  Linux can't accept code which doesn't follow a certain guideline.
Adrian Bunk was kind enough to enumerate the issues to be resolved, and
I do agree on all of them.  This is not being harsh, this is requiring
good code quality.  Else Linux wouldn't be so successful.

Samuel

Re: kernel pre-emption and software speech

[Henrik Nilsen Omma]

Samuel Thibault wrote:
> Hi,
>
> Justin Ekis, le Wed 04 Oct 2006 10:39:41 -0400, a écrit :
>   
>> Considering all that, and the fact that speakup seems to be very
>> stable, I think this message is overly harsh but I'm pasting it below
>> anyway.
>>     
>
> Mmm, it is not.  Really.  "Working" code doesn't mean "acceptable"
> code.  Linux can't accept code which doesn't follow a certain guideline.
> Adrian Bunk was kind enough to enumerate the issues to be resolved, and
> I do agree on all of them.  This is not being harsh, this is requiring
> good code quality.  Else Linux wouldn't be so successful.
>   

Right, the kernel esp. needs to be quite fuzzy about such stuff. It's a 
bit like approaching the High Priests about making changes in their holy 
book. It's the people presenting new code that have to make the case 
that it's good quality and useful. We know that to generally be the case 
but we have to sell it to the core kernel developers. It can be a long 
process, but the feedback is generally fair (if you keep the high 
standards of quality in mind) but it may be a bit direct, so thick skin 
is useful.

I would say it's very worth while though, because it will tighten up the 
code and there will be many more people looking at it making sure it 
works well together with their stuff too. And then of course it gets a 
much wider distribution.

I just spoke with Ben Collins who did the integration with our kernel. 
He says it was pretty straight forward to do, though he didn't look at 
coding style as such. He also says hosting it in git would make his work 
easier, and I suspect that of the core kernel devs too.

Henrik

Re: kernel pre-emption and software speech

[Kirk Reiser]

Quite a few of the changes suggested in Adrian Bunk's suggestion list
were implemented.  Others I didn't understand the criticisms and when
I asked did not get definitive answers.  Some of the suggestions I
didn't understand, I could not figure out how else to implement.  I
have offered to rewrite sections of the code with help from many
people that have offered and have never been able to actually get any
help after the offering.  I have basically given up on the process
because of lack of expertise on my part and lack of assistance on the
part of others.  I originally worked closely with Alan Cox to get it
in and it was mostly there and then Alan and Linus had their falling
out and so that ended up slipping down the tubes.

I would like speakup to be in the actual kernel code because that
would make my job easier maintaining it when someone else changes the
kernel code they would have to be partially aware of the speakup code
needing to be modified also.  As it is speakup works well for the most
part and is relatively easy to patch for novices.  I am not going to
try to get in the kernel code any more unless someone is really
willing to help me with the modifications and answer my silly
questions when I have them, which is often.

I have been moving speakup to git or I should say Daniel Drake has
moved speakup to git but it is not ready for prime-time yet.  I either
have to rewrite the checkout/checkin scripts or move to another system
such as quilt.  My first looks at quilt have not been overwhelmingly
encouraging because of what looks to be lack of documentation or
tutorials or something.  I can't find anything useful reading wise on
the quilt web page.  Maybe I have the wrong page who knows but Daniel
gave it to me so I suspect it is just sparse.

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: kernel pre-emption and software speech

[Steve Holmes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

How does git differ from svn? I heard svn (Subversion) was better than
cvs but what is said of git? Elinks developers use git also.  It would
be nice to standardize on a single revision system but choice is what
it's all about I guess.

On Wed, Oct 04, 2006 at 01:28:45PM -0400, Kirk Reiser wrote:
> Quite a few of the changes suggested in Adrian Bunk's suggestion list
> were implemented.  Others I didn't understand the criticisms and when
> I asked did not get definitive answers.  Some of the suggestions I
> didn't understand, I could not figure out how else to implement.  I
> have offered to rewrite sections of the code with help from many
> people that have offered and have never been able to actually get any
> help after the offering.  I have basically given up on the process
> because of lack of expertise on my part and lack of assistance on the
> part of others.  I originally worked closely with Alan Cox to get it
> in and it was mostly there and then Alan and Linus had their falling
> out and so that ended up slipping down the tubes.
> 
> I would like speakup to be in the actual kernel code because that
> would make my job easier maintaining it when someone else changes the
> kernel code they would have to be partially aware of the speakup code
> needing to be modified also.  As it is speakup works well for the most
> part and is relatively easy to patch for novices.  I am not going to
> try to get in the kernel code any more unless someone is really
> willing to help me with the modifications and answer my silly
> questions when I have them, which is often.
> 
> I have been moving speakup to git or I should say Daniel Drake has
> moved speakup to git but it is not ready for prime-time yet.  I either
> have to rewrite the checkout/checkin scripts or move to another system
> such as quilt.  My first looks at quilt have not been overwhelmingly
> encouraging because of what looks to be lack of documentation or
> tutorials or something.  I can't find anything useful reading wise on
> the quilt web page.  Maybe I have the wrong page who knows but Daniel
> gave it to me so I suspect it is just sparse.
> 
>   Kirk
> 
> -- 
> 
> Kirk Reiser				The Computer Braille Facility
> e-mail: kirk@braille.uwo.ca		University of Western Ontario
> phone: (519) 661-3061
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 
> 

- -- 
HolmesGrown Solutions
The best solutions for the best price!
http://holmesgrown.ld.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFFJA+uWSjv55S0LfERA7RgAKCz9bYGrK3e7WuzUcSm+HXHoZeNHwCg02f9
JHKWi8zbF3fHV+pWV5V7hHg=
=7ERY
-----END PGP SIGNATURE-----

Re: kernel pre-emption and software speech

[Henrik Nilsen Omma]

Steve Holmes wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> How does git differ from svn? I heard svn (Subversion) was better than
> cvs but what is said of git? Elinks developers use git also.  It would
> be nice to standardize on a single revision system but choice is what
> it's all about I guess.

There are many good alternatives, and I personally use bzr, but when you 
try do work closely with another project like speakup does with the 
kernel it helps to be on the same system. Great news that work is being 
done on this!

Kirk: Thanks for the background on that. I'll talk some more with Ben 
our kernel guy and see if we can help with this process.

Henrik

Re: kernel pre-emption and software speech

[Michael Whapples]

In some cases we have to accept less than perfect code. By this I mean that 
it may function correctly with out no problems, but may need tidying up and 
other techniques may be more effecient, but if it is the only software that 
offers those functions then you should accept for what it gives, unless you 
are prepared to sort it out. Just leaving it definitely doesn't resolve the 
issues.

The other thing is that speakup seems to be good enough for some distros to 
include speakup in the default kernel and some others have it as an 
optional kernel but still in the main distro, and are they less stable than 
others? (these include slackware, gentoo, grml). I always found it strange 
that Redhat said how good speakup is, but never had it included on the main 
distro media.

From
Michael Whapples

 Samuel Thibault writes:

> Hi,
> 
> Justin Ekis, le Wed 04 Oct 2006 10:39:41 -0400, a écrit :
>> Considering all that, and the fact that speakup seems to be very
>> stable, I think this message is overly harsh but I'm pasting it below
>> anyway.
> 
> Mmm, it is not.  Really.  "Working" code doesn't mean "acceptable"
> code.  Linux can't accept code which doesn't follow a certain guideline.
> Adrian Bunk was kind enough to enumerate the issues to be resolved, and
> I do agree on all of them.  This is not being harsh, this is requiring
> good code quality.  Else Linux wouldn't be so successful.
> 
> Samuel
> 
> 
> 

Re: kernel pre-emption and software speech

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Oct 04, 2006 at 10:47:11PM +0100, Michael Whapples wrote:
> I always found it strange 
> that Redhat said how good speakup is, but never had it included on the main 
> distro media.

Actually, I seem to recall that speakup was included in the official
release of redhat 8.0.

Greg





- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFJCzh7s9z/XlyUyARAl+1AJ48aUvIA+EuLZ05XJxvSvIMsWGGnQCfVfru
qTZ8zWsDExb/3gmGgIs7kxY=
=86DK
-----END PGP SIGNATURE-----

Re: kernel pre-emption and software speech

[Samuel Thibault]

Hi,

Michael Whapples, le Wed 04 Oct 2006 22:47:11 +0100, a écrit :
> In some cases we have to accept less than perfect code. By this I mean that 
> it may function correctly with out no problems, but may need tidying up and 
> other techniques may be more effecient, but if it is the only software that 
> offers those functions then you should accept for what it gives, unless you 
> are prepared to sort it out. Just leaving it definitely doesn't resolve the 
> issues.

I'm sorry, but that's not how things work with Linux. The Reiser4 code
has been waiting for a long time for instance, and won't be merged
unless the required cleaning up happens.

> The other thing is that speakup seems to be good enough for some distros to 
> include speakup in the default kernel and some others have it as an 
> optional kernel but still in the main distro, and are they less stable than 
> others? (these include slackware, gentoo, grml). I always found it strange 
> that Redhat said how good speakup is, but never had it included on the main 
> distro media.

The problem is not a stability problem, but a code correctness / style
/ ... You may have code that works, but if it is unmaintainable, some
day it won't work any more.

Samuel

Re: kernel pre-emption and software speech

[Samuel Thibault]

Samuel Thibault, le Thu 05 Oct 2006 08:58:36 +0200, a écrit :
> The problem is not a stability problem, but a code correctness / style
> / ... You may have code that works, but if it is unmaintainable, some
> day it won't work any more.

(by "unmaintainable", I mean "unmaintainable by usual kernel hackers".
hence the need for a common style/etc.)

Samuel

Re: kernel pre-emption and software speech

[Michael Whapples]

Samuel Thibault writes:

> Hi,
> 
> Michael Whapples, le Wed 04 Oct 2006 22:47:11 +0100, a écrit :
>> In some cases we have to accept less than perfect code. By this I mean that 
>> it may function correctly with out no problems, but may need tidying up and 
>> other techniques may be more effecient, but if it is the only software that 
>> offers those functions then you should accept for what it gives, unless you 
>> are prepared to sort it out. Just leaving it definitely doesn't resolve the 
>> issues.
> 
> I'm sorry, but that's not how things work with Linux. The Reiser4 code
> has been waiting for a long time for instance, and won't be merged
> unless the required cleaning up happens.
In your example there are alternatives, can you name another system that 
gives me speech from the moment the OS takes control of the computer, to the 
moment it turns off? Cleaning up code is important, and may be there would 
be more motivation from others if it was in the way. If this too much of a 
problem having it there, it would be good of those who know how to clean it 
up helped with it (doing it or helping Kirk and the others writing speakup). 
As I said leaving things doesn't get it done.
> 
>> The other thing is that speakup seems to be good enough for some distros to 
>> include speakup in the default kernel and some others have it as an 
>> optional kernel but still in the main distro, and are they less stable than 
>> others? (these include slackware, gentoo, grml). I always found it strange 
>> that Redhat said how good speakup is, but never had it included on the main 
>> distro media.
> 
> The problem is not a stability problem, but a code correctness / style
> / ... You may have code that works, but if it is unmaintainable, some
> day it won't work any more.
OK maybe it is to do with maintaining code, but still there is the question 
of distros using speakup, surely they should be having problems or likely 
to have problems sometime?
> 
> Samuel
> 
> 
> 

Re: kernel pre-emption and software speech

[Samuel Thibault]

Michael Whapples, le Thu 05 Oct 2006 18:23:02 +0100, a écrit :
> Samuel Thibault writes:
> 
> > Michael Whapples, le Wed 04 Oct 2006 22:47:11 +0100, a écrit :
> >> In some cases we have to accept less than perfect code. By this I mean that 
> >> it may function correctly with out no problems, but may need tidying up and 
> >> other techniques may be more effecient, but if it is the only software that 
> >> offers those functions then you should accept for what it gives, unless you 
> >> are prepared to sort it out. Just leaving it definitely doesn't resolve the 
> >> issues.
> > 
> > I'm sorry, but that's not how things work with Linux. The Reiser4 code
> > has been waiting for a long time for instance, and won't be merged
> > unless the required cleaning up happens.
> In your example there are alternatives, can you name another system that 
> gives me speech from the moment the OS takes control of the computer, to the 
> moment it turns off?

Kernel hackers just won't take this as a reason for including code that
they consider not clean enough.

> >> The other thing is that speakup seems to be good enough for some distros to 
> >> include speakup in the default kernel and some others have it as an 
> >> optional kernel but still in the main distro, and are they less stable than 
> >> others? (these include slackware, gentoo, grml). I always found it strange 
> >> that Redhat said how good speakup is, but never had it included on the main 
> >> distro media.
> > 
> > The problem is not a stability problem, but a code correctness / style
> > / ... You may have code that works, but if it is unmaintainable, some
> > day it won't work any more.
> OK maybe it is to do with maintaining code, but still there is the question 
> of distros using speakup, surely they should be having problems or likely 
> to have problems sometime?

Yes, I guess they are having troubles (and cope with them, since they
are faced to their users, while kernel hackers aren't).

Samuel

Re: kernel pre-emption and software speech

[John Heim]

I think that those of us who depend on speakup but don't have the expertise 
to help with the code could contribute in terms of putting pressure (for 
lack of a better term) on the kernel developers to give you the assistance 
you need.

I mean, we could write to the powers that be, whoever they are (Alan and/or 
Linus?) and ask them to make this a high priority item.

Maybe the kernel developers don't understand how important speakup is. 
People's livelihoods (like mine) depend on it. I literally could not do my 
job w/o speakup.


With you being willing to do the work, it would be really unforgivable if 
the holdup was on their end.  I don't thing anybody would be unwilling to 
help if they were made aware of the problem. That would be inhuman.

Even here at the math department at the University of Wisconsin, not 
everybody patches the kernel when they make a custom kernel for particular 
machine. And this is a fairly small shop. Say you work in a large shop, the 
only machines that are going to have speakup built in are those you set up 
yourself. And that means that for a blind person, the vast majority of 
machines at a facility would be unusable.

And then there's the live CDs. We either have to have special versions of 
those or we have to count on the developers to patch the code. You've got to 
give the people at grml a hand for their work. But it would be so much nicer 
if it just worked by default.




----- Original Message ----- 
From: "Kirk Reiser" <kirk@braille.uwo.ca>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Sent: Wednesday, October 04, 2006 12:28 PM
Subject: Re: kernel pre-emption and software speech


> Quite a few of the changes suggested in Adrian Bunk's suggestion list
> were implemented.  Others I didn't understand the criticisms and when
> I asked did not get definitive answers.  Some of the suggestions I
> didn't understand, I could not figure out how else to implement.  I
> have offered to rewrite sections of the code with help from many
> people that have offered and have never been able to actually get any
> help after the offering.  I have basically given up on the process
> because of lack of expertise on my part and lack of assistance on the
> part of others.  I originally worked closely with Alan Cox to get it
> in and it was mostly there and then Alan and Linus had their falling
> out and so that ended up slipping down the tubes.
>
> I would like speakup to be in the actual kernel code because that
> would make my job easier maintaining it when someone else changes the
> kernel code they would have to be partially aware of the speakup code
> needing to be modified also.  As it is speakup works well for the most
> part and is relatively easy to patch for novices.  I am not going to
> try to get in the kernel code any more unless someone is really
> willing to help me with the modifications and answer my silly
> questions when I have them, which is often.
>
> I have been moving speakup to git or I should say Daniel Drake has
> moved speakup to git but it is not ready for prime-time yet.  I either
> have to rewrite the checkout/checkin scripts or move to another system
> such as quilt.  My first looks at quilt have not been overwhelmingly
> encouraging because of what looks to be lack of documentation or
> tutorials or something.  I can't find anything useful reading wise on
> the quilt web page.  Maybe I have the wrong page who knows but Daniel
> gave it to me so I suspect it is just sparse.
>
>  Kirk
>
> -- 
>
> Kirk Reiser The Computer Braille Facility
> e-mail: kirk@braille.uwo.ca University of Western Ontario
> phone: (519) 661-3061
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> 

Re: kernel pre-emption and software speech

[John Heim]

> In your example there are alternatives, can you name another system that
> gives me speech from the moment the OS takes control of the computer, to 
> the
> moment it turns off?

Kernel hackers just won't take this as a reason for including code that
they consider not clean enough.


Right. And they shouldn't. I don't think we want to be asking for "special" 
treatment in terms of messing up the linux  kernel.

But Kirk seemed to be saying that he dropped his effort to get the speakup 
code included with the regular kernel source because of a lack of assistance 
from the kernel developers. And what Michael says about how important 
speakup is might have an effect on that. With the maturity level linux has 
already achieved, it's hard to imagine what higher priorities they could 
have at this point.

Re: kernel pre-emption and software speech

[Samuel Thibault]

Hi,

Kirk Reiser, le Wed 04 Oct 2006 13:28:45 -0400, a écrit :
> Others I didn't understand the criticisms and when I asked did not get
> definitive answers.

There is never a definitive answer to a question you know ;)
But I'm ready to answer your questions.  Just a few starts:

- as said in "the code should follow Documentation/CodingStyle better
(no spaces between the braces and function arguments)", you need to
reindent your code. You can use linux/scripts/Lindent for this.  Yes,
_you_ need to reindent your code.  Projects that accept different
indentations becomes more and more tedious to develop on the long run.
- there's a bunch of global variables in speakup.c, they deserve
prefixing with "spk_"
- it would be very useful for kernel hackers (who of course don't have
synth hardware) to have a simple dummy driver that echoes on the serial
port what would be spoken by speakup.
- I'll send you a little cleanup patch (not tested though).  Yes,
speakup is most probably broken on SMP, since it doesn't use a single
spinlock (that probably explains the "kernel preemption garbages
speakup" issue that started the thread).
- key grabbing and console following will need a more generic interface,
not specialized to speakup.  I'll try to give a try on linux-kernel to
see how people would see it be done.

Samuel