Serial conflict

Serial conflict

[Jacob Schmude]

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

Hi all,
Well, it's been a while but here I am again to stir up a bit of
trouble. <grin>
I'm attempting to use Speakup with a serial synthesizer on Archlinux
with kernel 2.6.37.1-1 (2.6.37-ARCH is the in-kernel version number).
Speakup is included in these kernels, but trying to load any of the
speakup synthesizer drivers results in the following:
synth probe
Ports not available, trying to steal them
Trying to free nonexistent resource <00000000000003f8-00000000000003ff>
Unable to allocate port at 3f8, errno -16
LiteTalk: not found
ltlk: device probe failed

This happens with any serial synth I have, though obviously substitute
the other driver names in these errors. I've tried the Doubletalk LT,
Dectalk Express, and Accent SA (yes, all of which I do have). I get
the same result whether I allow Speakup to probe or whether I specify
a ser=0 parameter.
I've trieed a few things. First, I tried unbinding the in-kernel
serial driver from that port via sysfs, but there's no change although
the port does seem to successfully unbind. Second, I searched the
speakup archives and found a post from January detailing this problem,
and the poster had success removing the return NULL statement at that
point in serialio.c. This didn't work for me, however, and I'm not all
that surprised it didn't.
I've tried the staging speakup in the kernel, and with the latest git.
The return NULL removal was attempted on the git source tree.
Can anyone shed a bit of light on what I'm probably doing wrong? I can
compile a custom kernel if necessary, though I was hoping not to need
this. It worked in kernel 2.6.36, but obviously something critical has
changed.

Thanks

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNbar4AAoJEDtK6CrF/Uo1IwEH/R7wM2GoBwVss4rtEzSSBbxC
uUQox6uCAbOkvO1f6BualtyOkbFoyUrGcEinpA2vIlZ8avyPnucSCZd+ehNgtoWi
vQjpnOsBKoEun7H41aJ42DojRhfdwBgeeXOJCT4Gxz63XWNjM+Uc/po/X9mz6qyG
yYTEKBOuwGVQur+wKjMi3RLNhSxJwqhNxcfF+6uwTdixP8nq8wpDSuqj/z6PvdWj
OaN4ew5O73hw3+C5y/nfnxFMkwQwn6ZMvApl/57EL5ZwAyF7dGMg2dRNkZWOlCiX
pLAunnsZrbFDGuLLzD9s60bjAiDp60DMolYly989kvNLsuySgsxVEBNzrlrsqVk=
=meVR
-----END PGP SIGNATURE-----

Re: Serial conflict

[covici]

Once you delete that return statement, you have to recompile the kernel
-- in 2.6.37 I would using the staging driver instead of git.  This
works for me , at any rate.

Jacob Schmude <j.schmude@gmail.com> wrote:

> Hi all,
> Well, it's been a while but here I am again to stir up a bit of
> trouble. <grin>
> I'm attempting to use Speakup with a serial synthesizer on Archlinux
> with kernel 2.6.37.1-1 (2.6.37-ARCH is the in-kernel version number).
> Speakup is included in these kernels, but trying to load any of the
> speakup synthesizer drivers results in the following:
> synth probe
> Ports not available, trying to steal them
> Trying to free nonexistent resource <00000000000003f8-00000000000003ff>
> Unable to allocate port at 3f8, errno -16
> LiteTalk: not found
> ltlk: device probe failed
> 
> This happens with any serial synth I have, though obviously substitute
> the other driver names in these errors. I've tried the Doubletalk LT,
> Dectalk Express, and Accent SA (yes, all of which I do have). I get
> the same result whether I allow Speakup to probe or whether I specify
> a ser=0 parameter.
> I've trieed a few things. First, I tried unbinding the in-kernel
> serial driver from that port via sysfs, but there's no change although
> the port does seem to successfully unbind. Second, I searched the
> speakup archives and found a post from January detailing this problem,
> and the poster had success removing the return NULL statement at that
> point in serialio.c. This didn't work for me, however, and I'm not all
> that surprised it didn't.
> I've tried the staging speakup in the kernel, and with the latest git.
> The return NULL removal was attempted on the git source tree.
> Can anyone shed a bit of light on what I'm probably doing wrong? I can
> compile a custom kernel if necessary, though I was hoping not to need
> this. It worked in kernel 2.6.36, but obviously something critical has
> changed.
> 
> Thanks
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Serial conflict

[Jacob Schmude]

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

Hi
Doesn't work, unfortunately. I do have it sort of working with the git
version (staging isn't working) but not the way it should be. Speakup
and the kernel's serial driver constantly battle over it. Seriously,
this is 2011. One would think we'd be over having to recompile kernels
for things like this.


On 03/01/2011 10:46 PM, covici@ccs.covici.com wrote:
> Once you delete that return statement, you have to recompile the
> kernel -- in 2.6.37 I would using the staging driver instead of
> git. This works for me , at any rate.
>
> Jacob Schmude <j.schmude@gmail.com> wrote:
>
>> Hi all, Well, it's been a while but here I am again to stir up a
>> bit of trouble. <grin> I'm attempting to use Speakup with a
>> serial synthesizer on Archlinux with kernel 2.6.37.1-1
>> (2.6.37-ARCH is the in-kernel version number). Speakup is
>> included in these kernels, but trying to load any of the speakup
>> synthesizer drivers results in the following: synth probe Ports
>> not available, trying to steal them Trying to free nonexistent
>> resource <00000000000003f8-00000000000003ff> Unable to allocate
>> port at 3f8, errno -16 LiteTalk: not found ltlk: device probe
>> failed
>>
>> This happens with any serial synth I have, though obviously
>> substitute the other driver names in these errors. I've tried the
>> Doubletalk LT, Dectalk Express, and Accent SA (yes, all of which
>> I do have). I get the same result whether I allow Speakup to
>> probe or whether I specify a ser=0 parameter. I've trieed a few
>> things. First, I tried unbinding the in-kernel serial driver from
>> that port via sysfs, but there's no change although the port does
>> seem to successfully unbind. Second, I searched the speakup
>> archives and found a post from January detailing this problem,
>> and the poster had success removing the return NULL statement at
>> that point in serialio.c. This didn't work for me, however, and
>> I'm not all that surprised it didn't. I've tried the staging
>> speakup in the kernel, and with the latest git. The return NULL
>> removal was attempted on the git source tree. Can anyone shed a
>> bit of light on what I'm probably doing wrong? I can compile a
>> custom kernel if necessary, though I was hoping not to need this.
>> It worked in kernel 2.6.36, but obviously something critical has
>> changed.
>>
>> Thanks
>>
>>
>> _______________________________________________ Speakup mailing
>> list Speakup@braille.uwo.ca
>> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNbeoKAAoJEDtK6CrF/Uo18q0IAK4cf2bcXvvdzLF52erlDud4
Vg5QyMPjRkpr700NUpG0FN7/e6CpuPLjoYD3g/Kgeq0all/rPpMDDCH4If+IYPGH
wEgNBITVB1tV7JZbN7ZGfEfb2lThrx9P8MKFFKinlvC3T2xcYYXrsN9tfgdGnN/J
HMm/DK96js51xby6Ge/F4JxYo01cTQ66bVldphUf9mRsyfe4vPoS6MpRRPQl19c+
RHBjmt6XoyxXYY8R4RssIuTtYiyvyEy4w096IDn3VLrUYByblUjWOCBGcDpIucjp
7zSSislZEoJlpZaMEoTUW40kv0wKvIQAQRkLyEw0hJa86H/4pTlymMWrSDNhvhI=
=xHmE
-----END PGP SIGNATURE-----

Re: Serial conflict

[Chuck Hallenbeck]

Jacob,

My distro is identical to yours, also on a 64 bit machine,  and here is
how I configure speakup for both a software synthesizer and a serial
synthesizer:

1. In /etc/rc.conf, my MODULES line looks like this:

MODULES=(ipv6 speakup speakup_soft speakup_ltlk)

2. In /etc/modprobe.d/modprobe.conf, add these lines:

options speakup_soft start=0
options speakup_ltlk ser=0 start=0

3. In /etc/rc.local, add these lines:

# start talking
talkwith soft espeakup
speakupconf load

In the last group, the talkwith command could specify either device, 
and once the syhstem is running, the talkwith command switches between
devices gracefully, I use sudo to run it as root.

Hope that elps.

Chuck




-- 
Chuck in Hudson.
My website is hallenbeck.ftml.net, my Jabber ID is chuckh1@jabber.org

Re: Serial conflict

[Jacob Schmude]

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

Hi Chuck
I wish it did, but I can't load any of the hardware synth modules.
When I try, I get the serial conflict where by Speakup tries to steal
the ports from the kernel and can't. I know how to configure Speakup
and things like that, but I need to figure out what is going wrong
with the serial driver before it will work. I'm horrible at kernel
hacking, so I've only gotten it to half work where by the kernel and
speakup battle for control of the port constantly. Speakup does talk
when I have it do this, but responsiveness is awful. Using either an
unchanged staging or clean git, however, just does not work. It is
rather irritating, since it did work in 2.6.36 and, examining the
configs for both kernels, I can't see anything that even remotely
looks related to this.

Thanks

On 03/02/2011 03:01 AM, Chuck Hallenbeck wrote:
> Jacob,
>
> My distro is identical to yours, also on a 64 bit machine, and here is
> how I configure speakup for both a software synthesizer and a serial
> synthesizer:
>
> 1. In /etc/rc.conf, my MODULES line looks like this:
>
> MODULES=(ipv6 speakup speakup_soft speakup_ltlk)
>
> 2. In /etc/modprobe.d/modprobe.conf, add these lines:
>
> options speakup_soft start=0
> options speakup_ltlk ser=0 start=0
>
> 3. In /etc/rc.local, add these lines:
>
> # start talking
> talkwith soft espeakup
> speakupconf load
>
> In the last group, the talkwith command could specify either device,
> and once the syhstem is running, the talkwith command switches between
> devices gracefully, I use sudo to run it as root.
>
> Hope that elps.
>
> Chuck
>
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNboCGAAoJEDtK6CrF/Uo1X9kIAKujzbKsoJ+luB+GIOJ8KVWH
AQgttbR8x/vfmpIRvbQOmP2153EI3yBl9WmC9ByySBcTr8ZbIKm1eakd5o43w768
nLmUYxxzTagzYak+rYoT0/FUVT6gIfR1AcDRhIgiJ1+8TpDSwIJ/6ZbN2QxXUpL4
FxCB9lV7tdRH2zE68L/T8VVSENz0ij+fBbm8isBbL6GnxyUvexAT6suyUu/nTbOM
f/d3Tu7DS2EhOcki2hUoX26zfvAGi6ggmqnXx32NNkEsbMKL1DXILsez91Ql1Xo7
RfPYjaLTvDaGTiylr8H161EaCmczizKA5aoKBXyeSkA5pPc6+8XufhErIOc0sGk=
=S5TH
-----END PGP SIGNATURE-----

Re: Serial conflict

[Steve Holmes]

Hi Jacob,

I too use Arch Linux but also experience the same problem you do.
Though I didn't get into messing with kernel details, I tried the
solution that Chuck suggested in his previous message, but no joy for
me either.  My failure to get serials to work goes back to something
like 2.6.34.  've been trying this with a Speakout, using the
speakup_spkout driver. I thought someone told me that driver had a bug
of some kind but I really would like to be able to use an external
synthesizer, especially if software speech goes south when playing
with pulse audio or other such evil things.

I really wish we could get to the bottom of this serial problem since
that used to be speakup's life blood.  I think many of us are hoping
the recent kernel integration might lead us to support in getting the
serial support beefed up so you could even use USB or PCI serial ports
and not be locked into the old ones which hardly exist anymore on most
new computers.

On Wed, Mar 02, 2011 at 09:38:21AM -0800, Jacob Schmude wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Chuck
> I wish it did, but I can't load any of the hardware synth modules.
> When I try, I get the serial conflict where by Speakup tries to steal
> the ports from the kernel and can't. I know how to configure Speakup
> and things like that, but I need to figure out what is going wrong
> with the serial driver before it will work. I'm horrible at kernel
> hacking, so I've only gotten it to half work where by the kernel and
> speakup battle for control of the port constantly. Speakup does talk
> when I have it do this, but responsiveness is awful. Using either an
> unchanged staging or clean git, however, just does not work. It is
> rather irritating, since it did work in 2.6.36 and, examining the
> configs for both kernels, I can't see anything that even remotely
> looks related to this.
> 
> Thanks
> 
> On 03/02/2011 03:01 AM, Chuck Hallenbeck wrote:
> > Jacob,
> >
> > My distro is identical to yours, also on a 64 bit machine, and here is
> > how I configure speakup for both a software synthesizer and a serial
> > synthesizer:
> >
> > 1. In /etc/rc.conf, my MODULES line looks like this:
> >
> > MODULES=(ipv6 speakup speakup_soft speakup_ltlk)
> >
> > 2. In /etc/modprobe.d/modprobe.conf, add these lines:
> >
> > options speakup_soft start=0
> > options speakup_ltlk ser=0 start=0
> >
> > 3. In /etc/rc.local, add these lines:
> >
> > # start talking
> > talkwith soft espeakup
> > speakupconf load
> >
> > In the last group, the talkwith command could specify either device,
> > and once the syhstem is running, the talkwith command switches between
> > devices gracefully, I use sudo to run it as root.
> >
> > Hope that elps.
> >
> > Chuck
> >
> >
> >
> >
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJNboCGAAoJEDtK6CrF/Uo1X9kIAKujzbKsoJ+luB+GIOJ8KVWH
> AQgttbR8x/vfmpIRvbQOmP2153EI3yBl9WmC9ByySBcTr8ZbIKm1eakd5o43w768
> nLmUYxxzTagzYak+rYoT0/FUVT6gIfR1AcDRhIgiJ1+8TpDSwIJ/6ZbN2QxXUpL4
> FxCB9lV7tdRH2zE68L/T8VVSENz0ij+fBbm8isBbL6GnxyUvexAT6suyUu/nTbOM
> f/d3Tu7DS2EhOcki2hUoX26zfvAGi6ggmqnXx32NNkEsbMKL1DXILsez91Ql1Xo7
> RfPYjaLTvDaGTiylr8H161EaCmczizKA5aoKBXyeSkA5pPc6+8XufhErIOc0sGk=
> =S5TH
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Serial conflict

[Jacob Schmude]

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

Hi Steve
I'm glad I'm not the only one, though I know that doesn't help. It's
definitely not the speakout driver in this case. I don't have one, but
I do have a doubletalk lt, accent sa, and dectalk express, all of
which I've tried. I'd try my Keynote SA as well except Speakup doesn't
support that one.
I understand the hope of better serial support, though I think the
logic is flawed. I remember once before when speakup/kernel
integration was being pursued, and one of the reasons it didn't get in
was because of its self-contained and ancient serial stack. However,
expecting others to help--others who, I might add, don't need speakup
and probably never will--is probably not going to gain results. If
this is going to be done, it's going to be someone who needs speakup
and has good kernel development skills, not some random kernel
developer with nothing else to do. Things just don't work that way. I
wish I could do it, but what I know about kernel hacking you could
write on a 3 by 5 card in jumbo braille and still have blank space
left over. <grin> Application programming is fine, but once I hit
kernel land my head starts to hurt.


On 03/02/2011 01:20 PM, Steve Holmes wrote:
> Hi Jacob,
>
> I too use Arch Linux but also experience the same problem you do.
> Though I didn't get into messing with kernel details, I tried the
> solution that Chuck suggested in his previous message, but no joy
> for me either. My failure to get serials to work goes back to
> something like 2.6.34. 've been trying this with a Speakout, using
> the speakup_spkout driver. I thought someone told me that driver
> had a bug of some kind but I really would like to be able to use an
> external synthesizer, especially if software speech goes south when
> playing with pulse audio or other such evil things.
>
> I really wish we could get to the bottom of this serial problem
> since that used to be speakup's life blood. I think many of us are
> hoping the recent kernel integration might lead us to support in
> getting the serial support beefed up so you could even use USB or
> PCI serial ports and not be locked into the old ones which hardly
> exist anymore on most new computers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNbrhSAAoJEDtK6CrF/Uo1VpoIAIacStbNQuDqqB6hViV3Pru8
fgsXELuFB7Vt3FKXYREXumLWyHQq1GCRxAPIoQbyC5oQaFYPbFSgVVXa7NRNk1jZ
MigBzAIqtiW5ZBUqwf1R/VtiJS9pYirXqgDj9ZbJkFrkSvSIpqujMNju77dfvOjI
an2VWw3qNE7Ol8iN3ptBxRW6NZ+CEvf2itNi8QFZGB+16ba2OZGsiatYRRtGfHq4
WBocSDf5QBuKIbBxUii9DrdiP50wlGAGiHB7A6RhtQaHYkPvdAaM9VyQqSRnTG7i
6kZ+H6TdyiAZkxPdMLE7DHWIXHeAWfRa1Gwy+GKLsc9h3a6RDuO9bbyeCla7cy0=
=Jxjn
-----END PGP SIGNATURE-----

Re: Serial conflict

[Steve Holmes]

Yeah, mine too.  I never delved into kernel programming either.  Maybe
it isn't all that hard but I don't know where to start in that world.
The thing that bugs me here with the serial port problems is that this
stuff seems to work on some people's machines and not on others.
Where I run into serial issues is on a machine that apparently has 64
bit capability but at the time I built my Arch installation, I hadn't
realized it so it is basically built as a 32 bit system (x86). Hey, I
might try the speakup-enabled Arch live CD; wonderif I can override
the speakup.synth parameter on that; never tried so far.

Chris, can one do that with your live CD? if so, what name is used for
the image or first word of the command line?  I guess I could inspect
the grub lines you have on that disk to figure that out.

On Wed, Mar 02, 2011 at 01:36:21PM -0800, Jacob Schmude wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Steve
> I'm glad I'm not the only one, though I know that doesn't help. It's
> definitely not the speakout driver in this case. I don't have one, but
> I do have a doubletalk lt, accent sa, and dectalk express, all of
> which I've tried. I'd try my Keynote SA as well except Speakup doesn't
> support that one.
> I understand the hope of better serial support, though I think the
> logic is flawed. I remember once before when speakup/kernel
> integration was being pursued, and one of the reasons it didn't get in
> was because of its self-contained and ancient serial stack. However,
> expecting others to help--others who, I might add, don't need speakup
> and probably never will--is probably not going to gain results. If
> this is going to be done, it's going to be someone who needs speakup
> and has good kernel development skills, not some random kernel
> developer with nothing else to do. Things just don't work that way. I
> wish I could do it, but what I know about kernel hacking you could
> write on a 3 by 5 card in jumbo braille and still have blank space
> left over. <grin> Application programming is fine, but once I hit
> kernel land my head starts to hurt.
> 
> 
> On 03/02/2011 01:20 PM, Steve Holmes wrote:
> > Hi Jacob,
> >
> > I too use Arch Linux but also experience the same problem you do.
> > Though I didn't get into messing with kernel details, I tried the
> > solution that Chuck suggested in his previous message, but no joy
> > for me either. My failure to get serials to work goes back to
> > something like 2.6.34. 've been trying this with a Speakout, using
> > the speakup_spkout driver. I thought someone told me that driver
> > had a bug of some kind but I really would like to be able to use an
> > external synthesizer, especially if software speech goes south when
> > playing with pulse audio or other such evil things.
> >
> > I really wish we could get to the bottom of this serial problem
> > since that used to be speakup's life blood. I think many of us are
> > hoping the recent kernel integration might lead us to support in
> > getting the serial support beefed up so you could even use USB or
> > PCI serial ports and not be locked into the old ones which hardly
> > exist anymore on most new computers.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJNbrhSAAoJEDtK6CrF/Uo1VpoIAIacStbNQuDqqB6hViV3Pru8
> fgsXELuFB7Vt3FKXYREXumLWyHQq1GCRxAPIoQbyC5oQaFYPbFSgVVXa7NRNk1jZ
> MigBzAIqtiW5ZBUqwf1R/VtiJS9pYirXqgDj9ZbJkFrkSvSIpqujMNju77dfvOjI
> an2VWw3qNE7Ol8iN3ptBxRW6NZ+CEvf2itNi8QFZGB+16ba2OZGsiatYRRtGfHq4
> WBocSDf5QBuKIbBxUii9DrdiP50wlGAGiHB7A6RhtQaHYkPvdAaM9VyQqSRnTG7i
> 6kZ+H6TdyiAZkxPdMLE7DHWIXHeAWfRa1Gwy+GKLsc9h3a6RDuO9bbyeCla7cy0=
> =Jxjn
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Serial conflict

[Christopher Brannon]

Steve Holmes <steve@holmesgrown.com> writes:

> might try the speakup-enabled Arch live CD; wonderif I can override
> the speakup.synth parameter on that; never tried so far.

There's no speakup.synth parameter.  It just loads the softsynth module
and starts espeakup.

-- Chris

Re: Serial conflict

[Steve Holmes]

On Thu, Mar 03, 2011 at 04:24:44PM +0000, Christopher Brannon wrote:
> There's no speakup.synth parameter.  It just loads the softsynth module
> and starts espeakup.
Oh, so there's no way to override the startup boot options like other
live media? I thought that was a native function of the kernel. But if
those other modules aren't loaded in the initial RAMFS, maybe that
wouldn't be possible.  I was just thinking if one wanted to try out
serial support at boot time.  No big deal here but I thought it would
be interesting to try.

> -- Chris
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Serial conflict

[Christopher Moore]

Hello,
Here's another thought:  Suppose we did away with all the hardware synth 
modules in speakup.  All interaction with speakup could be done through 
the /dev/softsyn device.  This would require converting the hardware 
modules to user-space programs which would communicate with speakup over 
the /dev/softsyn device and to the hardware synth over the /dev/tts 
serial device.

What I'm suggesting is to remove serial port support from speakup since 
it appears to be problematic at best.

Chris

Re: Serial conflict

[Zachary Kline]

This is an excellent suggestion, if at all practical.  If we did this it might also let us handle USB serial ports and the like with ease, since we'd then be in userspace.
Hope we can make something of it,
Zack.
On Mar 4, 2011, at 8:10 AM, Christopher Moore wrote:

> Hello,
> Here's another thought:  Suppose we did away with all the hardware synth modules in speakup.  All interaction with speakup could be done through the /dev/softsyn device.  This would require converting the hardware modules to user-space programs which would communicate with speakup over the /dev/softsyn device and to the hardware synth over the /dev/tts serial device.
> 
> What I'm suggesting is to remove serial port support from speakup since it appears to be problematic at best.
> 
> Chris
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

RE: Serial conflict

[Albert Sten-Clanton]

Would this influence how early in the boot-up Speakup could kick in using a
hardware synthesizer?  I'm sorry to say I know nothing about this area.
Thanks!

Al 

-----Original Message-----
From: speakup-bounces@braille.uwo.ca [mailto:speakup-bounces@braille.uwo.ca]
On Behalf Of Zachary Kline
Sent: Friday, March 04, 2011 11:12 AM
To: Speakup is a screen review system for Linux.
Subject: Re: Serial conflict

This is an excellent suggestion, if at all practical.  If we did this it
might also let us handle USB serial ports and the like with ease, since we'd
then be in userspace.
Hope we can make something of it,
Zack.
On Mar 4, 2011, at 8:10 AM, Christopher Moore wrote:

> Hello,
> Here's another thought:  Suppose we did away with all the hardware synth
modules in speakup.  All interaction with speakup could be done through the
/dev/softsyn device.  This would require converting the hardware modules to
user-space programs which would communicate with speakup over the
/dev/softsyn device and to the hardware synth over the /dev/tts serial
device.
> 
> What I'm suggesting is to remove serial port support from speakup since it
appears to be problematic at best.
> 
> Chris
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
Speakup@braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Serial conflict

[David Csercsics]

On Fri, Mar 04, 2011 at 12:16:38PM -0500, Albert Sten-Clanton wrote:
> Would this influence how early in the boot-up Speakup could kick in using a
> hardware synthesizer?  I'm sorry to say I know nothing about this area.
It shouldn't provided we keep the userspace programs small enough to be
contained nicely on a ramfs. This is what the kernel's early userspace
stuff is designed for. Going to make building custom kernels a bit more
of a pain and there will need to be init scripts to start the synth
program back up after the system has properly transferred control to
the real root file system but you could make that happen very early so
you'd only lose speech for less than a second unless there's some error
or other with the boot process which likely means you'll need to pull
out your rescue CD to fix it anyway.

speakup in user space (was Re: Serial conflict)

[Jacob Schmude]

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

Hi
If that were done, why have Speakup in the kernel at all? Software
speech cannot be included in the kernel itself, and this would mean
that hardware speech would not be able to kick in as early if needed.
Also, we would then be under the limitations of user-space programs in
that when a kernel panic happens, we may not be able to review it
whether we're using hardware synthesizers or not.
If we were to go this route, my suggestion would be to get Speakup out
of the kernel entirely and convert the whole thing to user-space. I'd
use an approach similar to BRLTTY, using the /dev/vcsa devices. WE
wouldn't lose anything more than if serial support were removed, and
the integration problems with various distributions would be
completely gone. No kernel conflicts, no module versioning, none of
that. It would also remove the necessity for middleware between
speakup and software speech. The only reason I think Speakup was in
the kernel in the first place was the advantage it gave hardware
synthesizers as far as early boot sequences and reading even the worst
kernel panics (remember hardware speech was the only option in Linux
back then). Take that away, and we might as well take Speakup out of
the kernel and move the whole thing into user-space, since that would
remove the one and only advantage for speakup being in kernel-space.
To be clear, I'm not against moving speakup into user-space. In fact,
I think it would be for the best in the long run, but there's no need
to keep any of it in the kernel if we do.


On 03/04/2011 08:10 AM, Christopher Moore wrote:
> Hello,
> Here's another thought: Suppose we did away with all the hardware
> synth modules in speakup. All interaction with speakup could be
> done through the /dev/softsyn device. This would require converting
> the hardware modules to user-space programs which would communicate
> with speakup over the /dev/softsyn device and to the hardware synth
> over the /dev/tts serial device.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNcSomAAoJEDtK6CrF/Uo1OxkH/irNp/uXpnlpNnhBa1CQ3SBD
SoURw4o4QKI3ik85Ym7gtj0Z1CufSyKNocY7M5wDfDfAZmfkN37wdeFSwWcLeioM
eJCpakaCmvs5WN7HW5bn50l8kh0GybNtxCSdRfXNN/xLEhCnP85IuXStqahesNvJ
wcqljpGEgm8CCdM4tLxykPN+j6A5mG/p1NW5Dx+QKM33WwXZFkY6rM8VR8//0gJM
8JKKrnEbrvUjaDOY7vVHlhEzcZKUb+T8dZMTtkcegISKqi7elIogGCuNngHjesXi
p2SogGa3m023ozuZW3E/MikVIZ/67H8Onr+e0maWWluQg26xwNA1T+8KAwHUOSA=
=wn0H
-----END PGP SIGNATURE-----

Re: speakup in user space (was Re: Serial conflict)

[William Hubbs]

On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi
> If that were done, why have Speakup in the kernel at all? Software
> speech cannot be included in the kernel itself, and this would mean
> that hardware speech would not be able to kick in as early if needed.
> Also, we would then be under the limitations of user-space programs in
> that when a kernel panic happens, we may not be able to review it
> whether we're using hardware synthesizers or not.
> If we were to go this route, my suggestion would be to get Speakup out
> of the kernel entirely and convert the whole thing to user-space. I'd
> use an approach similar to BRLTTY, using the /dev/vcsa devices. WE
> wouldn't lose anything more than if serial support were removed, and
> the integration problems with various distributions would be
> completely gone. No kernel conflicts, no module versioning, none of
> that. It would also remove the necessity for middleware between
> speakup and software speech.

SBL uses the vcsa devices. I attempted to use this screen reader, but I
found very quickly that it doesn't work the way we expect screen readers
to work. For example, if you type the date command, the next thing you
hear read back to you is the command prompt. You are required to use the
screen review mode to find the output from the command and read it. As I
understand it, this is a limitation of the vcsa devices.

The closest thing as I understand it to a user space screen reader that
really works is yasr, but you have to be logged in to use that.

William

Re: speakup in user space (was Re: Serial conflict)

[Jacob Schmude]

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

Hi
I don't think that's a limitation of the VCSA devices themselves, but
rather how they are used. These devices show the screen as it
currently is at any given time, although documentation for them is
rather sparse. But couldn't we, rather than querying the device,
monitor it instead for incoming text? I'll do some digging and see
what I can find out.
It just seems that to have speakup in the kernel even after removing
serial support would leave us with all of the problems with none of
the advantages remaining.



On 03/04/2011 10:52 AM, William Hubbs wrote:
> On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Hi If that were done, why have Speakup in the kernel at all?
>> Software speech cannot be included in the kernel itself, and this
>> would mean that hardware speech would not be able to kick in as
>> early if needed. Also, we would then be under the limitations of
>> user-space programs in that when a kernel panic happens, we may
>> not be able to review it whether we're using hardware
>> synthesizers or not. If we were to go this route, my suggestion
>> would be to get Speakup out of the kernel entirely and convert
>> the whole thing to user-space. I'd use an approach similar to
>> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything
>> more than if serial support were removed, and the integration
>> problems with various distributions would be completely gone. No
>> kernel conflicts, no module versioning, none of that. It would
>> also remove the necessity for middleware between speakup and
>> software speech.
>
> SBL uses the vcsa devices. I attempted to use this screen reader,
> but I found very quickly that it doesn't work the way we expect
> screen readers to work. For example, if you type the date command,
> the next thing you hear read back to you is the command prompt. You
> are required to use the screen review mode to find the output from
> the command and read it. As I understand it, this is a limitation
> of the vcsa devices.
>
> The closest thing as I understand it to a user space screen reader
> that really works is yasr, but you have to be logged in to use
> that.
>
> William
>
> _______________________________________________ Speakup mailing
> list Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNcVF1AAoJEDtK6CrF/Uo1Lk0H/i6q5fKxDiCYLo3dNO9djAtT
aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M
fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1
MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo
Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO
v1xj2oKZOCUBEIjlZhLXYOdyOPPmLLLpwKSfFHDICwMcTeNAxVbg1bDSOWiETlw=
=zJ6i
-----END PGP SIGNATURE-----

Re: Serial conflict

[Frost]

On Fri, Mar 04, 2011 at 08:12:23AM -0800, Zachary Kline wrote:
> This is an excellent suggestion, if at all practical.  If we did this 
> it might also let us handle USB serial ports and the like with ease, 
> since we'd then be in userspace.

	Then what's the point of getting SpeakUP into the kernel.  And 
what about "power-of to power-off support.  How is ANY blind linux user 
going to manage to fsck a disk when needed.  We might as well go back to 
friggin yasr.

	We just got SpeakUP into the kernel and may soon be getting 
support from other kernel developers to support serial ports properly 
from kernelspace, and you want to ditch it all and go back to 
prehistoric SpeakUP and scratching at fleas.

	You people disgust me.

				Michael

--
Linux User:	177869 # Powered By: Intel # http://rivensight.dyndns.org
          Postings Copyrighted 2010-2011 by: Michael Ferranti

Re: Serial conflict

[covici]

I agree, don't take speakup out of the kernel -- I had something the
other day, where I had the wrong ramdisk version and it would not load
any modules, but I had speakup -- since  my synth is built into the
kernel and was able to figure out what happened -- if speakup were in
user space I would have been sunk.

But how about the following -- can we put a notify into the serial synth
initialization so speakup would know when things were happening and
could simulate an open for whatever device, or steal the port before the
serial synth could do anything -- prefer the former if possible.

Frost <znvyyvfgf@gmail.com> wrote:

> On Fri, Mar 04, 2011 at 08:12:23AM -0800, Zachary Kline wrote:
> > This is an excellent suggestion, if at all practical.  If we did this 
> > it might also let us handle USB serial ports and the like with ease, 
> > since we'd then be in userspace.
> 
> 	Then what's the point of getting SpeakUP into the kernel.  And 
> what about "power-of to power-off support.  How is ANY blind linux user 
> going to manage to fsck a disk when needed.  We might as well go back to 
> friggin yasr.
> 
> 	We just got SpeakUP into the kernel and may soon be getting 
> support from other kernel developers to support serial ports properly 
> from kernelspace, and you want to ditch it all and go back to 
> prehistoric SpeakUP and scratching at fleas.
> 
> 	You people disgust me.
> 
> 				Michael
> 
> --
> Linux User:	177869 # Powered By: Intel # http://rivensight.dyndns.org
>           Postings Copyrighted 2010-2011 by: Michael Ferranti
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: speakup in user space (was Re: Serial conflict)

[Steve Holmes]

I've always preferred the kernel-based solution and find it to be so
responsive and fast and I remember the days of early access to deal
with kernel panics and similar stuff.  The forced fsck's that come up
from time to time also can be tracked earlier with speakup in the
kernel with good hardware support.  I do miss that when using software
speech.  I understand the advantages of user-space solutions and I
always thought a combination could really give a super experience.
Have basic support in the kernel and have user space stuff to provide
for things like keyboard-macros, flexible speak windows and stuff.  I
really wish we could fix the serial support stuff as that was a
land-mark feature of speakup in the past.  The fact that it is
basically broken on most machines is particularly disturbing.  Why it
works on some machines and not others, really bugs me!

I wish I had the expertese to help here.

On Fri, Mar 04, 2011 at 12:54:15PM -0800, Jacob Schmude wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi
> I don't think that's a limitation of the VCSA devices themselves, but
> rather how they are used. These devices show the screen as it
> currently is at any given time, although documentation for them is
> rather sparse. But couldn't we, rather than querying the device,
> monitor it instead for incoming text? I'll do some digging and see
> what I can find out.
> It just seems that to have speakup in the kernel even after removing
> serial support would leave us with all of the problems with none of
> the advantages remaining.
> 
> 
> 
> On 03/04/2011 10:52 AM, William Hubbs wrote:
> > On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> Hi If that were done, why have Speakup in the kernel at all?
> >> Software speech cannot be included in the kernel itself, and this
> >> would mean that hardware speech would not be able to kick in as
> >> early if needed. Also, we would then be under the limitations of
> >> user-space programs in that when a kernel panic happens, we may
> >> not be able to review it whether we're using hardware
> >> synthesizers or not. If we were to go this route, my suggestion
> >> would be to get Speakup out of the kernel entirely and convert
> >> the whole thing to user-space. I'd use an approach similar to
> >> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything
> >> more than if serial support were removed, and the integration
> >> problems with various distributions would be completely gone. No
> >> kernel conflicts, no module versioning, none of that. It would
> >> also remove the necessity for middleware between speakup and
> >> software speech.
> >
> > SBL uses the vcsa devices. I attempted to use this screen reader,
> > but I found very quickly that it doesn't work the way we expect
> > screen readers to work. For example, if you type the date command,
> > the next thing you hear read back to you is the command prompt. You
> > are required to use the screen review mode to find the output from
> > the command and read it. As I understand it, this is a limitation
> > of the vcsa devices.
> >
> > The closest thing as I understand it to a user space screen reader
> > that really works is yasr, but you have to be logged in to use
> > that.
> >
> > William
> >
> > _______________________________________________ Speakup mailing
> > list Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJNcVF1AAoJEDtK6CrF/Uo1Lk0H/i6q5fKxDiCYLo3dNO9djAtT
> aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M
> fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1
> MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo
> Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO
> v1xj2oKZOCUBEIjlZhLXYOdyOPPmLLLpwKSfFHDICwMcTeNAxVbg1bDSOWiETlw=
> =zJ6i
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: speakup in user space (was Re: Serial conflict)

[Kyle]

Just my $0.02, unless things have changed recently, Speakup needs much 
better USB support. Speaking from the perspective of having a machine 
that doesn't have a serial port, and more and more machines are built 
that way now, USB is certainly the way to go. In the very near future, 
this will be entirely necessary, as motherboards with serial ports are 
becoming harder and harder to find, and most available plug-in serial 
ports are USB adapters.
~Kyle

Re: speakup in user space (was Re: Serial conflict)

[Jason White]

Jacob Schmude  <speakup@braille.uwo.ca> wrote:
>I don't think that's a limitation of the VCSA devices themselves, but
>rather how they are used. These devices show the screen as it
>currently is at any given time, although documentation for them is
>rather sparse. But couldn't we, rather than querying the device,
>monitor it instead for incoming text? I'll do some digging and see
>what I can find out.

Even if the VCSA devices have such a limitation, you could propose changes to
overcome it, or write a relatively simple kernel module just to expose the
necessary information and implement the screen reader itself in user space.
>It just seems that to have speakup in the kernel even after removing
>serial support would leave us with all of the problems with none of
>the advantages remaining.

As I understand the situation, keystrokes can be intercepted from user space
as well now; support for this was integrated into BRLTTY relatively recently.

If I were designing a screen reader for Linux, I wouldn't put it in the kernel
unless there were really no workable alternative. If I had to touch the
kernel, it would be by way of a minimal driver just to provide the necessary
interfaces.

Re: speakup in user space (was Re: Serial conflict)

[Ari Moisio]

Hi

I   have made a screen reader that almost relies  on the /dev/vcsa 
devices. There are also options to read everything that an application 
spits out to stdout but only application i have found this useful is teh 
bc calculator.

There is also a  mode to read  changing content on the screen but it's not 
very usefull either, only when monitoring slowly changin status pages.

This screen reader works completely in the user space and will start 
after use has logged in.

Application will capture keyboard input and application output bu starting 
a new shel and tapping to it's stdin  and stdout. Not very elegant 
solutions but it works for me.

The source code is awful mess  and both comment in the code are in 
finnish:-(



-- 
mr. M01510 & guide Loadstone-GPS
hkp://wwwkeys.pgp.net B784D020
0C1F 6A76 DC9D DD58 3383 8B5D 0E76 9600  B784 D02

On Fri, 4 Mar 2011, Jacob Schmude wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
> I don't think that's a limitation of the VCSA devices themselves, but
> rather how they are used. These devices show the screen as it
> currently is at any given time, although documentation for them is
> rather sparse. But couldn't we, rather than querying the device,
> monitor it instead for incoming text? I'll do some digging and see
> what I can find out.
> It just seems that to have speakup in the kernel even after removing
> serial support would leave us with all of the problems with none of
> the advantages remaining.
>
>
>
> On 03/04/2011 10:52 AM, William Hubbs wrote:
>> On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi If that were done, why have Speakup in the kernel at all?
>>> Software speech cannot be included in the kernel itself, and this
>>> would mean that hardware speech would not be able to kick in as
>>> early if needed. Also, we would then be under the limitations of
>>> user-space programs in that when a kernel panic happens, we may
>>> not be able to review it whether we're using hardware
>>> synthesizers or not. If we were to go this route, my suggestion
>>> would be to get Speakup out of the kernel entirely and convert
>>> the whole thing to user-space. I'd use an approach similar to
>>> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything
>>> more than if serial support were removed, and the integration
>>> problems with various distributions would be completely gone. No
>>> kernel conflicts, no module versioning, none of that. It would
>>> also remove the necessity for middleware between speakup and
>>> software speech.
>>
>> SBL uses the vcsa devices. I attempted to use this screen reader,
>> but I found very quickly that it doesn't work the way we expect
>> screen readers to work. For example, if you type the date command,
>> the next thing you hear read back to you is the command prompt. You
>> are required to use the screen review mode to find the output from
>> the command and read it. As I understand it, this is a limitation
>> of the vcsa devices.
>>
>> The closest thing as I understand it to a user space screen reader
>> that really works is yasr, but you have to be logged in to use
>> that.
>>
>> William
>>
>> _______________________________________________ Speakup mailing
>> list Speakup@braille.uwo.ca
>> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJNcVF1AAoJEDtK6CrF/Uo1Lk0H/i6q5fKxDiCYLo3dNO9djAtT
> aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M
> fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1
> MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo
> Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO
> v1xj2oKZOCUBEIjlZhLXYOdyOPPmLLLpwKSfFHDICwMcTeNAxVbg1bDSOWiETlw=
> =zJ6i
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: speakup in user space (was Re: Serial conflict)

[Jason White]

Just one point of clarification here:
Jason White  <speakup@braille.uwo.ca> wrote:

>If I were designing a screen reader for Linux, I wouldn't put it in the kernel
>unless there were really no workable alternative. If I had to touch the
>kernel, it would be by way of a minimal driver just to provide the necessary
>interfaces.

The above isn't meant as a criticism of the Speakup design, which may have
been the best of the available options when it was decided upon. My point,
rather, is that in today's environment there are very limited benefits to be
obtained from implementing the entire screen reader in the kernel. If your
kernel panics and you have a serial synthesizer, then there's an added
benefit, provided that Speakup is still running after the crash. Linux
supports other means of reporting kernel panics, kexec, serial cosnole,
network console, and so on. Thus I'm not convinced of the importance of this
particular scenario. Speakup can theoretically start very early in the boot
process, but the advantage really only accrues if it is compiled into the
kernel image. If it's a module, then you'll need the initrd image to be loaded
before it starts, as will be the case in just about every distribution these
days. In that circumstance, however, you can just as easily load a user-space
screen reader in the initrd image.

Hardware-based speech synthesizers are undoubtedly on the way out, and have
been so for at least a decade, quite aside from the issues associated with
serial port access that have given rise to this discussion.

I'm an outsider to the Speakup "community", and not really qualified to assess
all of the alternatives.

>From my perspective, this will head in either of two possible directions.

1. Speakup developers will write kernel code to access the kernel's support
for serial devices (including serial to USB converters) to solve the hardware
synthesizer problem; likewise, support will be provided for synthesizers with
USB interfaces. I don't know whether there is likely to be pressure from the
kernel community suggesting that the whole project should be in user-space and
hence it should not be accepted into the mainline. I'm not making this
argument, just suggesting that it could be raised when the time comes to move
Speakup out of staging and into the kernel proper. This could be a barrier to
final merging, depending on the criteria applied in making that decision.

2. Alternatively, a decision will be taken to move the entire implementation,
or most of it, into user space, possibly leaving behind a small kernel module
if the existing interfaces don't provide everything that is needed. Obviously
there'll be plenty of code rewriting involved if this option is taken up.

I suppose part of the question to be considered is: how hard would it be to
pursue option 1, and is that really the best way to proceed over the long
term? One could argue that there's a marginal advantage in certain corner
cases of a kernel-based implementation and that there's a solution here which
works now, and which, moreover, has done so since the late 90s. On the other
hand, an implementation in user-space can't bring down your entire system in
the same way that a kernel module can, all of the device support provided by
the kernel is available via /dev through interfaces that will continue to be
supported; there's the possibility of supporting some of the user-space
terminal emulators (such as that used by the Debian installer) if a suitable
API is created; working with user-space speech servers etc., is
straightforward; the implementation of the screen reader may be less complex,
etc.

Ultimately it's the developers of Speakup who will collectively decide how
it evolves from here.