Help with serial synths in 4.X kernels

Help with serial synths in 4.X kernels

[Tony Baechler]

Hello all,

This is probably for Samuel, but I thought I would ask here in hopes that 
others might have suggestions. I'm trying to compile 4.X kernels 
(specifically 4.3.3) with working serial synth support, but so far no luck. 
I've seen several patches posted here by Samuel, but I don't know if they've 
been accepted into staging. I pulled a recent staging snapshot and copied 
the speakup directory over that supplied with kernel 4.3.3 in Debian. The 
kernel didn't compile, giving an error that screen_pos is undefined. I 
copied main.c from the 4.3.3 source which fixes the problem, but loading the 
speakup_dectlk module results in silence. It seems that it still won't 
access the serial port, even if I include ser=0 on the command line. I also 
tried applying John's patch to the vanilla 4.3.3 sources. Again, it 
compiled, but loading speakup_dectlk locked up the machine. I tried 
4.4.0-trunk-amd64 from Debian without success.

Is there a diff with all of the Speakup patches posted to date which I can 
apply to the kernel sources? Is there any chance that Debian will pick up 
these patches soon since they apparently haven't made it to the official 
staging tree? Am I missing something obvious? Samuel, would you please post 
a file with all of your patches so far in a central location to make them 
easier to find?

For the record, John's build instructions don't work on recent kernels. I've 
found that the following steps seem to work better:

1. Install the "linux-source" and "make-kpkg" packages.

2. Change to /usr/src/ which should have a tar.bz2 or tar.xz file with the 
source. Extract the source which should create a linux-source-X.Y.Z directory.

3. Change to linux-source-X.Y.Z.

4. As root or with sudo, run the following:

make-kpkg --initrd buildpackage

Note that on Ubuntu, you'll run into problems with .config missing. Debian 
packages don't seem to have this problem, but to be safe, copy a config.* 
file to .config in the linux-source directory. Apply any Speakup patches 
before running make-kpkg. On an Intel I7 with 32 GB of memory, the build 
process takes about three hours and builds several .deb packages.


-- 
Tony Baechler, founder, Baechler Access Technology Services
Putting accessibility at the forefront of technology
mailto:bats@batsupport.com
Phone: 1-619-746-8310  SMS text: 1-619-375-2545

Re: Help with serial synths in 4.X kernels

[John G Heim]

You should check the syslog. There are almost certainly messages in 
there reporting what is happening. I'll try to compile 4.3 kernels for 
ubuntu and debian over the next few days. I had planned to automate the 
process. Every time my ubuntu machines download a new kernel, generate a 
new patched kernel package. I never got around to it though. I was using 
a sed command to comment out the line that caused serial synths to not 
work so that automation was possible. Part of the problem here is that I 
have kind of given up on serial synths myself. I have been depending 
more and more on the combination of a braille display and software 
speech.  It seems to me that using a hardware speech synth is going 
against the grain these days.
02/23/2016 07:45 AM, Tony Baechler wrote:
> Hello all,
>
> his is probably for Samuel, but I thought I would ask here in hopes 
> that others might have suggestions. I'm trying to compile 4.X kernels 
> (specifically 4.3.3) with working serial synth support, but so far no 
> luck. I've seen several patches posted here by Samuel, but I don't 
> know if they've been accepted into staging. I pulled a recent staging 
> snapshot and copied the speakup directory over that supplied with 
> kernel 4.3.3 in Debian. The kernel didn't compile, giving an error 
> that screen_pos is undefined. I copied main.c from the 4.3.3 source 
> which fixes the problem, but loading the speakup_dectlk module results 
> in silence. It seems that it still won't access the serial port, even 
> if I include ser=0 on the command line. I also tried applying John's 
> patch to the vanilla 4.3.3 sources. Again, it compiled, but loading 
> speakup_dectlk locked up the machine. I tried 4.4.0-trunk-amd64 from 
> Debian without success.
>
> Is there a diff with all of the Speakup patches posted to date which I 
> can apply to the kernel sources? Is there any chance that Debian will 
> pick up these patches soon since they apparently haven't made it to 
> the official staging tree? Am I missing something obvious? Samuel, 
> would you please post a file with all of your patches so far in a 
> central location to make them easier to find?
>
> For the record, John's build instructions don't work on recent 
> kernels. I've found that the following steps seem to work better:
>
> 1. Install the "linux-source" and "make-kpkg" packages.
>
> 2. Change to /usr/src/ which should have a tar.bz2 or tar.xz file with 
> the source. Extract the source which should create a 
> linux-source-X.Y.Z directory.
>
> 3. Change to linux-source-X.Y.Z.
>
> 4. As root or with sudo, run the following:
>
> make-kpkg --initrd buildpackage
>
> Note that on Ubuntu, you'll run into problems with .config missing. 
> Debian packages don't seem to have this problem, but to be safe, copy 
> a config.* file to .config in the linux-source directory. Apply any 
> Speakup patches before running make-kpkg. On an Intel I7 with 32 GB of 
> memory, the build process takes about three hours and builds several 
> .deb packages.
>
>

Re: Help with serial synths in 4.X kernels

[covici]

Do you have the serialio.c patched to comment out the return null in
around line 42?  I am running successfully using 4.1.15 kernel, I have
not checked the 4.3 series as I want to run lts ones only.

Tony Baechler <tony@baechler.net> wrote:

> Hello all,
> 
> This is probably for Samuel, but I thought I would ask here in hopes
> that others might have suggestions. I'm trying to compile 4.X kernels
> (specifically 4.3.3) with working serial synth support, but so far no
> luck. I've seen several patches posted here by Samuel, but I don't
> know if they've been accepted into staging. I pulled a recent staging
> snapshot and copied the speakup directory over that supplied with
> kernel 4.3.3 in Debian. The kernel didn't compile, giving an error
> that screen_pos is undefined. I copied main.c from the 4.3.3 source
> which fixes the problem, but loading the speakup_dectlk module results
> in silence. It seems that it still won't access the serial port, even
> if I include ser=0 on the command line. I also tried applying John's
> patch to the vanilla 4.3.3 sources. Again, it compiled, but loading
> speakup_dectlk locked up the machine. I tried 4.4.0-trunk-amd64 from
> Debian without success.
> 
> Is there a diff with all of the Speakup patches posted to date which I
> can apply to the kernel sources? Is there any chance that Debian will
> pick up these patches soon since they apparently haven't made it to
> the official staging tree? Am I missing something obvious? Samuel,
> would you please post a file with all of your patches so far in a
> central location to make them easier to find?
> 
> For the record, John's build instructions don't work on recent
> kernels. I've found that the following steps seem to work better:
> 
> 1. Install the "linux-source" and "make-kpkg" packages.
> 
> 2. Change to /usr/src/ which should have a tar.bz2 or tar.xz file with
> the source. Extract the source which should create a
> linux-source-X.Y.Z directory.
> 
> 3. Change to linux-source-X.Y.Z.
> 
> 4. As root or with sudo, run the following:
> 
> make-kpkg --initrd buildpackage
> 
> Note that on Ubuntu, you'll run into problems with .config
> missing. Debian packages don't seem to have this problem, but to be
> safe, copy a config.* file to .config in the linux-source
> directory. Apply any Speakup patches before running make-kpkg. On an
> Intel I7 with 32 GB of memory, the build process takes about three
> hours and builds several .deb packages.
> 
> 
> -- 
> Tony Baechler, founder, Baechler Access Technology Services
> Putting accessibility at the forefront of technology
> mailto:bats@batsupport.com
> Phone: 1-619-746-8310  SMS text: 1-619-375-2545
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[Al Sten-Clanton]

Using a hardware synth may be going against the grain, but I'll be 
mighty grateful for the patch if you have the chance to create it.

Best!

Al

On 2/23/2016 9:31 AM, John G Heim wrote:
> You should check the syslog. There are almost certainly messages in
> there reporting what is happening. I'll try to compile 4.3 kernels for
> ubuntu and debian over the next few days. I had planned to automate the
> process. Every time my ubuntu machines download a new kernel, generate a
> new patched kernel package. I never got around to it though. I was using
> a sed command to comment out the line that caused serial synths to not
> work so that automation was possible. Part of the problem here is that I
> have kind of given up on serial synths myself. I have been depending
> more and more on the combination of a braille display and software
> speech.  It seems to me that using a hardware speech synth is going
> against the grain these days.
> 02/23/2016 07:45 AM, Tony Baechler wrote:
>> Hello all,
>>
>> his is probably for Samuel, but I thought I would ask here in hopes
>> that others might have suggestions. I'm trying to compile 4.X kernels
>> (specifically 4.3.3) with working serial synth support, but so far no
>> luck. I've seen several patches posted here by Samuel, but I don't
>> know if they've been accepted into staging. I pulled a recent staging
>> snapshot and copied the speakup directory over that supplied with
>> kernel 4.3.3 in Debian. The kernel didn't compile, giving an error
>> that screen_pos is undefined. I copied main.c from the 4.3.3 source
>> which fixes the problem, but loading the speakup_dectlk module results
>> in silence. It seems that it still won't access the serial port, even
>> if I include ser=0 on the command line. I also tried applying John's
>> patch to the vanilla 4.3.3 sources. Again, it compiled, but loading
>> speakup_dectlk locked up the machine. I tried 4.4.0-trunk-amd64 from
>> Debian without success.
>>
>> Is there a diff with all of the Speakup patches posted to date which I
>> can apply to the kernel sources? Is there any chance that Debian will
>> pick up these patches soon since they apparently haven't made it to
>> the official staging tree? Am I missing something obvious? Samuel,
>> would you please post a file with all of your patches so far in a
>> central location to make them easier to find?
>>
>> For the record, John's build instructions don't work on recent
>> kernels. I've found that the following steps seem to work better:
>>
>> 1. Install the "linux-source" and "make-kpkg" packages.
>>
>> 2. Change to /usr/src/ which should have a tar.bz2 or tar.xz file with
>> the source. Extract the source which should create a
>> linux-source-X.Y.Z directory.
>>
>> 3. Change to linux-source-X.Y.Z.
>>
>> 4. As root or with sudo, run the following:
>>
>> make-kpkg --initrd buildpackage
>>
>> Note that on Ubuntu, you'll run into problems with .config missing.
>> Debian packages don't seem to have this problem, but to be safe, copy
>> a config.* file to .config in the linux-source directory. Apply any
>> Speakup patches before running make-kpkg. On an Intel I7 with 32 GB of
>> memory, the build process takes about three hours and builds several
>> .deb packages.
>>
>>
>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

Re: Help with serial synths in 4.X kernels

[Tony Baechler]

First, 4.3 is considered stable which is why I picked it. We're already up 
to 4.3.3 which fixes bugs in earlier 4.3.X releases. Second, I'm not sure 
which patch you mean, but if you're referring to John's patch on his build 
instructions page which modifies serialio.c, yes, I applied it first to the 
vanilla sources and it locked up the machine. I didn't apply it after 
backporting the latest Speakup source from the staging tree because I didn't 
think it was necessary. I think some of Samuel's patches didn't get 
accepted, thus leaving serial synth support still broken.

On 2/23/2016 7:05 AM, covici@ccs.covici.com wrote:
> Do you have the serialio.c patched to comment out the return null in
> around line 42?  I am running successfully using 4.1.15 kernel, I have
> not checked the 4.3 series as I want to run lts ones only.

Re: Help with serial synths in 4.X kernels

[covici]

First, 4.3 is not lts according to the kernel.org webpage.

The patch I mean is the one I described, this has nothing to do with
building packages, I am talking about modifying serialio.c to comment
out the return NULL statement.  I don't build any packages, I just
compile myself.

Tony Baechler <tony@baechler.net> wrote:

> First, 4.3 is considered stable which is why I picked it. We're
> already up to 4.3.3 which fixes bugs in earlier 4.3.X
> releases. Second, I'm not sure which patch you mean, but if you're
> referring to John's patch on his build instructions page which
> modifies serialio.c, yes, I applied it first to the vanilla sources
> and it locked up the machine. I didn't apply it after backporting the
> latest Speakup source from the staging tree because I didn't think it
> was necessary. I think some of Samuel's patches didn't get accepted,
> thus leaving serial synth support still broken.
> 
> On 2/23/2016 7:05 AM, covici@ccs.covici.com wrote:
> > Do you have the serialio.c patched to comment out the return null in
> > around line 42?  I am running successfully using 4.1.15 kernel, I have
> > not checked the 4.3 series as I want to run lts ones only.
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[Tony Baechler]

On 2/23/2016 6:31 AM, John G Heim wrote:
> You should check the syslog. There are almost certainly messages in there
> reporting what is happening. I'll try to compile 4.3 kernels for ubuntu and
> debian over the next few days. I had planned to automate the process. Every
> time my ubuntu machines download a new kernel, generate a new patched kernel
> package. I never got around to it though. I was using a sed command to
> comment out the line that caused serial synths to not work so that
> automation was possible. Part of the problem here is that I have kind of
> given up on serial synths myself. I have been depending more and more on the
> combination of a braille display and software speech.  It seems to me that
> using a hardware speech synth is going against the grain these days.


As Karen and others have pointed out, we all have our own personal speech 
preferences. In my case, I have multiple reasons for wanting serial speech 
to work. I find it easier to hear and understand for one thing. There are 
some bugs in the DECtalk Express module which might be easily fixed, but the 
last unpatched kernel I know of that actually worked was 2.6.32 which is no 
longer supported. Anyway, as requested, here is the dmesg output. I don't 
see anything helpful. I did the following:

service espeakup stop
rmmod speakup_soft
modprobe speakup_dectlk
rmmod speakup_dectlk
rmmod speakup
modprobe speakup_soft
espeakup

[   11.336314] r8169 0000:02:00.0 eth0: link up
[   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   27.013903] releasing synth soft
[   27.013975] unregistered /dev/softsynth
[   32.824006] speakup: unregistering synth device /dev/synth
[   56.630004] speakup: module is from the staging directory, the quality is 
unknown, you have been warned.
[   56.630896] input: Speakup as /devices/virtual/input/input7
[   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
[   56.631055] speakup 3.1.6: initialized
[   56.631057] synth name on entry is: dectlk
[   56.639855] speakup_dectlk: module is from the staging directory, the 
quality is unknown, you have been warned.
[   56.640036] synth probe
[   56.640039] Ports not available, trying to steal them
[   56.640042] Unable to allocate port at 3f8, errno -16
[   56.640044] Dectalk Express: not found
[   56.640045] dectlk: device probe failed
[   67.012005] speakup: unregistering synth device /dev/synth
[   70.985966] speakup: module is from the staging directory, the quality is 
unknown, you have been warned.
[   70.986851] input: Speakup as /devices/virtual/input/input8
[   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
[   70.987006] speakup 3.1.6: initialized
[   70.987008] synth name on entry is: dectlk
[   70.987055] speakup_soft: module is from the staging directory, the 
quality is unknown, you have been warned.
[   70.987193] synth probe
[   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, MINOR 26)

Re: Help with serial synths in 4.X kernels

[covici]

Your output indicates you don't have the return null commented out, this
is why you are not getting speech.

Tony Baechler <tony@baechler.net> wrote:

> On 2/23/2016 6:31 AM, John G Heim wrote:
> > You should check the syslog. There are almost certainly messages in there
> > reporting what is happening. I'll try to compile 4.3 kernels for ubuntu and
> > debian over the next few days. I had planned to automate the process. Every
> > time my ubuntu machines download a new kernel, generate a new patched kernel
> > package. I never got around to it though. I was using a sed command to
> > comment out the line that caused serial synths to not work so that
> > automation was possible. Part of the problem here is that I have kind of
> > given up on serial synths myself. I have been depending more and more on the
> > combination of a braille display and software speech.  It seems to me that
> > using a hardware speech synth is going against the grain these days.
> 
> 
> As Karen and others have pointed out, we all have our own personal
> speech preferences. In my case, I have multiple reasons for wanting
> serial speech to work. I find it easier to hear and understand for one
> thing. There are some bugs in the DECtalk Express module which might
> be easily fixed, but the last unpatched kernel I know of that actually
> worked was 2.6.32 which is no longer supported. Anyway, as requested,
> here is the dmesg output. I don't see anything helpful. I did the
> following:
> 
> service espeakup stop
> rmmod speakup_soft
> modprobe speakup_dectlk
> rmmod speakup_dectlk
> rmmod speakup
> modprobe speakup_soft
> espeakup
> 
> [   11.336314] r8169 0000:02:00.0 eth0: link up
> [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   27.013903] releasing synth soft
> [   27.013975] unregistered /dev/softsynth
> [   32.824006] speakup: unregistering synth device /dev/synth
> [   56.630004] speakup: module is from the staging directory, the
> quality is unknown, you have been warned.
> [   56.630896] input: Speakup as /devices/virtual/input/input7
> [   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
> [   56.631055] speakup 3.1.6: initialized
> [   56.631057] synth name on entry is: dectlk
> [   56.639855] speakup_dectlk: module is from the staging directory,
> the quality is unknown, you have been warned.
> [   56.640036] synth probe
> [   56.640039] Ports not available, trying to steal them
> [   56.640042] Unable to allocate port at 3f8, errno -16
> [   56.640044] Dectalk Express: not found
> [   56.640045] dectlk: device probe failed
> [   67.012005] speakup: unregistering synth device /dev/synth
> [   70.985966] speakup: module is from the staging directory, the
> quality is unknown, you have been warned.
> [   70.986851] input: Speakup as /devices/virtual/input/input8
> [   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
> [   70.987006] speakup 3.1.6: initialized
> [   70.987008] synth name on entry is: dectlk
> [   70.987055] speakup_soft: module is from the staging directory, the
> quality is unknown, you have been warned.
> [   70.987193] synth probe
> [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, MINOR 26)
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[John G Heim]

Well, first of all, I didn't mean to say you shouldn't use a serial 
hardware synth. However,IMO, you would be wise to consider contingency 
plans. If your livelihood depends on that serial synth, you'd be wise to 
begin examining your alternatives.

Also, I can't promise to debug the kernel code. When I said check the 
syslog, I meant for you to check the syslog. If I can find the time to 
take a look at it, I certainly will but I can't promise that. I suspect 
that what's happening is that when speakup tries to "steal" the serial 
port, the return value is no longer just null. When I last traced back 
the functions that speakup was calling to steal the serial port, it was 
bullstuff. Speakup called a function that did nothing -- which isn't the 
fault of the speakup developers. I suspect that those functions now do 
something -- probably not what we want but something.

It has probably been a year since I last posted a rant on this list 
about the linux kernel developers. As I write this, I find myself 
getting all worked up about it again. The one good thing about Trump 
running for President is that now I have someone I find more arrogant 
and irritating than the linux kernel development team.



On 02/24/2016 08:29 AM, Tony Baechler wrote:
> On 2/23/2016 6:31 AM, John G Heim wrote:
>> You should check the syslog. There are almost certainly messages in 
>> there
>> reporting what is happening. I'll try to compile 4.3 kernels for 
>> ubuntu and
>> debian over the next few days. I had planned to automate the process. 
>> Every
>> time my ubuntu machines download a new kernel, generate a new patched 
>> kernel
>> package. I never got around to it though. I was using a sed command to
>> comment out the line that caused serial synths to not work so that
>> automation was possible. Part of the problem here is that I have kind of
>> given up on serial synths myself. I have been depending more and more 
>> on the
>> combination of a braille display and software speech.  It seems to me 
>> that
>> using a hardware speech synth is going against the grain these days.
>
>
> As Karen and others have pointed out, we all have our own personal 
> speech preferences. In my case, I have multiple reasons for wanting 
> serial speech to work. I find it easier to hear and understand for one 
> thing. There are some bugs in the DECtalk Express module which might 
> be easily fixed, but the last unpatched kernel I know of that actually 
> worked was 2.6.32 which is no longer supported. Anyway, as requested, 
> here is the dmesg output. I don't see anything helpful. I did the 
> following:
>
> service espeakup stop
> rmmod speakup_soft
> modprobe speakup_dectlk
> rmmod speakup_dectlk
> rmmod speakup
> modprobe speakup_soft
> espeakup
>
> [   11.336314] r8169 0000:02:00.0 eth0: link up
> [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   27.013903] releasing synth soft
> [   27.013975] unregistered /dev/softsynth
> [   32.824006] speakup: unregistering synth device /dev/synth
> [   56.630004] speakup: module is from the staging directory, the 
> quality is unknown, you have been warned.
> [   56.630896] input: Speakup as /devices/virtual/input/input7
> [   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
> [   56.631055] speakup 3.1.6: initialized
> [   56.631057] synth name on entry is: dectlk
> [   56.639855] speakup_dectlk: module is from the staging directory, 
> the quality is unknown, you have been warned.
> [   56.640036] synth probe
> [   56.640039] Ports not available, trying to steal them
> [   56.640042] Unable to allocate port at 3f8, errno -16
> [   56.640044] Dectalk Express: not found
> [   56.640045] dectlk: device probe failed
> [   67.012005] speakup: unregistering synth device /dev/synth
> [   70.985966] speakup: module is from the staging directory, the 
> quality is unknown, you have been warned.
> [   70.986851] input: Speakup as /devices/virtual/input/input8
> [   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
> [   70.987006] speakup 3.1.6: initialized
> [   70.987008] synth name on entry is: dectlk
> [   70.987055] speakup_soft: module is from the staging directory, the 
> quality is unknown, you have been warned.
> [   70.987193] synth probe
> [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, 
> MINOR 26)

Re: Help with serial synths in 4.X kernels

[covici]

So as a temporary workaround for this, I just comment out the return
null statement when speakup can't steal the port back, and so we have
speech.  We can't reload another module in this case, but we do have
speech.

John G Heim <jheim@math.wisc.edu> wrote:

> Well, first of all, I didn't mean to say you shouldn't use a serial
> hardware synth. However,IMO, you would be wise to consider contingency
> plans. If your livelihood depends on that serial synth, you'd be wise
> to begin examining your alternatives.
> 
> Also, I can't promise to debug the kernel code. When I said check the
> syslog, I meant for you to check the syslog. If I can find the time to
> take a look at it, I certainly will but I can't promise that. I
> suspect that what's happening is that when speakup tries to "steal"
> the serial port, the return value is no longer just null. When I last
> traced back the functions that speakup was calling to steal the serial
> port, it was bullstuff. Speakup called a function that did nothing --
> which isn't the fault of the speakup developers. I suspect that those
> functions now do something -- probably not what we want but something.
> 
> It has probably been a year since I last posted a rant on this list
> about the linux kernel developers. As I write this, I find myself
> getting all worked up about it again. The one good thing about Trump
> running for President is that now I have someone I find more arrogant
> and irritating than the linux kernel development team.
> 
> 
> 
> On 02/24/2016 08:29 AM, Tony Baechler wrote:
> > On 2/23/2016 6:31 AM, John G Heim wrote:
> >> You should check the syslog. There are almost certainly messages in
> >> there
> >> reporting what is happening. I'll try to compile 4.3 kernels for
> >> ubuntu and
> >> debian over the next few days. I had planned to automate the
> >> process. Every
> >> time my ubuntu machines download a new kernel, generate a new
> >> patched kernel
> >> package. I never got around to it though. I was using a sed command to
> >> comment out the line that caused serial synths to not work so that
> >> automation was possible. Part of the problem here is that I have kind of
> >> given up on serial synths myself. I have been depending more and
> >> more on the
> >> combination of a braille display and software speech.  It seems to
> >> me that
> >> using a hardware speech synth is going against the grain these days.
> >
> >
> > As Karen and others have pointed out, we all have our own personal
> > speech preferences. In my case, I have multiple reasons for wanting
> > serial speech to work. I find it easier to hear and understand for
> > one thing. There are some bugs in the DECtalk Express module which
> > might be easily fixed, but the last unpatched kernel I know of that
> > actually worked was 2.6.32 which is no longer supported. Anyway, as
> > requested, here is the dmesg output. I don't see anything helpful. I
> > did the following:
> >
> > service espeakup stop
> > rmmod speakup_soft
> > modprobe speakup_dectlk
> > rmmod speakup_dectlk
> > rmmod speakup
> > modprobe speakup_soft
> > espeakup
> >
> > [   11.336314] r8169 0000:02:00.0 eth0: link up
> > [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > [   27.013903] releasing synth soft
> > [   27.013975] unregistered /dev/softsynth
> > [   32.824006] speakup: unregistering synth device /dev/synth
> > [   56.630004] speakup: module is from the staging directory, the
> > quality is unknown, you have been warned.
> > [   56.630896] input: Speakup as /devices/virtual/input/input7
> > [   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
> > [   56.631055] speakup 3.1.6: initialized
> > [   56.631057] synth name on entry is: dectlk
> > [   56.639855] speakup_dectlk: module is from the staging directory,
> > the quality is unknown, you have been warned.
> > [   56.640036] synth probe
> > [   56.640039] Ports not available, trying to steal them
> > [   56.640042] Unable to allocate port at 3f8, errno -16
> > [   56.640044] Dectalk Express: not found
> > [   56.640045] dectlk: device probe failed
> > [   67.012005] speakup: unregistering synth device /dev/synth
> > [   70.985966] speakup: module is from the staging directory, the
> > quality is unknown, you have been warned.
> > [   70.986851] input: Speakup as /devices/virtual/input/input8
> > [   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
> > [   70.987006] speakup 3.1.6: initialized
> > [   70.987008] synth name on entry is: dectlk
> > [   70.987055] speakup_soft: module is from the staging directory,
> > the quality is unknown, you have been warned.
> > [   70.987193] synth probe
> > [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10,
> > MINOR 26)
> 
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[Karen Lewellen]

May i ask how one finds contingency plans for your ears, your brain, and your 
processing? smiles.
I am not following this debate closely, but it certainly supports  my 
worries about Linux as a main computing solution.  If someone is going to 
remove the door to functionality, or decide for me how I personally 
accommodate my body differences, then they are no different than say 
Microsoft.
Access is a human right in some places,  not a feature.
defining that access begins and ends with the individual, which is why the 
best access uses a foundation allowing for many ways  in so to speak.

Going back to the corner now,
Kare


On Wed, 24 Feb 2016, John G Heim wrote:

> Well, first of all, I didn't mean to say you shouldn't use a serial hardware 
> synth. However,IMO, you would be wise to consider contingency plans. If your 
> livelihood depends on that serial synth, you'd be wise to begin examining 
> your alternatives.
>
> Also, I can't promise to debug the kernel code. When I said check the syslog, 
> I meant for you to check the syslog. If I can find the time to take a look at 
> it, I certainly will but I can't promise that. I suspect that what's 
> happening is that when speakup tries to "steal" the serial port, the return 
> value is no longer just null. When I last traced back the functions that 
> speakup was calling to steal the serial port, it was bullstuff. Speakup 
> called a function that did nothing -- which isn't the fault of the speakup 
> developers. I suspect that those functions now do something -- probably not 
> what we want but something.
>
> It has probably been a year since I last posted a rant on this list about the 
> linux kernel developers. As I write this, I find myself getting all worked up 
> about it again. The one good thing about Trump running for President is that 
> now I have someone I find more arrogant and irritating than the linux kernel 
> development team.
>
>
>
> On 02/24/2016 08:29 AM, Tony Baechler wrote:
>> On 2/23/2016 6:31 AM, John G Heim wrote:
>> >  You should check the syslog. There are almost certainly messages in 
>> >  there
>> >  reporting what is happening. I'll try to compile 4.3 kernels for ubuntu 
>> >  and
>> >  debian over the next few days. I had planned to automate the process. 
>> >  Every
>> >  time my ubuntu machines download a new kernel, generate a new patched 
>> >  kernel
>> >  package. I never got around to it though. I was using a sed command to
>> >  comment out the line that caused serial synths to not work so that
>> >  automation was possible. Part of the problem here is that I have kind of
>> >  given up on serial synths myself. I have been depending more and more on 
>> >  the
>> >  combination of a braille display and software speech.  It seems to me 
>> >  that
>> >  using a hardware speech synth is going against the grain these days.
>> 
>>
>>  As Karen and others have pointed out, we all have our own personal speech
>>  preferences. In my case, I have multiple reasons for wanting serial speech
>>  to work. I find it easier to hear and understand for one thing. There are
>>  some bugs in the DECtalk Express module which might be easily fixed, but
>>  the last unpatched kernel I know of that actually worked was 2.6.32 which
>>  is no longer supported. Anyway, as requested, here is the dmesg output. I
>>  don't see anything helpful. I did the following:
>>
>>  service espeakup stop
>>  rmmod speakup_soft
>>  modprobe speakup_dectlk
>>  rmmod speakup_dectlk
>>  rmmod speakup
>>  modprobe speakup_soft
>>  espeakup
>>
>>  [   11.336314] r8169 0000:02:00.0 eth0: link up
>>  [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>  [   27.013903] releasing synth soft
>>  [   27.013975] unregistered /dev/softsynth
>>  [   32.824006] speakup: unregistering synth device /dev/synth
>>  [   56.630004] speakup: module is from the staging directory, the quality
>>  is unknown, you have been warned.
>>  [   56.630896] input: Speakup as /devices/virtual/input/input7
>>  [   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
>>  [   56.631055] speakup 3.1.6: initialized
>>  [   56.631057] synth name on entry is: dectlk
>>  [   56.639855] speakup_dectlk: module is from the staging directory, the
>>  quality is unknown, you have been warned.
>>  [   56.640036] synth probe
>>  [   56.640039] Ports not available, trying to steal them
>>  [   56.640042] Unable to allocate port at 3f8, errno -16
>>  [   56.640044] Dectalk Express: not found
>>  [   56.640045] dectlk: device probe failed
>>  [   67.012005] speakup: unregistering synth device /dev/synth
>>  [   70.985966] speakup: module is from the staging directory, the quality
>>  is unknown, you have been warned.
>>  [   70.986851] input: Speakup as /devices/virtual/input/input8
>>  [   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
>>  [   70.987006] speakup 3.1.6: initialized
>>  [   70.987008] synth name on entry is: dectlk
>>  [   70.987055] speakup_soft: module is from the staging directory, the
>>  quality is unknown, you have been warned.
>>  [   70.987193] synth probe
>>  [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, MINOR
>>  26)
>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>
>

Re: Help with serial synths in 4.X kernels

[John G Heim]

Well, as I said, I've been relying more and more upon a braille display 
and software speech.

I can't say it's unfair to say linux is no better than Microsoft because 
I think in this context, it's comparing apples and oranges. IMO, it's 
neiher  fair or unfair. It's like saying a dolphin is no better than an 
oak tree. Well, at what? If you want linux to do something, you have to 
do it yourself or maybe pay someone to do it for you.
On the other hand, I would say that developers are ethically required to 
allow accessibility software to work with their code and the linux 
kernel developers have been woefully inadequate in that regard. A year 
or two ago, I took the time to drill down through the functions the 
speakup code was calling to "steal" the serial port. I found it led to a 
function inside the main kernel code (not in staging) that could never 
return a success. I asked about it on the kernel developers list. If 
speakup isn't accessing the serial port the right way, what is the right 
way? The answers I got were BS. The speakup code is not very well 
written, the whole thing should be moved to user space, etc. My reaction 
was like, okay, maybe, but can someone please answer the question? But 
apparently not. It was infuriating. That's when I started posting 
kernels with the function call commented out.

The whole thing just makes no sense. Why even include code that is 
deliberately disabled? Samuel is probably freaking out if he has read 
this far. Someone, probably him, went through a lot of work just to get 
speakup in staging. And, after all, software speech does work. That is 
not trivial.

On 02/24/2016 10:05 AM, Karen Lewellen wrote:
> May i ask how one finds contingency plans for your ears, your brain, 
> and your processing? smiles.
> I am not following this debate closely, but it certainly supports my 
> worries about Linux as a main computing solution.  If someone is going 
> to remove the door to functionality, or decide for me how I personally 
> accommodate my body differences, then they are no different than say 
> Microsoft.
> Access is a human right in some places,  not a feature.
> defining that access begins and ends with the individual, which is why 
> the best access uses a foundation allowing for many ways  in so to speak.
>
> Going back to the corner now,
> Kare
>
>
> On Wed, 24 Feb 2016, John G Heim wrote:
>
>> Well, first of all, I didn't mean to say you shouldn't use a serial 
>> hardware synth. However,IMO, you would be wise to consider 
>> contingency plans. If your livelihood depends on that serial synth, 
>> you'd be wise to begin examining your alternatives.
>>
>> Also, I can't promise to debug the kernel code. When I said check the 
>> syslog, I meant for you to check the syslog. If I can find the time 
>> to take a look at it, I certainly will but I can't promise that. I 
>> suspect that what's happening is that when speakup tries to "steal" 
>> the serial port, the return value is no longer just null. When I last 
>> traced back the functions that speakup was calling to steal the 
>> serial port, it was bullstuff. Speakup called a function that did 
>> nothing -- which isn't the fault of the speakup developers. I suspect 
>> that those functions now do something -- probably not what we want 
>> but something.
>>
>> It has probably been a year since I last posted a rant on this list 
>> about the linux kernel developers. As I write this, I find myself 
>> getting all worked up about it again. The one good thing about Trump 
>> running for President is that now I have someone I find more arrogant 
>> and irritating than the linux kernel development team.
>>
>>
>>
>> On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>> On 2/23/2016 6:31 AM, John G Heim wrote:
>>> >  You should check the syslog. There are almost certainly messages 
>>> in >  there
>>> >  reporting what is happening. I'll try to compile 4.3 kernels for 
>>> ubuntu >  and
>>> >  debian over the next few days. I had planned to automate the 
>>> process. >  Every
>>> >  time my ubuntu machines download a new kernel, generate a new 
>>> patched >  kernel
>>> >  package. I never got around to it though. I was using a sed 
>>> command to
>>> >  comment out the line that caused serial synths to not work so that
>>> >  automation was possible. Part of the problem here is that I have 
>>> kind of
>>> >  given up on serial synths myself. I have been depending more and 
>>> more on >  the
>>> >  combination of a braille display and software speech. It seems to 
>>> me >  that
>>> >  using a hardware speech synth is going against the grain these days.
>>>
>>>
>>>  As Karen and others have pointed out, we all have our own personal 
>>> speech
>>>  preferences. In my case, I have multiple reasons for wanting serial 
>>> speech
>>>  to work. I find it easier to hear and understand for one thing. 
>>> There are
>>>  some bugs in the DECtalk Express module which might be easily 
>>> fixed, but
>>>  the last unpatched kernel I know of that actually worked was 2.6.32 
>>> which
>>>  is no longer supported. Anyway, as requested, here is the dmesg 
>>> output. I
>>>  don't see anything helpful. I did the following:
>>>
>>>  service espeakup stop
>>>  rmmod speakup_soft
>>>  modprobe speakup_dectlk
>>>  rmmod speakup_dectlk
>>>  rmmod speakup
>>>  modprobe speakup_soft
>>>  espeakup
>>>
>>>  [   11.336314] r8169 0000:02:00.0 eth0: link up
>>>  [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>  [   27.013903] releasing synth soft
>>>  [   27.013975] unregistered /dev/softsynth
>>>  [   32.824006] speakup: unregistering synth device /dev/synth
>>>  [   56.630004] speakup: module is from the staging directory, the 
>>> quality
>>>  is unknown, you have been warned.
>>>  [   56.630896] input: Speakup as /devices/virtual/input/input7
>>>  [   56.631031] initialized device: /dev/synth, node (MAJOR 10, 
>>> MINOR 25)
>>>  [   56.631055] speakup 3.1.6: initialized
>>>  [   56.631057] synth name on entry is: dectlk
>>>  [   56.639855] speakup_dectlk: module is from the staging 
>>> directory, the
>>>  quality is unknown, you have been warned.
>>>  [   56.640036] synth probe
>>>  [   56.640039] Ports not available, trying to steal them
>>>  [   56.640042] Unable to allocate port at 3f8, errno -16
>>>  [   56.640044] Dectalk Express: not found
>>>  [   56.640045] dectlk: device probe failed
>>>  [   67.012005] speakup: unregistering synth device /dev/synth
>>>  [   70.985966] speakup: module is from the staging directory, the 
>>> quality
>>>  is unknown, you have been warned.
>>>  [   70.986851] input: Speakup as /devices/virtual/input/input8
>>>  [   70.986983] initialized device: /dev/synth, node (MAJOR 10, 
>>> MINOR 25)
>>>  [   70.987006] speakup 3.1.6: initialized
>>>  [   70.987008] synth name on entry is: dectlk
>>>  [   70.987055] speakup_soft: module is from the staging directory, the
>>>  quality is unknown, you have been warned.
>>>  [   70.987193] synth probe
>>>  [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, 
>>> MINOR
>>>  26)
>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>
>>

Re: Help with serial synths in 4.X kernels

[covici]

I got a more definite answer from someone  in kernel development -- I
cannot remember who -- but he said that the serial driver should be
written like a hardware device driver and obey all the appropriate
protocols thereof, so if we can figure out, say, how the uart driver
registers the port and have the speakup driver do the exact same thing,
maybe this would work much better.

John G Heim <jheim@math.wisc.edu> wrote:

> Well, as I said, I've been relying more and more upon a braille
> display and software speech.
> 
> I can't say it's unfair to say linux is no better than Microsoft
> because I think in this context, it's comparing apples and
> oranges. IMO, it's neiher  fair or unfair. It's like saying a dolphin
> is no better than an oak tree. Well, at what? If you want linux to do
> something, you have to do it yourself or maybe pay someone to do it
> for you.
> On the other hand, I would say that developers are ethically required
> to allow accessibility software to work with their code and the linux
> kernel developers have been woefully inadequate in that regard. A year
> or two ago, I took the time to drill down through the functions the
> speakup code was calling to "steal" the serial port. I found it led to
> a function inside the main kernel code (not in staging) that could
> never return a success. I asked about it on the kernel developers
> list. If speakup isn't accessing the serial port the right way, what
> is the right way? The answers I got were BS. The speakup code is not
> very well written, the whole thing should be moved to user space,
> etc. My reaction was like, okay, maybe, but can someone please answer
> the question? But apparently not. It was infuriating. That's when I
> started posting kernels with the function call commented out.
> 
> The whole thing just makes no sense. Why even include code that is
> deliberately disabled? Samuel is probably freaking out if he has read
> this far. Someone, probably him, went through a lot of work just to
> get speakup in staging. And, after all, software speech does
> work. That is not trivial.
> 
> On 02/24/2016 10:05 AM, Karen Lewellen wrote:
> > May i ask how one finds contingency plans for your ears, your brain,
> > and your processing? smiles.
> > I am not following this debate closely, but it certainly supports my
> > worries about Linux as a main computing solution.  If someone is
> > going to remove the door to functionality, or decide for me how I
> > personally accommodate my body differences, then they are no
> > different than say Microsoft.
> > Access is a human right in some places,  not a feature.
> > defining that access begins and ends with the individual, which is
> > why the best access uses a foundation allowing for many ways  in so
> > to speak.
> >
> > Going back to the corner now,
> > Kare
> >
> >
> > On Wed, 24 Feb 2016, John G Heim wrote:
> >
> >> Well, first of all, I didn't mean to say you shouldn't use a serial
> >> hardware synth. However,IMO, you would be wise to consider
> >> contingency plans. If your livelihood depends on that serial synth,
> >> you'd be wise to begin examining your alternatives.
> >>
> >> Also, I can't promise to debug the kernel code. When I said check
> >> the syslog, I meant for you to check the syslog. If I can find the
> >> time to take a look at it, I certainly will but I can't promise
> >> that. I suspect that what's happening is that when speakup tries to
> >> "steal" the serial port, the return value is no longer just
> >> null. When I last traced back the functions that speakup was
> >> calling to steal the serial port, it was bullstuff. Speakup called
> >> a function that did nothing -- which isn't the fault of the speakup
> >> developers. I suspect that those functions now do something --
> >> probably not what we want but something.
> >>
> >> It has probably been a year since I last posted a rant on this list
> >> about the linux kernel developers. As I write this, I find myself
> >> getting all worked up about it again. The one good thing about
> >> Trump running for President is that now I have someone I find more
> >> arrogant and irritating than the linux kernel development team.
> >>
> >>
> >>
> >> On 02/24/2016 08:29 AM, Tony Baechler wrote:
> >>> On 2/23/2016 6:31 AM, John G Heim wrote:
> >>> >  You should check the syslog. There are almost certainly
> >>> messages in >  there
> >>> >  reporting what is happening. I'll try to compile 4.3 kernels
> >>> for ubuntu >  and
> >>> >  debian over the next few days. I had planned to automate the
> >>> process. >  Every
> >>> >  time my ubuntu machines download a new kernel, generate a new
> >>> patched >  kernel
> >>> >  package. I never got around to it though. I was using a sed
> >>> command to
> >>> >  comment out the line that caused serial synths to not work so that
> >>> >  automation was possible. Part of the problem here is that I
> >>> have kind of
> >>> >  given up on serial synths myself. I have been depending more
> >>> and more on >  the
> >>> >  combination of a braille display and software speech. It seems
> >>> to me >  that
> >>> >  using a hardware speech synth is going against the grain these days.
> >>>
> >>>
> >>>  As Karen and others have pointed out, we all have our own
> >>> personal speech
> >>>  preferences. In my case, I have multiple reasons for wanting
> >>> serial speech
> >>>  to work. I find it easier to hear and understand for one
> >>> thing. There are
> >>>  some bugs in the DECtalk Express module which might be easily
> >>> fixed, but
> >>>  the last unpatched kernel I know of that actually worked was
> >>> 2.6.32 which
> >>>  is no longer supported. Anyway, as requested, here is the dmesg
> >>> output. I
> >>>  don't see anything helpful. I did the following:
> >>>
> >>>  service espeakup stop
> >>>  rmmod speakup_soft
> >>>  modprobe speakup_dectlk
> >>>  rmmod speakup_dectlk
> >>>  rmmod speakup
> >>>  modprobe speakup_soft
> >>>  espeakup
> >>>
> >>>  [   11.336314] r8169 0000:02:00.0 eth0: link up
> >>>  [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>>  [   27.013903] releasing synth soft
> >>>  [   27.013975] unregistered /dev/softsynth
> >>>  [   32.824006] speakup: unregistering synth device /dev/synth
> >>>  [   56.630004] speakup: module is from the staging directory, the
> >>> quality
> >>>  is unknown, you have been warned.
> >>>  [   56.630896] input: Speakup as /devices/virtual/input/input7
> >>>  [   56.631031] initialized device: /dev/synth, node (MAJOR 10,
> >>> MINOR 25)
> >>>  [   56.631055] speakup 3.1.6: initialized
> >>>  [   56.631057] synth name on entry is: dectlk
> >>>  [   56.639855] speakup_dectlk: module is from the staging
> >>> directory, the
> >>>  quality is unknown, you have been warned.
> >>>  [   56.640036] synth probe
> >>>  [   56.640039] Ports not available, trying to steal them
> >>>  [   56.640042] Unable to allocate port at 3f8, errno -16
> >>>  [   56.640044] Dectalk Express: not found
> >>>  [   56.640045] dectlk: device probe failed
> >>>  [   67.012005] speakup: unregistering synth device /dev/synth
> >>>  [   70.985966] speakup: module is from the staging directory, the
> >>> quality
> >>>  is unknown, you have been warned.
> >>>  [   70.986851] input: Speakup as /devices/virtual/input/input8
> >>>  [   70.986983] initialized device: /dev/synth, node (MAJOR 10,
> >>> MINOR 25)
> >>>  [   70.987006] speakup 3.1.6: initialized
> >>>  [   70.987008] synth name on entry is: dectlk
> >>>  [   70.987055] speakup_soft: module is from the staging directory, the
> >>>  quality is unknown, you have been warned.
> >>>  [   70.987193] synth probe
> >>>  [   70.987230] initialized device: /dev/softsynth, node (MAJOR
> >>> 10, MINOR
> >>>  26)
> >>
> >> _______________________________________________
> >> Speakup mailing list
> >> Speakup@linux-speakup.org
> >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>
> >>
> 
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[Karen Lewellen]

I respect that you feel your stance and your work is important.  I agree 
on 
Samuel, he has given a grand deal, providing much talent to this effort 
as well.
However, speaking only for myself, I do not find  the suggestion that what 
you are using applies to anyone else    making  a great  deal of 
sense...there is only one of you.
Speaking only for myself, I am amazed how these projects have come 
together 
forgetting the most fundamental thing about the people using them.
You are talking of humans, millions of them, and all humans learn 
differently.  You are using a braille display and software speech.  that 
is 
fine, but what if the person using the screen reader is doing so because 
they have a learning disability instead?
a large percentage  of the population that  can benefit from speech. 
what if they are in the sight loss 
majority, not braille users, or have no access to a display....costly  are 
they not?    what if 
they, as  I know  can be the case, find software speech impossible to hear 
and understand?
What if they are managing a combination of print challenges?  I can go on 
and on. 
Believe me i resonate with the challenges of getting a good answer out of 
the  larger  Linux community...I have been  working on a really functional 
Linux box for a good decade or more at least.
Still there are some who hold Linux out as a better alternative to say 
using other low graphics options, like DOS...and you indicate here that 
the suggestion may not be reasonable, unless you are willing and able to 
build the house yourself.    You  must be a programmer before you 
can fully  have the program.  I cannot say this is necessary using dos for 
sure.
I can say, speaking only for myself though that thinking everyone sharing 
a label with you is just like you prevents talent from being used for a 
greater and flexible solution across low graphics platforms.
Or even more graphical ones for that matter.
I grant you my Microsoft comparison may not be fair.  Save the same kind 
of arrogance you found in the Linux community has been mirrored  in the 
windows one on many occasions.
I sincerely wish you success  finding a real solution.  Tony as well.
However, if anyone starts to wonder why  I personally will choose ssh 
TELNET into any Linux structure from outside, I can point to this entire 
thread, smiles.
Thanks for engaging with me,
Karen


On Wed, 24 Feb 2016, John G Heim wrote:

> Well, as I said, I've been relying more and more upon a braille display and 
> software speech.
>
> I can't say it's unfair to say linux is no better than Microsoft because I 
> think in this context, it's comparing apples and oranges. IMO, it's neiher 
> fair or unfair. It's like saying a dolphin is no better than an oak tree. 
> Well, at what? If you want linux to do something, you have to do it yourself 
> or maybe pay someone to do it for you.
> On the other hand, I would say that developers are ethically required to 
> allow accessibility software to work with their code and the linux kernel 
> developers have been woefully inadequate in that regard. A year or two ago, I 
> took the time to drill down through the functions the speakup code was 
> calling to "steal" the serial port. I found it led to a function inside the 
> main kernel code (not in staging) that could never return a success. I asked 
> about it on the kernel developers list. If speakup isn't accessing the serial 
> port the right way, what is the right way? The answers I got were BS. The 
> speakup code is not very well written, the whole thing should be moved to 
> user space, etc. My reaction was like, okay, maybe, but can someone please 
> answer the question? But apparently not. It was infuriating. That's when I 
> started posting kernels with the function call commented out.
>
> The whole thing just makes no sense. Why even include code that is 
> deliberately disabled? Samuel is probably freaking out if he has read this 
> far. Someone, probably him, went through a lot of work just to get speakup in 
> staging. And, after all, software speech does work. That is not trivial.
>
> On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>>  May i ask how one finds contingency plans for your ears, your brain, and
>>  your processing? smiles.
>>  I am not following this debate closely, but it certainly supports my
>>  worries about Linux as a main computing solution.  If someone is going to
>>  remove the door to functionality, or decide for me how I personally
>>  accommodate my body differences, then they are no different than say
>>  Microsoft.
>>  Access is a human right in some places,  not a feature.
>>  defining that access begins and ends with the individual, which is why the
>>  best access uses a foundation allowing for many ways  in so to speak.
>>
>>  Going back to the corner now,
>>  Kare
>> 
>>
>>  On Wed, 24 Feb 2016, John G Heim wrote:
>> 
>> >  Well, first of all, I didn't mean to say you shouldn't use a serial 
>> >  hardware synth. However,IMO, you would be wise to consider contingency 
>> >  plans. If your livelihood depends on that serial synth, you'd be wise to 
>> >  begin examining your alternatives.
>> > 
>> >  Also, I can't promise to debug the kernel code. When I said check the 
>> >  syslog, I meant for you to check the syslog. If I can find the time to 
>> >  take a look at it, I certainly will but I can't promise that. I suspect 
>> >  that what's happening is that when speakup tries to "steal" the serial 
>> >  port, the return value is no longer just null. When I last traced back 
>> >  the functions that speakup was calling to steal the serial port, it was 
>> >  bullstuff. Speakup called a function that did nothing -- which isn't the 
>> >  fault of the speakup developers. I suspect that those functions now do 
>> >  something -- probably not what we want but something.
>> > 
>> >  It has probably been a year since I last posted a rant on this list 
>> >  about the linux kernel developers. As I write this, I find myself 
>> >  getting all worked up about it again. The one good thing about Trump 
>> >  running for President is that now I have someone I find more arrogant 
>> >  and irritating than the linux kernel development team.
>> > 
>> > 
>> > 
>> >  On 02/24/2016 08:29 AM, Tony Baechler wrote:
>> > >  On 2/23/2016 6:31 AM, John G Heim wrote:
>> > > >   You should check the syslog. There are almost certainly messages 
>> > > in >   there
>> > > >   reporting what is happening. I'll try to compile 4.3 kernels for 
>> > > ubuntu >   and
>> > > >   debian over the next few days. I had planned to automate the 
>> > >  process. >  Every
>> > > >   time my ubuntu machines download a new kernel, generate a new 
>> > > patched >   kernel
>> > > >   package. I never got around to it though. I was using a sed 
>> > >  command to
>> > > >   comment out the line that caused serial synths to not work so that
>> > > >   automation was possible. Part of the problem here is that I have 
>> > >  kind of
>> > > >   given up on serial synths myself. I have been depending more and 
>> > >  more on >  the
>> > > >   combination of a braille display and software speech. It seems to 
>> > > me >   that
>> > > >   using a hardware speech synth is going against the grain these 
>> > > >   days.
>> > > 
>> > > 
>> > >  As Karen and others have pointed out, we all have our own personal 
>> > >  speech
>> > >  preferences. In my case, I have multiple reasons for wanting serial 
>> > >  speech
>> > >  to work. I find it easier to hear and understand for one thing. There 
>> > >  are
>> > >  some bugs in the DECtalk Express module which might be easily fixed, 
>> > >  but
>> > >  the last unpatched kernel I know of that actually worked was 2.6.32 
>> > >  which
>> > >  is no longer supported. Anyway, as requested, here is the dmesg 
>> > >  output. I
>> > >   don't see anything helpful. I did the following:
>> > > 
>> > >   service espeakup stop
>> > >   rmmod speakup_soft
>> > >   modprobe speakup_dectlk
>> > >   rmmod speakup_dectlk
>> > >   rmmod speakup
>> > >   modprobe speakup_soft
>> > >   espeakup
>> > > 
>> > >   [   11.336314] r8169 0000:02:00.0 eth0: link up
>> > >   [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes 
>> > >   ready
>> > >   [   27.013903] releasing synth soft
>> > >   [   27.013975] unregistered /dev/softsynth
>> > >   [   32.824006] speakup: unregistering synth device /dev/synth
>> > >   [   56.630004] speakup: module is from the staging directory, the 
>> > >  quality
>> > >   is unknown, you have been warned.
>> > >   [   56.630896] input: Speakup as /devices/virtual/input/input7
>> > >   [   56.631031] initialized device: /dev/synth, node (MAJOR 10, 
>> > >  MINOR 25)
>> > >   [   56.631055] speakup 3.1.6: initialized
>> > >   [   56.631057] synth name on entry is: dectlk
>> > >   [   56.639855] speakup_dectlk: module is from the staging 
>> > >  directory, the
>> > >   quality is unknown, you have been warned.
>> > >   [   56.640036] synth probe
>> > >   [   56.640039] Ports not available, trying to steal them
>> > >   [   56.640042] Unable to allocate port at 3f8, errno -16
>> > >   [   56.640044] Dectalk Express: not found
>> > >   [   56.640045] dectlk: device probe failed
>> > >   [   67.012005] speakup: unregistering synth device /dev/synth
>> > >   [   70.985966] speakup: module is from the staging directory, the 
>> > >  quality
>> > >   is unknown, you have been warned.
>> > >   [   70.986851] input: Speakup as /devices/virtual/input/input8
>> > >   [   70.986983] initialized device: /dev/synth, node (MAJOR 10, 
>> > >  MINOR 25)
>> > >   [   70.987006] speakup 3.1.6: initialized
>> > >   [   70.987008] synth name on entry is: dectlk
>> > >   [   70.987055] speakup_soft: module is from the staging directory, 
>> > >   the
>> > >   quality is unknown, you have been warned.
>> > >   [   70.987193] synth probe
>> > >   [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, 
>> > >  MINOR
>> > >   26)
>> > 
>> >  _______________________________________________
>> >  Speakup mailing list
>> >  Speakup@linux-speakup.org
>> >  http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>> > 
>> > 
>
>
>

Re: Help with serial synths in 4.X kernels

[John G Heim]

Karen, suggesting one workaround for the problems with serial synths in 
speakup does not imply that I am forgetting the basic needs of my fellow 
human beings. That's ridiculous. Nothing I said implies in any way that 
getting your hands on a braille display is a solution that works for 
everyone.

Maybe the concept of open source is unclear but the truth is that you, 
Karen, are as responsible as anyone on this list for the speakup code. 
Why don't you rewrite it yourself? If you say you can't do that, would 
it be fair for me to accuse you of losing track of the basic needs of 
your fellow humans?



On 02/24/2016 12:05 PM, Karen Lewellen wrote:
> I respect that you feel your stance and your work is important.  I 
> agree on Samuel, he has given a grand deal, providing much talent to 
> this effort as well.
> However, speaking only for myself, I do not find  the suggestion that 
> what you are using applies to anyone else    making  a great deal of 
> sense...there is only one of you.
> Speaking only for myself, I am amazed how these projects have come 
> together forgetting the most fundamental thing about the people using 
> them.
> You are talking of humans, millions of them, and all humans learn 
> differently.  You are using a braille display and software speech.  
> that is fine, but what if the person using the screen reader is doing 
> so because they have a learning disability instead?
> a large percentage  of the population that  can benefit from speech. 
> what if they are in the sight loss majority, not braille users, or 
> have no access to a display....costly  are they not? what if they, as  
> I know  can be the case, find software speech impossible to hear and 
> understand?
> What if they are managing a combination of print challenges?  I can go 
> on and on. Believe me i resonate with the challenges of getting a good 
> answer out of the  larger  Linux community...I have been  working on a 
> really functional Linux box for a good decade or more at least.
> Still there are some who hold Linux out as a better alternative to say 
> using other low graphics options, like DOS...and you indicate here 
> that the suggestion may not be reasonable, unless you are willing and 
> able to build the house yourself.    You  must be a programmer before 
> you can fully  have the program.  I cannot say this is necessary using 
> dos for sure.
> I can say, speaking only for myself though that thinking everyone 
> sharing a label with you is just like you prevents talent from being 
> used for a greater and flexible solution across low graphics platforms.
> Or even more graphical ones for that matter.
> I grant you my Microsoft comparison may not be fair.  Save the same 
> kind of arrogance you found in the Linux community has been mirrored  
> in the windows one on many occasions.
> I sincerely wish you success  finding a real solution.  Tony as well.
> However, if anyone starts to wonder why  I personally will choose ssh 
> TELNET into any Linux structure from outside, I can point to this 
> entire thread, smiles.
> Thanks for engaging with me,
> Karen
>
>
> On Wed, 24 Feb 2016, John G Heim wrote:
>
>> Well, as I said, I've been relying more and more upon a braille 
>> display and software speech.
>>
>> I can't say it's unfair to say linux is no better than Microsoft 
>> because I think in this context, it's comparing apples and oranges. 
>> IMO, it's neiher fair or unfair. It's like saying a dolphin is no 
>> better than an oak tree. Well, at what? If you want linux to do 
>> something, you have to do it yourself or maybe pay someone to do it 
>> for you.
>> On the other hand, I would say that developers are ethically required 
>> to allow accessibility software to work with their code and the linux 
>> kernel developers have been woefully inadequate in that regard. A 
>> year or two ago, I took the time to drill down through the functions 
>> the speakup code was calling to "steal" the serial port. I found it 
>> led to a function inside the main kernel code (not in staging) that 
>> could never return a success. I asked about it on the kernel 
>> developers list. If speakup isn't accessing the serial port the right 
>> way, what is the right way? The answers I got were BS. The speakup 
>> code is not very well written, the whole thing should be moved to 
>> user space, etc. My reaction was like, okay, maybe, but can someone 
>> please answer the question? But apparently not. It was infuriating. 
>> That's when I started posting kernels with the function call 
>> commented out.
>>
>> The whole thing just makes no sense. Why even include code that is 
>> deliberately disabled? Samuel is probably freaking out if he has read 
>> this far. Someone, probably him, went through a lot of work just to 
>> get speakup in staging. And, after all, software speech does work. 
>> That is not trivial.
>>
>> On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>>>  May i ask how one finds contingency plans for your ears, your 
>>> brain, and
>>>  your processing? smiles.
>>>  I am not following this debate closely, but it certainly supports my
>>>  worries about Linux as a main computing solution.  If someone is 
>>> going to
>>>  remove the door to functionality, or decide for me how I personally
>>>  accommodate my body differences, then they are no different than say
>>>  Microsoft.
>>>  Access is a human right in some places,  not a feature.
>>>  defining that access begins and ends with the individual, which is 
>>> why the
>>>  best access uses a foundation allowing for many ways  in so to speak.
>>>
>>>  Going back to the corner now,
>>>  Kare
>>>
>>>
>>>  On Wed, 24 Feb 2016, John G Heim wrote:
>>>
>>> >  Well, first of all, I didn't mean to say you shouldn't use a 
>>> serial >  hardware synth. However,IMO, you would be wise to consider 
>>> contingency >  plans. If your livelihood depends on that serial 
>>> synth, you'd be wise to >  begin examining your alternatives.
>>> > >  Also, I can't promise to debug the kernel code. When I said 
>>> check the >  syslog, I meant for you to check the syslog. If I can 
>>> find the time to >  take a look at it, I certainly will but I can't 
>>> promise that. I suspect > that what's happening is that when speakup 
>>> tries to "steal" the serial >  port, the return value is no longer 
>>> just null. When I last traced back >  the functions that speakup was 
>>> calling to steal the serial port, it was >  bullstuff. Speakup 
>>> called a function that did nothing -- which isn't the >  fault of 
>>> the speakup developers. I suspect that those functions now do >  
>>> something -- probably not what we want but something.
>>> > >  It has probably been a year since I last posted a rant on this 
>>> list >  about the linux kernel developers. As I write this, I find 
>>> myself >  getting all worked up about it again. The one good thing 
>>> about Trump >  running for President is that now I have someone I 
>>> find more arrogant >  and irritating than the linux kernel 
>>> development team.
>>> > > > >  On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>> > >  On 2/23/2016 6:31 AM, John G Heim wrote:
>>> > > >   You should check the syslog. There are almost certainly 
>>> messages > > in >   there
>>> > > >   reporting what is happening. I'll try to compile 4.3 kernels 
>>> for > > ubuntu >   and
>>> > > >   debian over the next few days. I had planned to automate the 
>>> > >  process. >  Every
>>> > > >   time my ubuntu machines download a new kernel, generate a 
>>> new > > patched >   kernel
>>> > > >   package. I never got around to it though. I was using a sed 
>>> > >  command to
>>> > > >   comment out the line that caused serial synths to not work 
>>> so that
>>> > > >   automation was possible. Part of the problem here is that I 
>>> have > >  kind of
>>> > > >   given up on serial synths myself. I have been depending more 
>>> and > >  more on >  the
>>> > > >   combination of a braille display and software speech. It 
>>> seems to > > me >   that
>>> > > >   using a hardware speech synth is going against the grain 
>>> these > > >   days.
>>> > > > > > >  As Karen and others have pointed out, we all have our 
>>> own personal > >  speech
>>> > >  preferences. In my case, I have multiple reasons for wanting 
>>> serial > >  speech
>>> > >  to work. I find it easier to hear and understand for one thing. 
>>> There > >  are
>>> > >  some bugs in the DECtalk Express module which might be easily 
>>> fixed, > >  but
>>> > >  the last unpatched kernel I know of that actually worked was 
>>> 2.6.32 > >  which
>>> > >  is no longer supported. Anyway, as requested, here is the dmesg 
>>> > >  output. I
>>> > >   don't see anything helpful. I did the following:
>>> > > > >   service espeakup stop
>>> > >   rmmod speakup_soft
>>> > >   modprobe speakup_dectlk
>>> > >   rmmod speakup_dectlk
>>> > >   rmmod speakup
>>> > >   modprobe speakup_soft
>>> > >   espeakup
>>> > > > >   [   11.336314] r8169 0000:02:00.0 eth0: link up
>>> > >   [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link 
>>> becomes > >   ready
>>> > >   [   27.013903] releasing synth soft
>>> > >   [   27.013975] unregistered /dev/softsynth
>>> > >   [   32.824006] speakup: unregistering synth device /dev/synth
>>> > >   [   56.630004] speakup: module is from the staging directory, 
>>> the > >  quality
>>> > >   is unknown, you have been warned.
>>> > >   [   56.630896] input: Speakup as /devices/virtual/input/input7
>>> > >   [   56.631031] initialized device: /dev/synth, node (MAJOR 10, 
>>> > >  MINOR 25)
>>> > >   [   56.631055] speakup 3.1.6: initialized
>>> > >   [   56.631057] synth name on entry is: dectlk
>>> > >   [   56.639855] speakup_dectlk: module is from the staging > >  
>>> directory, the
>>> > >   quality is unknown, you have been warned.
>>> > >   [   56.640036] synth probe
>>> > >   [   56.640039] Ports not available, trying to steal them
>>> > >   [   56.640042] Unable to allocate port at 3f8, errno -16
>>> > >   [   56.640044] Dectalk Express: not found
>>> > >   [   56.640045] dectlk: device probe failed
>>> > >   [   67.012005] speakup: unregistering synth device /dev/synth
>>> > >   [   70.985966] speakup: module is from the staging directory, 
>>> the > >  quality
>>> > >   is unknown, you have been warned.
>>> > >   [   70.986851] input: Speakup as /devices/virtual/input/input8
>>> > >   [   70.986983] initialized device: /dev/synth, node (MAJOR 10, 
>>> > >  MINOR 25)
>>> > >   [   70.987006] speakup 3.1.6: initialized
>>> > >   [   70.987008] synth name on entry is: dectlk
>>> > >   [   70.987055] speakup_soft: module is from the staging 
>>> directory, > >   the
>>> > >   quality is unknown, you have been warned.
>>> > >   [   70.987193] synth probe
>>> > >   [   70.987230] initialized device: /dev/softsynth, node (MAJOR 
>>> 10, > >  MINOR
>>> > >   26)
>>> > >  _______________________________________________
>>> >  Speakup mailing list
>>> >  Speakup@linux-speakup.org
>>> > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>> > > 
>>
>>
>>

Re: Help with serial synths in 4.X kernels

[Karen Lewellen]

I made no such accusation.
I stated that speaking only for myself, I am  surprised how such projects 
come  together without considering the variations in how individuals 
learn, access, and use technologies.
You suggested that others should make contingency plans, assuming that such 
plans were a possibility, otherwise why would you suggest as much.
I am not sure why I am responsible for a code, just because I occupy 
a list.  does that make me responsible for Google's access choices, or 
Apples, just because I am a list member?
Why does my presence on a list make me responsible for the content of the 
speakup code?


On Wed, 24 Feb 2016, John G Heim wrote:

> Karen, suggesting one workaround for the problems with serial synths in 
> speakup does not imply that I am forgetting the basic needs of my fellow 
> human beings. That's ridiculous. Nothing I said implies in any way that 
> getting your hands on a braille display is a solution that works for 
> everyone.
>
> Maybe the concept of open source is unclear but the truth is that you, Karen, 
> are as responsible as anyone on this list for the speakup code. Why don't you 
> rewrite it yourself? If you say you can't do that, would it be fair for me to 
> accuse you of losing track of the basic needs of your fellow humans?
>
>
>
> On 02/24/2016 12:05 PM, Karen Lewellen wrote:
>>  I respect that you feel your stance and your work is important.  I agree
>>  on Samuel, he has given a grand deal, providing much talent to this effort
>>  as well.
>>  However, speaking only for myself, I do not find  the suggestion that what
>>  you are using applies to anyone else    making  a great deal of
>>  sense...there is only one of you.
>>  Speaking only for myself, I am amazed how these projects have come
>>  together forgetting the most fundamental thing about the people using
>>  them.
>>  You are talking of humans, millions of them, and all humans learn
>>  differently.  You are using a braille display and software speech.  that
>>  is fine, but what if the person using the screen reader is doing so
>>  because they have a learning disability instead?
>>  a large percentage  of the population that  can benefit from speech. what
>>  if they are in the sight loss majority, not braille users, or have no
>>  access to a display....costly  are they not? what if they, as  I know  can
>>  be the case, find software speech impossible to hear and understand?
>>  What if they are managing a combination of print challenges?  I can go on
>>  and on. Believe me i resonate with the challenges of getting a good answer
>>  out of the  larger  Linux community...I have been  working on a really
>>  functional Linux box for a good decade or more at least.
>>  Still there are some who hold Linux out as a better alternative to say
>>  using other low graphics options, like DOS...and you indicate here that
>>  the suggestion may not be reasonable, unless you are willing and able to
>>  build the house yourself.    You  must be a programmer before you can
>>  fully  have the program.  I cannot say this is necessary using dos for
>>  sure.
>>  I can say, speaking only for myself though that thinking everyone sharing
>>  a label with you is just like you prevents talent from being used for a
>>  greater and flexible solution across low graphics platforms.
>>  Or even more graphical ones for that matter.
>>  I grant you my Microsoft comparison may not be fair.  Save the same kind
>>  of arrogance you found in the Linux community has been mirrored  in the
>>  windows one on many occasions.
>>  I sincerely wish you success  finding a real solution.  Tony as well.
>>  However, if anyone starts to wonder why  I personally will choose ssh
>>  TELNET into any Linux structure from outside, I can point to this entire
>>  thread, smiles.
>>  Thanks for engaging with me,
>>  Karen
>> 
>>
>>  On Wed, 24 Feb 2016, John G Heim wrote:
>> 
>> >  Well, as I said, I've been relying more and more upon a braille display 
>> >  and software speech.
>> > 
>> >  I can't say it's unfair to say linux is no better than Microsoft because 
>> >  I think in this context, it's comparing apples and oranges. IMO, it's 
>> >  neiher fair or unfair. It's like saying a dolphin is no better than an 
>> >  oak tree. Well, at what? If you want linux to do something, you have to 
>> >  do it yourself or maybe pay someone to do it for you.
>> >  On the other hand, I would say that developers are ethically required to 
>> >  allow accessibility software to work with their code and the linux 
>> >  kernel developers have been woefully inadequate in that regard. A year 
>> >  or two ago, I took the time to drill down through the functions the 
>> >  speakup code was calling to "steal" the serial port. I found it led to a 
>> >  function inside the main kernel code (not in staging) that could never 
>> >  return a success. I asked about it on the kernel developers list. If 
>> >  speakup isn't accessing the serial port the right way, what is the right 
>> >  way? The answers I got were BS. The speakup code is not very well 
>> >  written, the whole thing should be moved to user space, etc. My reaction 
>> >  was like, okay, maybe, but can someone please answer the question? But 
>> >  apparently not. It was infuriating. That's when I started posting 
>> >  kernels with the function call commented out.
>> > 
>> >  The whole thing just makes no sense. Why even include code that is 
>> >  deliberately disabled? Samuel is probably freaking out if he has read 
>> >  this far. Someone, probably him, went through a lot of work just to get 
>> >  speakup in staging. And, after all, software speech does work. That is 
>> >  not trivial.
>> > 
>> >  On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>> > >  May i ask how one finds contingency plans for your ears, your brain, 
>> > >  and
>> > >   your processing? smiles.
>> > >   I am not following this debate closely, but it certainly supports my
>> > >   worries about Linux as a main computing solution.  If someone is 
>> > >  going to
>> > >   remove the door to functionality, or decide for me how I personally
>> > >   accommodate my body differences, then they are no different than say
>> > >   Microsoft.
>> > >   Access is a human right in some places,  not a feature.
>> > >   defining that access begins and ends with the individual, which is 
>> > >  why the
>> > >   best access uses a foundation allowing for many ways  in so to speak.
>> > > 
>> > >   Going back to the corner now,
>> > >   Kare
>> > > 
>> > > 
>> > >   On Wed, 24 Feb 2016, John G Heim wrote:
>> > > 
>> > > >   Well, first of all, I didn't mean to say you shouldn't use a 
>> > >  serial >  hardware synth. However,IMO, you would be wise to consider 
>> > >  contingency >  plans. If your livelihood depends on that serial synth, 
>> > >  you'd be wise to >  begin examining your alternatives.
>> > > > >   Also, I can't promise to debug the kernel code. When I said 
>> > >  check the >  syslog, I meant for you to check the syslog. If I can 
>> > >  find the time to >  take a look at it, I certainly will but I can't 
>> > >  promise that. I suspect > that what's happening is that when speakup 
>> > >  tries to "steal" the serial >  port, the return value is no longer 
>> > >  just null. When I last traced back >  the functions that speakup was 
>> > >  calling to steal the serial port, it was >  bullstuff. Speakup called 
>> > >  a function that did nothing -- which isn't the >  fault of the speakup 
>> > >  developers. I suspect that those functions now do >  something -- 
>> > >  probably not what we want but something.
>> > > > >   It has probably been a year since I last posted a rant on this 
>> > >  list >  about the linux kernel developers. As I write this, I find 
>> > >  myself >  getting all worked up about it again. The one good thing 
>> > >  about Trump >  running for President is that now I have someone I find 
>> > >  more arrogant >  and irritating than the linux kernel development 
>> > >  team.
>> > > > > > >   On 02/24/2016 08:29 AM, Tony Baechler wrote:
>> > > > >   On 2/23/2016 6:31 AM, John G Heim wrote:
>> > > > > >    You should check the syslog. There are almost certainly 
>> > > messages > > in >    there
>> > > > > >    reporting what is happening. I'll try to compile 4.3 kernels 
>> > > for > > ubuntu >    and
>> > > > > >    debian over the next few days. I had planned to automate the 
>> > > > >   process. >  Every
>> > > > > >    time my ubuntu machines download a new kernel, generate a 
>> > > new > > patched >    kernel
>> > > > > >    package. I never got around to it though. I was using a sed 
>> > > > >   command to
>> > > > > >    comment out the line that caused serial synths to not work 
>> > >  so that
>> > > > > >    automation was possible. Part of the problem here is that I 
>> > > have > >   kind of
>> > > > > >    given up on serial synths myself. I have been depending more 
>> > > and > >   more on >  the
>> > > > > >    combination of a braille display and software speech. It 
>> > >  seems to > > me >   that
>> > > > > >    using a hardware speech synth is going against the grain 
>> > > these > > >    days.
>> > > > > > > > >   As Karen and others have pointed out, we all have our 
>> > >  own personal > >  speech
>> > > > >   preferences. In my case, I have multiple reasons for wanting 
>> > > serial > >   speech
>> > > > >   to work. I find it easier to hear and understand for one thing. 
>> > > There > >   are
>> > > > >   some bugs in the DECtalk Express module which might be easily 
>> > >  fixed, > >  but
>> > > > >   the last unpatched kernel I know of that actually worked was 
>> > >  2.6.32 > >  which
>> > > > >   is no longer supported. Anyway, as requested, here is the dmesg 
>> > > > >   output. I
>> > > > >    don't see anything helpful. I did the following:
>> > > > > > >    service espeakup stop
>> > > > >    rmmod speakup_soft
>> > > > >    modprobe speakup_dectlk
>> > > > >    rmmod speakup_dectlk
>> > > > >    rmmod speakup
>> > > > >    modprobe speakup_soft
>> > > > >    espeakup
>> > > > > > >    [   11.336314] r8169 0000:02:00.0 eth0: link up
>> > > > >    [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link 
>> > > becomes > >    ready
>> > > > >    [   27.013903] releasing synth soft
>> > > > >    [   27.013975] unregistered /dev/softsynth
>> > > > >    [   32.824006] speakup: unregistering synth device /dev/synth
>> > > > >    [   56.630004] speakup: module is from the staging directory, 
>> > > the > >   quality
>> > > > >    is unknown, you have been warned.
>> > > > >    [   56.630896] input: Speakup as /devices/virtual/input/input7
>> > > > >    [   56.631031] initialized device: /dev/synth, node (MAJOR 10, 
>> > > > >   MINOR 25)
>> > > > >    [   56.631055] speakup 3.1.6: initialized
>> > > > >    [   56.631057] synth name on entry is: dectlk
>> > > > >    [   56.639855] speakup_dectlk: module is from the staging > > 
>> > >  directory, the
>> > > > >    quality is unknown, you have been warned.
>> > > > >    [   56.640036] synth probe
>> > > > >    [   56.640039] Ports not available, trying to steal them
>> > > > >    [   56.640042] Unable to allocate port at 3f8, errno -16
>> > > > >    [   56.640044] Dectalk Express: not found
>> > > > >    [   56.640045] dectlk: device probe failed
>> > > > >    [   67.012005] speakup: unregistering synth device /dev/synth
>> > > > >    [   70.985966] speakup: module is from the staging directory, 
>> > > the > >   quality
>> > > > >    is unknown, you have been warned.
>> > > > >    [   70.986851] input: Speakup as /devices/virtual/input/input8
>> > > > >    [   70.986983] initialized device: /dev/synth, node (MAJOR 10, 
>> > > > >   MINOR 25)
>> > > > >    [   70.987006] speakup 3.1.6: initialized
>> > > > >    [   70.987008] synth name on entry is: dectlk
>> > > > >    [   70.987055] speakup_soft: module is from the staging 
>> > >  directory, > >   the
>> > > > >    quality is unknown, you have been warned.
>> > > > >    [   70.987193] synth probe
>> > > > >    [   70.987230] initialized device: /dev/softsynth, node (MAJOR 
>> > >  10, > >  MINOR
>> > > > >   26)
>> > > > >   _______________________________________________
>> > > >   Speakup mailing list
>> > > >   Speakup@linux-speakup.org
>> > > >  http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>> > > > > 
>> > 
>> > 
>> > 
>
>
>

Re: Help with serial synths in 4.X kernels

[John G Heim]

karen, it's reasonable for me to assume that you are a speakup user 
since you're on this list. As a user of speakup, you are as responsible 
as anybody for the code. That's what open source is.

You need to understand that when you say something like, "without 
considering the variations in how individuals learn", that sure sounds 
like an accusation. It sounds like you are accusing someone, presumably 
me, of failing to consider variations in how individuals learn. Surely, 
you can understand how I'd take it that way, right? But nothing I've 
said implies that.
Look, I get it. I know how expensive braille displays are. ButI wasn't 
saying that if you don't like speakup, tough luck, just go out and buy 
yourself a braille display. It is just one possible solution.

By the way, I'm not totally ignorant of the different ways people learn. 
And I happen to know that a lot of your objections to my suggestion that 
a braille display might be one solution are pretty bogus. People with 
cognitive disabilities on top of being blind often prefer a braille display.
On 02/24/2016 01:55 PM, Karen Lewellen wrote:
> I made no such accusation.
> I stated that speaking only for myself, I am  surprised how such 
> projects come  together without considering the variations in how 
> individuals learn, access, and use technologies.
> You suggested that others should make contingency plans, assuming that 
> such plans were a possibility, otherwise why would you suggest as much.
> I am not sure why I am responsible for a code, just because I occupy a 
> list.  does that make me responsible for Google's access choices, or 
> Apples, just because I am a list member?
> Why does my presence on a list make me responsible for the content of 
> the speakup code?
>
>
> On Wed, 24 Feb 2016, John G Heim wrote:
>
>> Karen, suggesting one workaround for the problems with serial synths 
>> in speakup does not imply that I am forgetting the basic needs of my 
>> fellow human beings. That's ridiculous. Nothing I said implies in any 
>> way that getting your hands on a braille display is a solution that 
>> works for everyone.
>>
>> Maybe the concept of open source is unclear but the truth is that 
>> you, Karen, are as responsible as anyone on this list for the speakup 
>> code. Why don't you rewrite it yourself? If you say you can't do 
>> that, would it be fair for me to accuse you of losing track of the 
>> basic needs of your fellow humans?
>>
>>
>>
>> On 02/24/2016 12:05 PM, Karen Lewellen wrote:
>>>  I respect that you feel your stance and your work is important.  I 
>>> agree
>>>  on Samuel, he has given a grand deal, providing much talent to this 
>>> effort
>>>  as well.
>>>  However, speaking only for myself, I do not find  the suggestion 
>>> that what
>>>  you are using applies to anyone else    making  a great deal of
>>>  sense...there is only one of you.
>>>  Speaking only for myself, I am amazed how these projects have come
>>>  together forgetting the most fundamental thing about the people using
>>>  them.
>>>  You are talking of humans, millions of them, and all humans learn
>>>  differently.  You are using a braille display and software speech.  
>>> that
>>>  is fine, but what if the person using the screen reader is doing so
>>>  because they have a learning disability instead?
>>>  a large percentage  of the population that  can benefit from 
>>> speech. what
>>>  if they are in the sight loss majority, not braille users, or have no
>>>  access to a display....costly  are they not? what if they, as  I 
>>> know  can
>>>  be the case, find software speech impossible to hear and understand?
>>>  What if they are managing a combination of print challenges? I can 
>>> go on
>>>  and on. Believe me i resonate with the challenges of getting a good 
>>> answer
>>>  out of the  larger  Linux community...I have been  working on a really
>>>  functional Linux box for a good decade or more at least.
>>>  Still there are some who hold Linux out as a better alternative to say
>>>  using other low graphics options, like DOS...and you indicate here 
>>> that
>>>  the suggestion may not be reasonable, unless you are willing and 
>>> able to
>>>  build the house yourself.    You  must be a programmer before you can
>>>  fully  have the program.  I cannot say this is necessary using dos for
>>>  sure.
>>>  I can say, speaking only for myself though that thinking everyone 
>>> sharing
>>>  a label with you is just like you prevents talent from being used 
>>> for a
>>>  greater and flexible solution across low graphics platforms.
>>>  Or even more graphical ones for that matter.
>>>  I grant you my Microsoft comparison may not be fair.  Save the same 
>>> kind
>>>  of arrogance you found in the Linux community has been mirrored  in 
>>> the
>>>  windows one on many occasions.
>>>  I sincerely wish you success  finding a real solution.  Tony as well.
>>>  However, if anyone starts to wonder why  I personally will choose ssh
>>>  TELNET into any Linux structure from outside, I can point to this 
>>> entire
>>>  thread, smiles.
>>>  Thanks for engaging with me,
>>>  Karen
>>>
>>>
>>>  On Wed, 24 Feb 2016, John G Heim wrote:
>>>
>>> >  Well, as I said, I've been relying more and more upon a braille 
>>> display >  and software speech.
>>> > >  I can't say it's unfair to say linux is no better than 
>>> Microsoft because >  I think in this context, it's comparing apples 
>>> and oranges. IMO, it's >  neiher fair or unfair. It's like saying a 
>>> dolphin is no better than an > oak tree. Well, at what? If you want 
>>> linux to do something, you have to >  do it yourself or maybe pay 
>>> someone to do it for you.
>>> >  On the other hand, I would say that developers are ethically 
>>> required to >  allow accessibility software to work with their code 
>>> and the linux >  kernel developers have been woefully inadequate in 
>>> that regard. A year >  or two ago, I took the time to drill down 
>>> through the functions the >  speakup code was calling to "steal" the 
>>> serial port. I found it led to a >  function inside the main kernel 
>>> code (not in staging) that could never >  return a success. I asked 
>>> about it on the kernel developers list. If >  speakup isn't 
>>> accessing the serial port the right way, what is the right >  way? 
>>> The answers I got were BS. The speakup code is not very well >  
>>> written, the whole thing should be moved to user space, etc. My 
>>> reaction >  was like, okay, maybe, but can someone please answer the 
>>> question? But > apparently not. It was infuriating. That's when I 
>>> started posting >  kernels with the function call commented out.
>>> > >  The whole thing just makes no sense. Why even include code that 
>>> is >  deliberately disabled? Samuel is probably freaking out if he 
>>> has read >  this far. Someone, probably him, went through a lot of 
>>> work just to get > speakup in staging. And, after all, software 
>>> speech does work. That is >  not trivial.
>>> > >  On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>>> > >  May i ask how one finds contingency plans for your ears, your 
>>> brain, > >  and
>>> > >   your processing? smiles.
>>> > >   I am not following this debate closely, but it certainly 
>>> supports my
>>> > >   worries about Linux as a main computing solution. If someone 
>>> is > >  going to
>>> > >   remove the door to functionality, or decide for me how I 
>>> personally
>>> > >   accommodate my body differences, then they are no different 
>>> than say
>>> > >   Microsoft.
>>> > >   Access is a human right in some places,  not a feature.
>>> > >   defining that access begins and ends with the individual, 
>>> which is > >  why the
>>> > >   best access uses a foundation allowing for many ways  in so to 
>>> speak.
>>> > > > >   Going back to the corner now,
>>> > >   Kare
>>> > > > > > >   On Wed, 24 Feb 2016, John G Heim wrote:
>>> > > > > >   Well, first of all, I didn't mean to say you shouldn't 
>>> use a > >  serial >  hardware synth. However,IMO, you would be wise 
>>> to consider > > contingency >  plans. If your livelihood depends on 
>>> that serial synth, > >  you'd be wise to >  begin examining your 
>>> alternatives.
>>> > > > >   Also, I can't promise to debug the kernel code. When I 
>>> said > >  check the >  syslog, I meant for you to check the syslog. 
>>> If I can > >  find the time to >  take a look at it, I certainly 
>>> will but I can't > >  promise that. I suspect > that what's 
>>> happening is that when speakup > >  tries to "steal" the serial >  
>>> port, the return value is no longer > > just null. When I last 
>>> traced back >  the functions that speakup was > >  calling to steal 
>>> the serial port, it was >  bullstuff. Speakup called > >  a function 
>>> that did nothing -- which isn't the >  fault of the speakup > >  
>>> developers. I suspect that those functions now do > something -- > 
>>> >  probably not what we want but something.
>>> > > > >   It has probably been a year since I last posted a rant on 
>>> this > >  list >  about the linux kernel developers. As I write 
>>> this, I find > >  myself >  getting all worked up about it again. 
>>> The one good thing > >  about Trump >  running for President is that 
>>> now I have someone I find > >  more arrogant >  and irritating than 
>>> the linux kernel development > >  team.
>>> > > > > > >   On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>> > > > >   On 2/23/2016 6:31 AM, John G Heim wrote:
>>> > > > > >    You should check the syslog. There are almost certainly 
>>> > > messages > > in > there
>>> > > > > >    reporting what is happening. I'll try to compile 4.3 
>>> kernels > > for > > ubuntu >    and
>>> > > > > >    debian over the next few days. I had planned to 
>>> automate the > > > >   process. >  Every
>>> > > > > >    time my ubuntu machines download a new kernel, generate 
>>> a > > new > > patched > kernel
>>> > > > > >    package. I never got around to it though. I was using a 
>>> sed > > > >   command to
>>> > > > > >    comment out the line that caused serial synths to not 
>>> work > >  so that
>>> > > > > >    automation was possible. Part of the problem here is 
>>> that I > > have > >   kind of
>>> > > > > >    given up on serial synths myself. I have been depending 
>>> more > > and > >   more on >  the
>>> > > > > >    combination of a braille display and software speech. 
>>> It > >  seems to > > me >   that
>>> > > > > >    using a hardware speech synth is going against the 
>>> grain > > these > > > days.
>>> > > > > > > > >   As Karen and others have pointed out, we all have 
>>> our > >  own personal > >  speech
>>> > > > >   preferences. In my case, I have multiple reasons for 
>>> wanting > > serial > >   speech
>>> > > > >   to work. I find it easier to hear and understand for one 
>>> thing. > > There > >   are
>>> > > > >   some bugs in the DECtalk Express module which might be 
>>> easily > >  fixed, > >  but
>>> > > > >   the last unpatched kernel I know of that actually worked 
>>> was > >  2.6.32 > >  which
>>> > > > >   is no longer supported. Anyway, as requested, here is the 
>>> dmesg > > > >   output. I
>>> > > > >    don't see anything helpful. I did the following:
>>> > > > > > >    service espeakup stop
>>> > > > >    rmmod speakup_soft
>>> > > > >    modprobe speakup_dectlk
>>> > > > >    rmmod speakup_dectlk
>>> > > > >    rmmod speakup
>>> > > > >    modprobe speakup_soft
>>> > > > >    espeakup
>>> > > > > > >    [   11.336314] r8169 0000:02:00.0 eth0: link up
>>> > > > >    [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link 
>>> > > becomes > >    ready
>>> > > > >    [   27.013903] releasing synth soft
>>> > > > >    [   27.013975] unregistered /dev/softsynth
>>> > > > >    [   32.824006] speakup: unregistering synth device 
>>> /dev/synth
>>> > > > >    [   56.630004] speakup: module is from the staging 
>>> directory, > > the > >   quality
>>> > > > >    is unknown, you have been warned.
>>> > > > >    [   56.630896] input: Speakup as 
>>> /devices/virtual/input/input7
>>> > > > >    [   56.631031] initialized device: /dev/synth, node 
>>> (MAJOR 10, > > > >   MINOR 25)
>>> > > > >    [   56.631055] speakup 3.1.6: initialized
>>> > > > >    [   56.631057] synth name on entry is: dectlk
>>> > > > >    [   56.639855] speakup_dectlk: module is from the staging 
>>> > > > >  directory, the
>>> > > > >    quality is unknown, you have been warned.
>>> > > > >    [   56.640036] synth probe
>>> > > > >    [   56.640039] Ports not available, trying to steal them
>>> > > > >    [   56.640042] Unable to allocate port at 3f8, errno -16
>>> > > > >    [   56.640044] Dectalk Express: not found
>>> > > > >    [   56.640045] dectlk: device probe failed
>>> > > > >    [   67.012005] speakup: unregistering synth device 
>>> /dev/synth
>>> > > > >    [   70.985966] speakup: module is from the staging 
>>> directory, > > the > >   quality
>>> > > > >    is unknown, you have been warned.
>>> > > > >    [   70.986851] input: Speakup as 
>>> /devices/virtual/input/input8
>>> > > > >    [   70.986983] initialized device: /dev/synth, node 
>>> (MAJOR 10, > > > >   MINOR 25)
>>> > > > >    [   70.987006] speakup 3.1.6: initialized
>>> > > > >    [   70.987008] synth name on entry is: dectlk
>>> > > > >    [   70.987055] speakup_soft: module is from the staging > 
>>> >  directory, > >   the
>>> > > > >    quality is unknown, you have been warned.
>>> > > > >    [   70.987193] synth probe
>>> > > > >    [   70.987230] initialized device: /dev/softsynth, node 
>>> (MAJOR > >  10, > >  MINOR
>>> > > > >   26)
>>> > > > > _______________________________________________
>>> > > >   Speakup mailing list
>>> > > >   Speakup@linux-speakup.org
>>> > > > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>> > > > > > > > 
>>
>>
>>

Re: Help with serial synths in 4.X kernels

[John G Heim]

It seems to me that a hardware speech synth isn't that different from a 
serial console. All you have to do to listen to boot messages is to 
configure a serial console in your boot loader and plug your serial 
synth into that same serial port. The problem would be with controlling 
it with the keyboard. A hardware speech synth has no keyboard. So you'd 
want the normal virtual console, tty0, to control what's sent to the 
serial port. The kernel specifications say that keyboard input is taken 
from the last console configured.  Also, stdio and stderr are sent to 
the last console configured. What we'd want is a console type exactly 
like tty0 except that it also has the code from a serial console that 
send text out over the serial port. I am not sure how much control you 
have over the text that scrolls by on the screen with a virtual console. 
You'd need to add speakup control keystrokes like numpad-7 to speak the 
previous line, numpad-5 to speak the current word, etc.






On 02/24/2016 11:53 AM, covici@ccs.covici.com wrote:
> I got a more definite answer from someone  in kernel development -- I
> cannot remember who -- but he said that the serial driver should be
> written like a hardware device driver and obey all the appropriate
> protocols thereof, so if we can figure out, say, how the uart driver
> registers the port and have the speakup driver do the exact same thing,
> maybe this would work much better.
>
> John G Heim <jheim@math.wisc.edu> wrote:
>
>> Well, as I said, I've been relying more and more upon a braille
>> display and software speech.
>>
>> I can't say it's unfair to say linux is no better than Microsoft
>> because I think in this context, it's comparing apples and
>> oranges. IMO, it's neiher  fair or unfair. It's like saying a dolphin
>> is no better than an oak tree. Well, at what? If you want linux to do
>> something, you have to do it yourself or maybe pay someone to do it
>> for you.
>> On the other hand, I would say that developers are ethically required
>> to allow accessibility software to work with their code and the linux
>> kernel developers have been woefully inadequate in that regard. A year
>> or two ago, I took the time to drill down through the functions the
>> speakup code was calling to "steal" the serial port. I found it led to
>> a function inside the main kernel code (not in staging) that could
>> never return a success. I asked about it on the kernel developers
>> list. If speakup isn't accessing the serial port the right way, what
>> is the right way? The answers I got were BS. The speakup code is not
>> very well written, the whole thing should be moved to user space,
>> etc. My reaction was like, okay, maybe, but can someone please answer
>> the question? But apparently not. It was infuriating. That's when I
>> started posting kernels with the function call commented out.
>>
>> The whole thing just makes no sense. Why even include code that is
>> deliberately disabled? Samuel is probably freaking out if he has read
>> this far. Someone, probably him, went through a lot of work just to
>> get speakup in staging. And, after all, software speech does
>> work. That is not trivial.
>>
>> On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>>> May i ask how one finds contingency plans for your ears, your brain,
>>> and your processing? smiles.
>>> I am not following this debate closely, but it certainly supports my
>>> worries about Linux as a main computing solution.  If someone is
>>> going to remove the door to functionality, or decide for me how I
>>> personally accommodate my body differences, then they are no
>>> different than say Microsoft.
>>> Access is a human right in some places,  not a feature.
>>> defining that access begins and ends with the individual, which is
>>> why the best access uses a foundation allowing for many ways  in so
>>> to speak.
>>>
>>> Going back to the corner now,
>>> Kare
>>>
>>>
>>> On Wed, 24 Feb 2016, John G Heim wrote:
>>>
>>>> Well, first of all, I didn't mean to say you shouldn't use a serial
>>>> hardware synth. However,IMO, you would be wise to consider
>>>> contingency plans. If your livelihood depends on that serial synth,
>>>> you'd be wise to begin examining your alternatives.
>>>>
>>>> Also, I can't promise to debug the kernel code. When I said check
>>>> the syslog, I meant for you to check the syslog. If I can find the
>>>> time to take a look at it, I certainly will but I can't promise
>>>> that. I suspect that what's happening is that when speakup tries to
>>>> "steal" the serial port, the return value is no longer just
>>>> null. When I last traced back the functions that speakup was
>>>> calling to steal the serial port, it was bullstuff. Speakup called
>>>> a function that did nothing -- which isn't the fault of the speakup
>>>> developers. I suspect that those functions now do something --
>>>> probably not what we want but something.
>>>>
>>>> It has probably been a year since I last posted a rant on this list
>>>> about the linux kernel developers. As I write this, I find myself
>>>> getting all worked up about it again. The one good thing about
>>>> Trump running for President is that now I have someone I find more
>>>> arrogant and irritating than the linux kernel development team.
>>>>
>>>>
>>>>
>>>> On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>>>> On 2/23/2016 6:31 AM, John G Heim wrote:
>>>>>>   You should check the syslog. There are almost certainly
>>>>> messages in >  there
>>>>>>   reporting what is happening. I'll try to compile 4.3 kernels
>>>>> for ubuntu >  and
>>>>>>   debian over the next few days. I had planned to automate the
>>>>> process. >  Every
>>>>>>   time my ubuntu machines download a new kernel, generate a new
>>>>> patched >  kernel
>>>>>>   package. I never got around to it though. I was using a sed
>>>>> command to
>>>>>>   comment out the line that caused serial synths to not work so that
>>>>>>   automation was possible. Part of the problem here is that I
>>>>> have kind of
>>>>>>   given up on serial synths myself. I have been depending more
>>>>> and more on >  the
>>>>>>   combination of a braille display and software speech. It seems
>>>>> to me >  that
>>>>>>   using a hardware speech synth is going against the grain these days.
>>>>>
>>>>>   As Karen and others have pointed out, we all have our own
>>>>> personal speech
>>>>>   preferences. In my case, I have multiple reasons for wanting
>>>>> serial speech
>>>>>   to work. I find it easier to hear and understand for one
>>>>> thing. There are
>>>>>   some bugs in the DECtalk Express module which might be easily
>>>>> fixed, but
>>>>>   the last unpatched kernel I know of that actually worked was
>>>>> 2.6.32 which
>>>>>   is no longer supported. Anyway, as requested, here is the dmesg
>>>>> output. I
>>>>>   don't see anything helpful. I did the following:
>>>>>
>>>>>   service espeakup stop
>>>>>   rmmod speakup_soft
>>>>>   modprobe speakup_dectlk
>>>>>   rmmod speakup_dectlk
>>>>>   rmmod speakup
>>>>>   modprobe speakup_soft
>>>>>   espeakup
>>>>>
>>>>>   [   11.336314] r8169 0000:02:00.0 eth0: link up
>>>>>   [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>>>   [   27.013903] releasing synth soft
>>>>>   [   27.013975] unregistered /dev/softsynth
>>>>>   [   32.824006] speakup: unregistering synth device /dev/synth
>>>>>   [   56.630004] speakup: module is from the staging directory, the
>>>>> quality
>>>>>   is unknown, you have been warned.
>>>>>   [   56.630896] input: Speakup as /devices/virtual/input/input7
>>>>>   [   56.631031] initialized device: /dev/synth, node (MAJOR 10,
>>>>> MINOR 25)
>>>>>   [   56.631055] speakup 3.1.6: initialized
>>>>>   [   56.631057] synth name on entry is: dectlk
>>>>>   [   56.639855] speakup_dectlk: module is from the staging
>>>>> directory, the
>>>>>   quality is unknown, you have been warned.
>>>>>   [   56.640036] synth probe
>>>>>   [   56.640039] Ports not available, trying to steal them
>>>>>   [   56.640042] Unable to allocate port at 3f8, errno -16
>>>>>   [   56.640044] Dectalk Express: not found
>>>>>   [   56.640045] dectlk: device probe failed
>>>>>   [   67.012005] speakup: unregistering synth device /dev/synth
>>>>>   [   70.985966] speakup: module is from the staging directory, the
>>>>> quality
>>>>>   is unknown, you have been warned.
>>>>>   [   70.986851] input: Speakup as /devices/virtual/input/input8
>>>>>   [   70.986983] initialized device: /dev/synth, node (MAJOR 10,
>>>>> MINOR 25)
>>>>>   [   70.987006] speakup 3.1.6: initialized
>>>>>   [   70.987008] synth name on entry is: dectlk
>>>>>   [   70.987055] speakup_soft: module is from the staging directory, the
>>>>>   quality is unknown, you have been warned.
>>>>>   [   70.987193] synth probe
>>>>>   [   70.987230] initialized device: /dev/softsynth, node (MAJOR
>>>>> 10, MINOR
>>>>>   26)
>>>> _______________________________________________
>>>> Speakup mailing list
>>>> Speakup@linux-speakup.org
>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>>
>>>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>

Re: Help with serial synths in 4.X kernels

[Jude DaShiell]

hardware speech synthesizers will be available into the future since 
they're used in too many commercial applications to stop producing them.
  The RC systems where the litetalk comes from still sells litetalk 
serial and I think usb synthesizers and the prices for these the last 
time I checked was about $190.00 less than I paid for my original 
synthesizer something like $350.00 many years ago.  Hospitals use 
hardware speech synthesizers to direct patients when certain diagnostic 
tests and treatments get done.

On Wed, 24 Feb 2016, John G Heim wrote:

> Date: Wed, 24 Feb 2016 10:44:51
> From: John G Heim <jheim@math.wisc.edu>
> To: Tony Baechler <tony@baechler.net>,
>     Speakup is a screen review system for Linux. <speakup@linux-speakup.org>
> Subject: Re: Help with serial synths in 4.X kernels
> 
> Well, first of all, I didn't mean to say you shouldn't use a serial 
> hardware synth. However,IMO, you would be wise to consider contingency 
> plans. If your livelihood depends on that serial synth, you'd be wise to 
> begin examining your alternatives.
>
> Also, I can't promise to debug the kernel code. When I said check the 
> syslog, I meant for you to check the syslog. If I can find the time to 
> take a look at it, I certainly will but I can't promise that. I suspect 
> that what's happening is that when speakup tries to "steal" the serial 
> port, the return value is no longer just null. When I last traced back 
> the functions that speakup was calling to steal the serial port, it was 
> bullstuff. Speakup called a function that did nothing -- which isn't the 
> fault of the speakup developers. I suspect that those functions now do 
> something -- probably not what we want but something.
>
> It has probably been a year since I last posted a rant on this list 
> about the linux kernel developers. As I write this, I find myself 
> getting all worked up about it again. The one good thing about Trump 
> running for President is that now I have someone I find more arrogant 
> and irritating than the linux kernel development team.
>
>
>
> On 02/24/2016 08:29 AM, Tony Baechler wrote:
>> On 2/23/2016 6:31 AM, John G Heim wrote:
>>> You should check the syslog. There are almost certainly messages in 
>>> there
>>> reporting what is happening. I'll try to compile 4.3 kernels for 
>>> ubuntu and
>>> debian over the next few days. I had planned to automate the process. 
>>> Every
>>> time my ubuntu machines download a new kernel, generate a new patched 
>>> kernel
>>> package. I never got around to it though. I was using a sed command to
>>> comment out the line that caused serial synths to not work so that
>>> automation was possible. Part of the problem here is that I have kind of
>>> given up on serial synths myself. I have been depending more and more 
>>> on the
>>> combination of a braille display and software speech.  It seems to me 
>>> that
>>> using a hardware speech synth is going against the grain these days.
>>
>>
>> As Karen and others have pointed out, we all have our own personal 
>> speech preferences. In my case, I have multiple reasons for wanting 
>> serial speech to work. I find it easier to hear and understand for one 
>> thing. There are some bugs in the DECtalk Express module which might 
>> be easily fixed, but the last unpatched kernel I know of that actually 
>> worked was 2.6.32 which is no longer supported. Anyway, as requested, 
>> here is the dmesg output. I don't see anything helpful. I did the 
>> following:
>>
>> service espeakup stop
>> rmmod speakup_soft
>> modprobe speakup_dectlk
>> rmmod speakup_dectlk
>> rmmod speakup
>> modprobe speakup_soft
>> espeakup
>>
>> [   11.336314] r8169 0000:02:00.0 eth0: link up
>> [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> [   27.013903] releasing synth soft
>> [   27.013975] unregistered /dev/softsynth
>> [   32.824006] speakup: unregistering synth device /dev/synth
>> [   56.630004] speakup: module is from the staging directory, the 
>> quality is unknown, you have been warned.
>> [   56.630896] input: Speakup as /devices/virtual/input/input7
>> [   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
>> [   56.631055] speakup 3.1.6: initialized
>> [   56.631057] synth name on entry is: dectlk
>> [   56.639855] speakup_dectlk: module is from the staging directory, 
>> the quality is unknown, you have been warned.
>> [   56.640036] synth probe
>> [   56.640039] Ports not available, trying to steal them
>> [   56.640042] Unable to allocate port at 3f8, errno -16
>> [   56.640044] Dectalk Express: not found
>> [   56.640045] dectlk: device probe failed
>> [   67.012005] speakup: unregistering synth device /dev/synth
>> [   70.985966] speakup: module is from the staging directory, the 
>> quality is unknown, you have been warned.
>> [   70.986851] input: Speakup as /devices/virtual/input/input8
>> [   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
>> [   70.987006] speakup 3.1.6: initialized
>> [   70.987008] synth name on entry is: dectlk
>> [   70.987055] speakup_soft: module is from the staging directory, the 
>> quality is unknown, you have been warned.
>> [   70.987193] synth probe
>> [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, 
>> MINOR 26)
>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

-- 

Re: Help with serial synths in 4.X kernels

[covici]

I don't think that will work well, too many differences between what we
need and the console driver -- this is how I did the first serial driver
for speakup, back in the day, but I had to patch some kernel modules and
changes since then make it not worth doing that way, or maybe it would
be impossible to do it that way.

John G Heim <jheim@math.wisc.edu> wrote:

> It seems to me that a hardware speech synth isn't that different from
> a serial console. All you have to do to listen to boot messages is to
> configure a serial console in your boot loader and plug your serial
> synth into that same serial port. The problem would be with
> controlling it with the keyboard. A hardware speech synth has no
> keyboard. So you'd want the normal virtual console, tty0, to control
> what's sent to the serial port. The kernel specifications say that
> keyboard input is taken from the last console configured.  Also, stdio
> and stderr are sent to the last console configured. What we'd want is
> a console type exactly like tty0 except that it also has the code from
> a serial console that send text out over the serial port. I am not
> sure how much control you have over the text that scrolls by on the
> screen with a virtual console. You'd need to add speakup control
> keystrokes like numpad-7 to speak the previous line, numpad-5 to speak
> the current word, etc.
> 
> 
> 
> 
> 
> 
> On 02/24/2016 11:53 AM, covici@ccs.covici.com wrote:
> > I got a more definite answer from someone  in kernel development -- I
> > cannot remember who -- but he said that the serial driver should be
> > written like a hardware device driver and obey all the appropriate
> > protocols thereof, so if we can figure out, say, how the uart driver
> > registers the port and have the speakup driver do the exact same thing,
> > maybe this would work much better.
> >
> > John G Heim <jheim@math.wisc.edu> wrote:
> >
> >> Well, as I said, I've been relying more and more upon a braille
> >> display and software speech.
> >>
> >> I can't say it's unfair to say linux is no better than Microsoft
> >> because I think in this context, it's comparing apples and
> >> oranges. IMO, it's neiher  fair or unfair. It's like saying a dolphin
> >> is no better than an oak tree. Well, at what? If you want linux to do
> >> something, you have to do it yourself or maybe pay someone to do it
> >> for you.
> >> On the other hand, I would say that developers are ethically required
> >> to allow accessibility software to work with their code and the linux
> >> kernel developers have been woefully inadequate in that regard. A year
> >> or two ago, I took the time to drill down through the functions the
> >> speakup code was calling to "steal" the serial port. I found it led to
> >> a function inside the main kernel code (not in staging) that could
> >> never return a success. I asked about it on the kernel developers
> >> list. If speakup isn't accessing the serial port the right way, what
> >> is the right way? The answers I got were BS. The speakup code is not
> >> very well written, the whole thing should be moved to user space,
> >> etc. My reaction was like, okay, maybe, but can someone please answer
> >> the question? But apparently not. It was infuriating. That's when I
> >> started posting kernels with the function call commented out.
> >>
> >> The whole thing just makes no sense. Why even include code that is
> >> deliberately disabled? Samuel is probably freaking out if he has read
> >> this far. Someone, probably him, went through a lot of work just to
> >> get speakup in staging. And, after all, software speech does
> >> work. That is not trivial.
> >>
> >> On 02/24/2016 10:05 AM, Karen Lewellen wrote:
> >>> May i ask how one finds contingency plans for your ears, your brain,
> >>> and your processing? smiles.
> >>> I am not following this debate closely, but it certainly supports my
> >>> worries about Linux as a main computing solution.  If someone is
> >>> going to remove the door to functionality, or decide for me how I
> >>> personally accommodate my body differences, then they are no
> >>> different than say Microsoft.
> >>> Access is a human right in some places,  not a feature.
> >>> defining that access begins and ends with the individual, which is
> >>> why the best access uses a foundation allowing for many ways  in so
> >>> to speak.
> >>>
> >>> Going back to the corner now,
> >>> Kare
> >>>
> >>>
> >>> On Wed, 24 Feb 2016, John G Heim wrote:
> >>>
> >>>> Well, first of all, I didn't mean to say you shouldn't use a serial
> >>>> hardware synth. However,IMO, you would be wise to consider
> >>>> contingency plans. If your livelihood depends on that serial synth,
> >>>> you'd be wise to begin examining your alternatives.
> >>>>
> >>>> Also, I can't promise to debug the kernel code. When I said check
> >>>> the syslog, I meant for you to check the syslog. If I can find the
> >>>> time to take a look at it, I certainly will but I can't promise
> >>>> that. I suspect that what's happening is that when speakup tries to
> >>>> "steal" the serial port, the return value is no longer just
> >>>> null. When I last traced back the functions that speakup was
> >>>> calling to steal the serial port, it was bullstuff. Speakup called
> >>>> a function that did nothing -- which isn't the fault of the speakup
> >>>> developers. I suspect that those functions now do something --
> >>>> probably not what we want but something.
> >>>>
> >>>> It has probably been a year since I last posted a rant on this list
> >>>> about the linux kernel developers. As I write this, I find myself
> >>>> getting all worked up about it again. The one good thing about
> >>>> Trump running for President is that now I have someone I find more
> >>>> arrogant and irritating than the linux kernel development team.
> >>>>
> >>>>
> >>>>
> >>>> On 02/24/2016 08:29 AM, Tony Baechler wrote:
> >>>>> On 2/23/2016 6:31 AM, John G Heim wrote:
> >>>>>>   You should check the syslog. There are almost certainly
> >>>>> messages in >  there
> >>>>>>   reporting what is happening. I'll try to compile 4.3 kernels
> >>>>> for ubuntu >  and
> >>>>>>   debian over the next few days. I had planned to automate the
> >>>>> process. >  Every
> >>>>>>   time my ubuntu machines download a new kernel, generate a new
> >>>>> patched >  kernel
> >>>>>>   package. I never got around to it though. I was using a sed
> >>>>> command to
> >>>>>>   comment out the line that caused serial synths to not work so that
> >>>>>>   automation was possible. Part of the problem here is that I
> >>>>> have kind of
> >>>>>>   given up on serial synths myself. I have been depending more
> >>>>> and more on >  the
> >>>>>>   combination of a braille display and software speech. It seems
> >>>>> to me >  that
> >>>>>>   using a hardware speech synth is going against the grain these days.
> >>>>>
> >>>>>   As Karen and others have pointed out, we all have our own
> >>>>> personal speech
> >>>>>   preferences. In my case, I have multiple reasons for wanting
> >>>>> serial speech
> >>>>>   to work. I find it easier to hear and understand for one
> >>>>> thing. There are
> >>>>>   some bugs in the DECtalk Express module which might be easily
> >>>>> fixed, but
> >>>>>   the last unpatched kernel I know of that actually worked was
> >>>>> 2.6.32 which
> >>>>>   is no longer supported. Anyway, as requested, here is the dmesg
> >>>>> output. I
> >>>>>   don't see anything helpful. I did the following:
> >>>>>
> >>>>>   service espeakup stop
> >>>>>   rmmod speakup_soft
> >>>>>   modprobe speakup_dectlk
> >>>>>   rmmod speakup_dectlk
> >>>>>   rmmod speakup
> >>>>>   modprobe speakup_soft
> >>>>>   espeakup
> >>>>>
> >>>>>   [   11.336314] r8169 0000:02:00.0 eth0: link up
> >>>>>   [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>>>>   [   27.013903] releasing synth soft
> >>>>>   [   27.013975] unregistered /dev/softsynth
> >>>>>   [   32.824006] speakup: unregistering synth device /dev/synth
> >>>>>   [   56.630004] speakup: module is from the staging directory, the
> >>>>> quality
> >>>>>   is unknown, you have been warned.
> >>>>>   [   56.630896] input: Speakup as /devices/virtual/input/input7
> >>>>>   [   56.631031] initialized device: /dev/synth, node (MAJOR 10,
> >>>>> MINOR 25)
> >>>>>   [   56.631055] speakup 3.1.6: initialized
> >>>>>   [   56.631057] synth name on entry is: dectlk
> >>>>>   [   56.639855] speakup_dectlk: module is from the staging
> >>>>> directory, the
> >>>>>   quality is unknown, you have been warned.
> >>>>>   [   56.640036] synth probe
> >>>>>   [   56.640039] Ports not available, trying to steal them
> >>>>>   [   56.640042] Unable to allocate port at 3f8, errno -16
> >>>>>   [   56.640044] Dectalk Express: not found
> >>>>>   [   56.640045] dectlk: device probe failed
> >>>>>   [   67.012005] speakup: unregistering synth device /dev/synth
> >>>>>   [   70.985966] speakup: module is from the staging directory, the
> >>>>> quality
> >>>>>   is unknown, you have been warned.
> >>>>>   [   70.986851] input: Speakup as /devices/virtual/input/input8
> >>>>>   [   70.986983] initialized device: /dev/synth, node (MAJOR 10,
> >>>>> MINOR 25)
> >>>>>   [   70.987006] speakup 3.1.6: initialized
> >>>>>   [   70.987008] synth name on entry is: dectlk
> >>>>>   [   70.987055] speakup_soft: module is from the staging directory, the
> >>>>>   quality is unknown, you have been warned.
> >>>>>   [   70.987193] synth probe
> >>>>>   [   70.987230] initialized device: /dev/softsynth, node (MAJOR
> >>>>> 10, MINOR
> >>>>>   26)
> >>>> _______________________________________________
> >>>> Speakup mailing list
> >>>> Speakup@linux-speakup.org
> >>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>>>
> >>>>
> >> _______________________________________________
> >> Speakup mailing list
> >> Speakup@linux-speakup.org
> >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>
> 
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[John G Heim]

The hardware might be available but that doesn't mean it will work with 
the linux kernel.
On 02/24/2016 10:32 PM, Jude DaShiell wrote:
> hardware speech synthesizers will be available into the future since 
> they're used in too many commercial applications to stop producing them.
>  The RC systems where the litetalk comes from still sells litetalk 
> serial and I think usb synthesizers and the prices for these the last 
> time I checked was about $190.00 less than I paid for my original 
> synthesizer something like $350.00 many years ago. Hospitals use 
> hardware speech synthesizers to direct patients when certain 
> diagnostic tests and treatments get done.
>
> On Wed, 24 Feb 2016, John G Heim wrote:
>
>> Date: Wed, 24 Feb 2016 10:44:51
>> From: John G Heim <jheim@math.wisc.edu>
>> To: Tony Baechler <tony@baechler.net>,
>>     Speakup is a screen review system for Linux. 
>> <speakup@linux-speakup.org>
>> Subject: Re: Help with serial synths in 4.X kernels
>>
>> Well, first of all, I didn't mean to say you shouldn't use a serial 
>> hardware synth. However,IMO, you would be wise to consider 
>> contingency plans. If your livelihood depends on that serial synth, 
>> you'd be wise to begin examining your alternatives.
>>
>> Also, I can't promise to debug the kernel code. When I said check the 
>> syslog, I meant for you to check the syslog. If I can find the time 
>> to take a look at it, I certainly will but I can't promise that. I 
>> suspect that what's happening is that when speakup tries to "steal" 
>> the serial port, the return value is no longer just null. When I last 
>> traced back the functions that speakup was calling to steal the 
>> serial port, it was bullstuff. Speakup called a function that did 
>> nothing -- which isn't the fault of the speakup developers. I suspect 
>> that those functions now do something -- probably not what we want 
>> but something.
>>
>> It has probably been a year since I last posted a rant on this list 
>> about the linux kernel developers. As I write this, I find myself 
>> getting all worked up about it again. The one good thing about Trump 
>> running for President is that now I have someone I find more arrogant 
>> and irritating than the linux kernel development team.
>>
>>
>>
>> On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>> On 2/23/2016 6:31 AM, John G Heim wrote:
>>>> You should check the syslog. There are almost certainly messages in 
>>>> there
>>>> reporting what is happening. I'll try to compile 4.3 kernels for 
>>>> ubuntu and
>>>> debian over the next few days. I had planned to automate the 
>>>> process. Every
>>>> time my ubuntu machines download a new kernel, generate a new 
>>>> patched kernel
>>>> package. I never got around to it though. I was using a sed command to
>>>> comment out the line that caused serial synths to not work so that
>>>> automation was possible. Part of the problem here is that I have 
>>>> kind of
>>>> given up on serial synths myself. I have been depending more and 
>>>> more on the
>>>> combination of a braille display and software speech.  It seems to 
>>>> me that
>>>> using a hardware speech synth is going against the grain these days.
>>>
>>>
>>> As Karen and others have pointed out, we all have our own personal 
>>> speech preferences. In my case, I have multiple reasons for wanting 
>>> serial speech to work. I find it easier to hear and understand for 
>>> one thing. There are some bugs in the DECtalk Express module which 
>>> might be easily fixed, but the last unpatched kernel I know of that 
>>> actually worked was 2.6.32 which is no longer supported. Anyway, as 
>>> requested, here is the dmesg output. I don't see anything helpful. I 
>>> did the following:
>>>
>>> service espeakup stop
>>> rmmod speakup_soft
>>> modprobe speakup_dectlk
>>> rmmod speakup_dectlk
>>> rmmod speakup
>>> modprobe speakup_soft
>>> espeakup
>>>
>>> [   11.336314] r8169 0000:02:00.0 eth0: link up
>>> [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [   27.013903] releasing synth soft
>>> [   27.013975] unregistered /dev/softsynth
>>> [   32.824006] speakup: unregistering synth device /dev/synth
>>> [   56.630004] speakup: module is from the staging directory, the 
>>> quality is unknown, you have been warned.
>>> [   56.630896] input: Speakup as /devices/virtual/input/input7
>>> [   56.631031] initialized device: /dev/synth, node (MAJOR 10, MINOR 
>>> 25)
>>> [   56.631055] speakup 3.1.6: initialized
>>> [   56.631057] synth name on entry is: dectlk
>>> [   56.639855] speakup_dectlk: module is from the staging directory, 
>>> the quality is unknown, you have been warned.
>>> [   56.640036] synth probe
>>> [   56.640039] Ports not available, trying to steal them
>>> [   56.640042] Unable to allocate port at 3f8, errno -16
>>> [   56.640044] Dectalk Express: not found
>>> [   56.640045] dectlk: device probe failed
>>> [   67.012005] speakup: unregistering synth device /dev/synth
>>> [   70.985966] speakup: module is from the staging directory, the 
>>> quality is unknown, you have been warned.
>>> [   70.986851] input: Speakup as /devices/virtual/input/input8
>>> [   70.986983] initialized device: /dev/synth, node (MAJOR 10, MINOR 
>>> 25)
>>> [   70.987006] speakup 3.1.6: initialized
>>> [   70.987008] synth name on entry is: dectlk
>>> [   70.987055] speakup_soft: module is from the staging directory, 
>>> the quality is unknown, you have been warned.
>>> [   70.987193] synth probe
>>> [   70.987230] initialized device: /dev/softsynth, node (MAJOR 10, 
>>> MINOR 26)
>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>
>

Re: Help with serial synths in 4.X kernels

[Samuel Thibault]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

Hello,

covici@ccs.covici.com, on Tue 23 Feb 2016 10:05:22 -0500, wrote:
> Do you have the serialio.c patched to comment out the return null in
> around line 42?

Just wondering...

Is it known that passing

8250.nr_uarts=0

as a kernel command-line parameter has actually the same effect?  It'll
just prevent the normal serial driver from taking the ports, and thus
speakup will not have any trouble accessing them.

About the patches I have sent to the linux kernel mailing list, only the
attached one is needed to fix serial port access.

About proper serial port access, somebody from the Outreachy intern
program is currently having a look.

Samuel

[-- Attachment #2: speakup_serial_ports --]
[-- Type: text/plain, Size: 1622 bytes --]

Subject: [PATCH] Staging: speakup: Fix getting port information

Commit f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h>
instead of <asm/serial.h>") broke the port information in the speakup
driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
and no other header includes asm/serial.h.

We here make sure serialio.c does get the arch-specific definition of
SERIAL_PORT_DFNS from asm/serial.h, if any.

Along the way, this makes sure that we do have information for the
requested serial port number (index)

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Fixes: f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>")

--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -6,6 +6,11 @@
 #include "spk_priv.h"
 #include "serialio.h"
 
+#include <linux/serial_core.h>
+/* WARNING:  Do not change this to <linux/serial.h> without testing that
+ * SERIAL_PORT_DFNS does get defined to the appropriate value. */
+#include <asm/serial.h>
+
 #ifndef SERIAL_PORT_DFNS
 #define SERIAL_PORT_DFNS
 #endif
@@ -23,9 +28,15 @@ const struct old_serial_port *spk_serial
 	int baud = 9600, quot = 0;
 	unsigned int cval = 0;
 	int cflag = CREAD | HUPCL | CLOCAL | B9600 | CS8;
-	const struct old_serial_port *ser = rs_table + index;
+	const struct old_serial_port *ser;
 	int err;
 
+	if (index >= ARRAY_SIZE(rs_table)) {
+		pr_info("no port info for ttyS%d\n", index);
+		return NULL;
+	}
+	ser = rs_table + index;
+
 	/*	Divisor, bytesize and parity */
 	quot = ser->baud_base / baud;
 	cval = cflag & (CSIZE | CSTOPB);

responsibility for speakup, was: Re: Help with serial synths in 4.X kernels

[Gregory Nowak]

Your presence on a list does not make you responsible for code; it is
the license under which the code is released that makes us all
responsible for it. I think I see what John is getting at, so let me
try to explain. Free software is exactly that, free software. That
means that everyone is welcome to modify it, and release the
modifications back to the community. Since the speakup patches are
licensed under the GPL, they are free software. That means that all of
us regardless of presence on this list, regardless of ability or
disability are responsible for it.

Let me try to put this a different way. As citizens in a democracy, we're responsible
for what our government does. The majority of us don't run for office,
though most of us could do so. The majority of us aren't programmers,
though there is nothing stopping most of us from learning to
code. When we vote for a candidate, we are giving our support for that
candidate to govern on our behalf. When we use a given piece of free
software, we are taking an interest in it. Some could say that because
they don't vote, they aren't responsible for how a country is
governed. That's not correct; by not voting, a person is simply voting
for whatever the majority wants. Some could say that because I don't
like how a piece of free software works, I am not going to use
it. That still means that others are using that software, and are
deciding where that software goes as a majority. Admittedly my analogy
probably isn't perfect, but I do feel it's still very close. I hope
why we're all ultimately responsible for speakup makes more sense now.

Greg


On Wed, Feb 24, 2016 at 02:55:04PM -0500, Karen Lewellen wrote:
> I made no such accusation.
> I stated that speaking only for myself, I am  surprised how such
> projects come  together without considering the variations in how
> individuals learn, access, and use technologies.
> You suggested that others should make contingency plans, assuming
> that such plans were a possibility, otherwise why would you suggest
> as much.
> I am not sure why I am responsible for a code, just because I occupy
> a list.  does that make me responsible for Google's access choices,
> or Apples, just because I am a list member?
> Why does my presence on a list make me responsible for the content
> of the speakup code?
> 
> 
> On Wed, 24 Feb 2016, John G Heim wrote:
> 
> >Karen, suggesting one workaround for the problems with serial
> >synths in speakup does not imply that I am forgetting the basic
> >needs of my fellow human beings. That's ridiculous. Nothing I said
> >implies in any way that getting your hands on a braille display is
> >a solution that works for everyone.
> >
> >Maybe the concept of open source is unclear but the truth is that
> >you, Karen, are as responsible as anyone on this list for the
> >speakup code. Why don't you rewrite it yourself? If you say you
> >can't do that, would it be fair for me to accuse you of losing
> >track of the basic needs of your fellow humans?
> >
> >
> >
> >On 02/24/2016 12:05 PM, Karen Lewellen wrote:
> >> I respect that you feel your stance and your work is important.  I agree
> >> on Samuel, he has given a grand deal, providing much talent to this effort
> >> as well.
> >> However, speaking only for myself, I do not find  the suggestion that what
> >> you are using applies to anyone else    making  a great deal of
> >> sense...there is only one of you.
> >> Speaking only for myself, I am amazed how these projects have come
> >> together forgetting the most fundamental thing about the people using
> >> them.
> >> You are talking of humans, millions of them, and all humans learn
> >> differently.  You are using a braille display and software speech.  that
> >> is fine, but what if the person using the screen reader is doing so
> >> because they have a learning disability instead?
> >> a large percentage  of the population that  can benefit from speech. what
> >> if they are in the sight loss majority, not braille users, or have no
> >> access to a display....costly  are they not? what if they, as  I know  can
> >> be the case, find software speech impossible to hear and understand?
> >> What if they are managing a combination of print challenges?  I can go on
> >> and on. Believe me i resonate with the challenges of getting a good answer
> >> out of the  larger  Linux community...I have been  working on a really
> >> functional Linux box for a good decade or more at least.
> >> Still there are some who hold Linux out as a better alternative to say
> >> using other low graphics options, like DOS...and you indicate here that
> >> the suggestion may not be reasonable, unless you are willing and able to
> >> build the house yourself.    You  must be a programmer before you can
> >> fully  have the program.  I cannot say this is necessary using dos for
> >> sure.
> >> I can say, speaking only for myself though that thinking everyone sharing
> >> a label with you is just like you prevents talent from being used for a
> >> greater and flexible solution across low graphics platforms.
> >> Or even more graphical ones for that matter.
> >> I grant you my Microsoft comparison may not be fair.  Save the same kind
> >> of arrogance you found in the Linux community has been mirrored  in the
> >> windows one on many occasions.
> >> I sincerely wish you success  finding a real solution.  Tony as well.
> >> However, if anyone starts to wonder why  I personally will choose ssh
> >> TELNET into any Linux structure from outside, I can point to this entire
> >> thread, smiles.
> >> Thanks for engaging with me,
> >> Karen
> >>
> >>
> >> On Wed, 24 Feb 2016, John G Heim wrote:
> >>
> >>>  Well, as I said, I've been relying more and more upon a
> >>braille display >  and software speech.
> >>> >  I can't say it's unfair to say linux is no better than
> >>Microsoft because >  I think in this context, it's comparing
> >>apples and oranges. IMO, it's >  neiher fair or unfair. It's
> >>like saying a dolphin is no better than an >  oak tree. Well, at
> >>what? If you want linux to do something, you have to >  do it
> >>yourself or maybe pay someone to do it for you.
> >>>  On the other hand, I would say that developers are ethically
> >>required to >  allow accessibility software to work with their
> >>code and the linux >  kernel developers have been woefully
> >>inadequate in that regard. A year >  or two ago, I took the time
> >>to drill down through the functions the >  speakup code was
> >>calling to "steal" the serial port. I found it led to a >
> >>function inside the main kernel code (not in staging) that could
> >>never >  return a success. I asked about it on the kernel
> >>developers list. If >  speakup isn't accessing the serial port
> >>the right way, what is the right >  way? The answers I got were
> >>BS. The speakup code is not very well >  written, the whole
> >>thing should be moved to user space, etc. My reaction >  was
> >>like, okay, maybe, but can someone please answer the question?
> >>But >  apparently not. It was infuriating. That's when I started
> >>posting >  kernels with the function call commented out.
> >>> >  The whole thing just makes no sense. Why even include code
> >>that is >  deliberately disabled? Samuel is probably freaking
> >>out if he has read >  this far. Someone, probably him, went
> >>through a lot of work just to get >  speakup in staging. And,
> >>after all, software speech does work. That is >  not trivial.
> >>> >  On 02/24/2016 10:05 AM, Karen Lewellen wrote:
> >>> >  May i ask how one finds contingency plans for your ears,
> >>your brain, > >  and
> >>> >   your processing? smiles.
> >>> >   I am not following this debate closely, but it certainly supports my
> >>> >   worries about Linux as a main computing solution.  If
> >>someone is > >  going to
> >>> >   remove the door to functionality, or decide for me how I personally
> >>> >   accommodate my body differences, then they are no different than say
> >>> >   Microsoft.
> >>> >   Access is a human right in some places,  not a feature.
> >>> >   defining that access begins and ends with the individual,
> >>which is > >  why the
> >>> >   best access uses a foundation allowing for many ways  in so to speak.
> >>> > > >   Going back to the corner now,
> >>> >   Kare
> >>> > > > > >   On Wed, 24 Feb 2016, John G Heim wrote:
> >>> > > > >   Well, first of all, I didn't mean to say you
> >>shouldn't use a > >  serial >  hardware synth. However,IMO, you
> >>would be wise to consider > >  contingency >  plans. If your
> >>livelihood depends on that serial synth, > >  you'd be wise to >
> >>begin examining your alternatives.
> >>> > > >   Also, I can't promise to debug the kernel code. When I
> >>said > >  check the >  syslog, I meant for you to check the
> >>syslog. If I can > >  find the time to >  take a look at it, I
> >>certainly will but I can't > >  promise that. I suspect > that
> >>what's happening is that when speakup > >  tries to "steal" the
> >>serial >  port, the return value is no longer > >  just null.
> >>When I last traced back >  the functions that speakup was > >
> >>calling to steal the serial port, it was >  bullstuff. Speakup
> >>called > >  a function that did nothing -- which isn't the >
> >>fault of the speakup > >  developers. I suspect that those
> >>functions now do >  something -- > >  probably not what we want
> >>but something.
> >>> > > >   It has probably been a year since I last posted a rant
> >>on this > >  list >  about the linux kernel developers. As I
> >>write this, I find > >  myself >  getting all worked up about it
> >>again. The one good thing > >  about Trump >  running for
> >>President is that now I have someone I find > >  more arrogant >
> >>and irritating than the linux kernel development > >  team.
> >>> > > > > >   On 02/24/2016 08:29 AM, Tony Baechler wrote:
> >>> > > >   On 2/23/2016 6:31 AM, John G Heim wrote:
> >>> > > > >    You should check the syslog. There are almost
> >>certainly > > messages > > in >    there
> >>> > > > >    reporting what is happening. I'll try to compile
> >>4.3 kernels > > for > > ubuntu >    and
> >>> > > > >    debian over the next few days. I had planned to
> >>automate the > > > >   process. >  Every
> >>> > > > >    time my ubuntu machines download a new kernel,
> >>generate a > > new > > patched >    kernel
> >>> > > > >    package. I never got around to it though. I was
> >>using a sed > > > >   command to
> >>> > > > >    comment out the line that caused serial synths to
> >>not work > >  so that
> >>> > > > >    automation was possible. Part of the problem here
> >>is that I > > have > >   kind of
> >>> > > > >    given up on serial synths myself. I have been
> >>depending more > > and > >   more on >  the
> >>> > > > >    combination of a braille display and software
> >>speech. It > >  seems to > > me >   that
> >>> > > > >    using a hardware speech synth is going against the
> >>grain > > these > > >    days.
> >>> > > > > > > >   As Karen and others have pointed out, we all
> >>have our > >  own personal > >  speech
> >>> > > >   preferences. In my case, I have multiple reasons for
> >>wanting > > serial > >   speech
> >>> > > >   to work. I find it easier to hear and understand for
> >>one thing. > > There > >   are
> >>> > > >   some bugs in the DECtalk Express module which might be
> >>easily > >  fixed, > >  but
> >>> > > >   the last unpatched kernel I know of that actually
> >>worked was > >  2.6.32 > >  which
> >>> > > >   is no longer supported. Anyway, as requested, here is
> >>the dmesg > > > >   output. I
> >>> > > >    don't see anything helpful. I did the following:
> >>> > > > > >    service espeakup stop
> >>> > > >    rmmod speakup_soft
> >>> > > >    modprobe speakup_dectlk
> >>> > > >    rmmod speakup_dectlk
> >>> > > >    rmmod speakup
> >>> > > >    modprobe speakup_soft
> >>> > > >    espeakup
> >>> > > > > >    [   11.336314] r8169 0000:02:00.0 eth0: link up
> >>> > > >    [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0:
> >>link > > becomes > >    ready
> >>> > > >    [   27.013903] releasing synth soft
> >>> > > >    [   27.013975] unregistered /dev/softsynth
> >>> > > >    [   32.824006] speakup: unregistering synth device /dev/synth
> >>> > > >    [   56.630004] speakup: module is from the staging
> >>directory, > > the > >   quality
> >>> > > >    is unknown, you have been warned.
> >>> > > >    [   56.630896] input: Speakup as /devices/virtual/input/input7
> >>> > > >    [   56.631031] initialized device: /dev/synth, node
> >>(MAJOR 10, > > > >   MINOR 25)
> >>> > > >    [   56.631055] speakup 3.1.6: initialized
> >>> > > >    [   56.631057] synth name on entry is: dectlk
> >>> > > >    [   56.639855] speakup_dectlk: module is from the
> >>staging > > > >  directory, the
> >>> > > >    quality is unknown, you have been warned.
> >>> > > >    [   56.640036] synth probe
> >>> > > >    [   56.640039] Ports not available, trying to steal them
> >>> > > >    [   56.640042] Unable to allocate port at 3f8, errno -16
> >>> > > >    [   56.640044] Dectalk Express: not found
> >>> > > >    [   56.640045] dectlk: device probe failed
> >>> > > >    [   67.012005] speakup: unregistering synth device /dev/synth
> >>> > > >    [   70.985966] speakup: module is from the staging
> >>directory, > > the > >   quality
> >>> > > >    is unknown, you have been warned.
> >>> > > >    [   70.986851] input: Speakup as /devices/virtual/input/input8
> >>> > > >    [   70.986983] initialized device: /dev/synth, node
> >>(MAJOR 10, > > > >   MINOR 25)
> >>> > > >    [   70.987006] speakup 3.1.6: initialized
> >>> > > >    [   70.987008] synth name on entry is: dectlk
> >>> > > >    [   70.987055] speakup_soft: module is from the
> >>staging > >  directory, > >   the
> >>> > > >    quality is unknown, you have been warned.
> >>> > > >    [   70.987193] synth probe
> >>> > > >    [   70.987230] initialized device: /dev/softsynth,
> >>node (MAJOR > >  10, > >  MINOR
> >>> > > >   26)
> >>> > > >   _______________________________________________
> >>> > >   Speakup mailing list
> >>> > >   Speakup@linux-speakup.org
> >>> > >  http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>> > > > > > >
> >
> >
> >
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-manager@EU.org

Re: responsibility for speakup, was: Re: Help with serial synths in 4.X kernels

[Scott Henning]

Hello all,

This was quite a thread. I am usually only reading, since I have yet to 
make Speakup work for long and I need to keep Windows going to have 
work. My thanks to all for the technical and philosophical insights.  I 
stay on the list because my needs may change and a console with speech 
strikes me as a practical way to use a computer. Braille is not my 
strong point and I would flounder using it, but appreciate that it is 
also a possible future solution.

I remember the dialogue to work with the kernel developers and the 
response.  My sense is that everyone is busy and most of this 
development is done as volunteers. That applies to both Speakup and the 
kernel. Or is development on the kernel done by paid programmers?

All I have to say is thanks to all who are passionate and dedicated to 
Speakup and Linux to keep working on it. It gives me hope I will be able 
to use it when I am ready, because there will be this pool of code 
contributed on this project.

Sincerely,

Scott

-- 
Scott D. Henning
shenning@durango.net
AAD Broadcast Engineering
aadbroadcast.com
P.O. Box 1372
Durango, Colorado 81302

Re: Help with serial synths in 4.X kernels

[covici]

But even with your patch, serial port access is not  available with
speakup.  Also, if you set 8250.nr_uarts=0 what happens  to other serial
ports you may need for modems, or other applications?

Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:

> Hello,
> 
> covici@ccs.covici.com, on Tue 23 Feb 2016 10:05:22 -0500, wrote:
> > Do you have the serialio.c patched to comment out the return null in
> > around line 42?
> 
> Just wondering...
> 
> Is it known that passing
> 
> 8250.nr_uarts=0
> 
> as a kernel command-line parameter has actually the same effect?  It'll
> just prevent the normal serial driver from taking the ports, and thus
> speakup will not have any trouble accessing them.
> 
> About the patches I have sent to the linux kernel mailing list, only the
> attached one is needed to fix serial port access.
> 
> About proper serial port access, somebody from the Outreachy intern
> program is currently having a look.
> 
> Samuel
> Subject: [PATCH] Staging: speakup: Fix getting port information
> 
> Commit f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h>
> instead of <asm/serial.h>") broke the port information in the speakup
> driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
> and no other header includes asm/serial.h.
> 
> We here make sure serialio.c does get the arch-specific definition of
> SERIAL_PORT_DFNS from asm/serial.h, if any.
> 
> Along the way, this makes sure that we do have information for the
> requested serial port number (index)
> 
> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Fixes: f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>")
> 
> --- a/drivers/staging/speakup/serialio.c
> +++ b/drivers/staging/speakup/serialio.c
> @@ -6,6 +6,11 @@
>  #include "spk_priv.h"
>  #include "serialio.h"
>  
> +#include <linux/serial_core.h>
> +/* WARNING:  Do not change this to <linux/serial.h> without testing that
> + * SERIAL_PORT_DFNS does get defined to the appropriate value. */
> +#include <asm/serial.h>
> +
>  #ifndef SERIAL_PORT_DFNS
>  #define SERIAL_PORT_DFNS
>  #endif
> @@ -23,9 +28,15 @@ const struct old_serial_port *spk_serial
>  	int baud = 9600, quot = 0;
>  	unsigned int cval = 0;
>  	int cflag = CREAD | HUPCL | CLOCAL | B9600 | CS8;
> -	const struct old_serial_port *ser = rs_table + index;
> +	const struct old_serial_port *ser;
>  	int err;
>  
> +	if (index >= ARRAY_SIZE(rs_table)) {
> +		pr_info("no port info for ttyS%d\n", index);
> +		return NULL;
> +	}
> +	ser = rs_table + index;
> +
>  	/*	Divisor, bytesize and parity */
>  	quot = ser->baud_base / baud;
>  	cval = cflag & (CSIZE | CSTOPB);
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: Help with serial synths in 4.X kernels

[covici]

What is outreachy intern?

Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:

> Hello,
> 
> covici@ccs.covici.com, on Tue 23 Feb 2016 10:05:22 -0500, wrote:
> > Do you have the serialio.c patched to comment out the return null in
> > around line 42?
> 
> Just wondering...
> 
> Is it known that passing
> 
> 8250.nr_uarts=0
> 
> as a kernel command-line parameter has actually the same effect?  It'll
> just prevent the normal serial driver from taking the ports, and thus
> speakup will not have any trouble accessing them.
> 
> About the patches I have sent to the linux kernel mailing list, only the
> attached one is needed to fix serial port access.
> 
> About proper serial port access, somebody from the Outreachy intern
> program is currently having a look.
> 
> Samuel
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/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: responsibility for speakup, was: Re: Help with serial synths in 4.X kernels

[Al Sten-Clanton]

I think Greg's description of responsibility below is too broad, but at 
the very least, many of us can be responsible for the shapes of our 
suggestions and complaints, and for what we expect or insist on from 
others.  Beyond that, responsibility is a more nuanced animal.

Al

On 2/26/2016 3:37 PM, Gregory Nowak wrote:
> Your presence on a list does not make you responsible for code; it is
> the license under which the code is released that makes us all
> responsible for it. I think I see what John is getting at, so let me
> try to explain. Free software is exactly that, free software. That
> means that everyone is welcome to modify it, and release the
> modifications back to the community. Since the speakup patches are
> licensed under the GPL, they are free software. That means that all of
> us regardless of presence on this list, regardless of ability or
> disability are responsible for it.
>
> Let me try to put this a different way. As citizens in a democracy, we're responsible
> for what our government does. The majority of us don't run for office,
> though most of us could do so. The majority of us aren't programmers,
> though there is nothing stopping most of us from learning to
> code. When we vote for a candidate, we are giving our support for that
> candidate to govern on our behalf. When we use a given piece of free
> software, we are taking an interest in it. Some could say that because
> they don't vote, they aren't responsible for how a country is
> governed. That's not correct; by not voting, a person is simply voting
> for whatever the majority wants. Some could say that because I don't
> like how a piece of free software works, I am not going to use
> it. That still means that others are using that software, and are
> deciding where that software goes as a majority. Admittedly my analogy
> probably isn't perfect, but I do feel it's still very close. I hope
> why we're all ultimately responsible for speakup makes more sense now.
>
> Greg
>
>
> On Wed, Feb 24, 2016 at 02:55:04PM -0500, Karen Lewellen wrote:
>> I made no such accusation.
>> I stated that speaking only for myself, I am  surprised how such
>> projects come  together without considering the variations in how
>> individuals learn, access, and use technologies.
>> You suggested that others should make contingency plans, assuming
>> that such plans were a possibility, otherwise why would you suggest
>> as much.
>> I am not sure why I am responsible for a code, just because I occupy
>> a list.  does that make me responsible for Google's access choices,
>> or Apples, just because I am a list member?
>> Why does my presence on a list make me responsible for the content
>> of the speakup code?
>>
>>
>> On Wed, 24 Feb 2016, John G Heim wrote:
>>
>>> Karen, suggesting one workaround for the problems with serial
>>> synths in speakup does not imply that I am forgetting the basic
>>> needs of my fellow human beings. That's ridiculous. Nothing I said
>>> implies in any way that getting your hands on a braille display is
>>> a solution that works for everyone.
>>>
>>> Maybe the concept of open source is unclear but the truth is that
>>> you, Karen, are as responsible as anyone on this list for the
>>> speakup code. Why don't you rewrite it yourself? If you say you
>>> can't do that, would it be fair for me to accuse you of losing
>>> track of the basic needs of your fellow humans?
>>>
>>>
>>>
>>> On 02/24/2016 12:05 PM, Karen Lewellen wrote:
>>>> I respect that you feel your stance and your work is important.  I agree
>>>> on Samuel, he has given a grand deal, providing much talent to this effort
>>>> as well.
>>>> However, speaking only for myself, I do not find  the suggestion that what
>>>> you are using applies to anyone else    making  a great deal of
>>>> sense...there is only one of you.
>>>> Speaking only for myself, I am amazed how these projects have come
>>>> together forgetting the most fundamental thing about the people using
>>>> them.
>>>> You are talking of humans, millions of them, and all humans learn
>>>> differently.  You are using a braille display and software speech.  that
>>>> is fine, but what if the person using the screen reader is doing so
>>>> because they have a learning disability instead?
>>>> a large percentage  of the population that  can benefit from speech. what
>>>> if they are in the sight loss majority, not braille users, or have no
>>>> access to a display....costly  are they not? what if they, as  I know  can
>>>> be the case, find software speech impossible to hear and understand?
>>>> What if they are managing a combination of print challenges?  I can go on
>>>> and on. Believe me i resonate with the challenges of getting a good answer
>>>> out of the  larger  Linux community...I have been  working on a really
>>>> functional Linux box for a good decade or more at least.
>>>> Still there are some who hold Linux out as a better alternative to say
>>>> using other low graphics options, like DOS...and you indicate here that
>>>> the suggestion may not be reasonable, unless you are willing and able to
>>>> build the house yourself.    You  must be a programmer before you can
>>>> fully  have the program.  I cannot say this is necessary using dos for
>>>> sure.
>>>> I can say, speaking only for myself though that thinking everyone sharing
>>>> a label with you is just like you prevents talent from being used for a
>>>> greater and flexible solution across low graphics platforms.
>>>> Or even more graphical ones for that matter.
>>>> I grant you my Microsoft comparison may not be fair.  Save the same kind
>>>> of arrogance you found in the Linux community has been mirrored  in the
>>>> windows one on many occasions.
>>>> I sincerely wish you success  finding a real solution.  Tony as well.
>>>> However, if anyone starts to wonder why  I personally will choose ssh
>>>> TELNET into any Linux structure from outside, I can point to this entire
>>>> thread, smiles.
>>>> Thanks for engaging with me,
>>>> Karen
>>>>
>>>>
>>>> On Wed, 24 Feb 2016, John G Heim wrote:
>>>>
>>>>>   Well, as I said, I've been relying more and more upon a
>>>> braille display >  and software speech.
>>>>>>   I can't say it's unfair to say linux is no better than
>>>> Microsoft because >  I think in this context, it's comparing
>>>> apples and oranges. IMO, it's >  neiher fair or unfair. It's
>>>> like saying a dolphin is no better than an >  oak tree. Well, at
>>>> what? If you want linux to do something, you have to >  do it
>>>> yourself or maybe pay someone to do it for you.
>>>>>   On the other hand, I would say that developers are ethically
>>>> required to >  allow accessibility software to work with their
>>>> code and the linux >  kernel developers have been woefully
>>>> inadequate in that regard. A year >  or two ago, I took the time
>>>> to drill down through the functions the >  speakup code was
>>>> calling to "steal" the serial port. I found it led to a >
>>>> function inside the main kernel code (not in staging) that could
>>>> never >  return a success. I asked about it on the kernel
>>>> developers list. If >  speakup isn't accessing the serial port
>>>> the right way, what is the right >  way? The answers I got were
>>>> BS. The speakup code is not very well >  written, the whole
>>>> thing should be moved to user space, etc. My reaction >  was
>>>> like, okay, maybe, but can someone please answer the question?
>>>> But >  apparently not. It was infuriating. That's when I started
>>>> posting >  kernels with the function call commented out.
>>>>>>   The whole thing just makes no sense. Why even include code
>>>> that is >  deliberately disabled? Samuel is probably freaking
>>>> out if he has read >  this far. Someone, probably him, went
>>>> through a lot of work just to get >  speakup in staging. And,
>>>> after all, software speech does work. That is >  not trivial.
>>>>>>   On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>>>>>>   May i ask how one finds contingency plans for your ears,
>>>> your brain, > >  and
>>>>>>    your processing? smiles.
>>>>>>    I am not following this debate closely, but it certainly supports my
>>>>>>    worries about Linux as a main computing solution.  If
>>>> someone is > >  going to
>>>>>>    remove the door to functionality, or decide for me how I personally
>>>>>>    accommodate my body differences, then they are no different than say
>>>>>>    Microsoft.
>>>>>>    Access is a human right in some places,  not a feature.
>>>>>>    defining that access begins and ends with the individual,
>>>> which is > >  why the
>>>>>>    best access uses a foundation allowing for many ways  in so to speak.
>>>>>>>>    Going back to the corner now,
>>>>>>    Kare
>>>>>>>>>>    On Wed, 24 Feb 2016, John G Heim wrote:
>>>>>>>>>    Well, first of all, I didn't mean to say you
>>>> shouldn't use a > >  serial >  hardware synth. However,IMO, you
>>>> would be wise to consider > >  contingency >  plans. If your
>>>> livelihood depends on that serial synth, > >  you'd be wise to >
>>>> begin examining your alternatives.
>>>>>>>>    Also, I can't promise to debug the kernel code. When I
>>>> said > >  check the >  syslog, I meant for you to check the
>>>> syslog. If I can > >  find the time to >  take a look at it, I
>>>> certainly will but I can't > >  promise that. I suspect > that
>>>> what's happening is that when speakup > >  tries to "steal" the
>>>> serial >  port, the return value is no longer > >  just null.
>>>> When I last traced back >  the functions that speakup was > >
>>>> calling to steal the serial port, it was >  bullstuff. Speakup
>>>> called > >  a function that did nothing -- which isn't the >
>>>> fault of the speakup > >  developers. I suspect that those
>>>> functions now do >  something -- > >  probably not what we want
>>>> but something.
>>>>>>>>    It has probably been a year since I last posted a rant
>>>> on this > >  list >  about the linux kernel developers. As I
>>>> write this, I find > >  myself >  getting all worked up about it
>>>> again. The one good thing > >  about Trump >  running for
>>>> President is that now I have someone I find > >  more arrogant >
>>>> and irritating than the linux kernel development > >  team.
>>>>>>>>>>    On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>>>>>>>    On 2/23/2016 6:31 AM, John G Heim wrote:
>>>>>>>>>     You should check the syslog. There are almost
>>>> certainly > > messages > > in >    there
>>>>>>>>>     reporting what is happening. I'll try to compile
>>>> 4.3 kernels > > for > > ubuntu >    and
>>>>>>>>>     debian over the next few days. I had planned to
>>>> automate the > > > >   process. >  Every
>>>>>>>>>     time my ubuntu machines download a new kernel,
>>>> generate a > > new > > patched >    kernel
>>>>>>>>>     package. I never got around to it though. I was
>>>> using a sed > > > >   command to
>>>>>>>>>     comment out the line that caused serial synths to
>>>> not work > >  so that
>>>>>>>>>     automation was possible. Part of the problem here
>>>> is that I > > have > >   kind of
>>>>>>>>>     given up on serial synths myself. I have been
>>>> depending more > > and > >   more on >  the
>>>>>>>>>     combination of a braille display and software
>>>> speech. It > >  seems to > > me >   that
>>>>>>>>>     using a hardware speech synth is going against the
>>>> grain > > these > > >    days.
>>>>>>>>>>>>    As Karen and others have pointed out, we all
>>>> have our > >  own personal > >  speech
>>>>>>>>    preferences. In my case, I have multiple reasons for
>>>> wanting > > serial > >   speech
>>>>>>>>    to work. I find it easier to hear and understand for
>>>> one thing. > > There > >   are
>>>>>>>>    some bugs in the DECtalk Express module which might be
>>>> easily > >  fixed, > >  but
>>>>>>>>    the last unpatched kernel I know of that actually
>>>> worked was > >  2.6.32 > >  which
>>>>>>>>    is no longer supported. Anyway, as requested, here is
>>>> the dmesg > > > >   output. I
>>>>>>>>     don't see anything helpful. I did the following:
>>>>>>>>>>     service espeakup stop
>>>>>>>>     rmmod speakup_soft
>>>>>>>>     modprobe speakup_dectlk
>>>>>>>>     rmmod speakup_dectlk
>>>>>>>>     rmmod speakup
>>>>>>>>     modprobe speakup_soft
>>>>>>>>     espeakup
>>>>>>>>>>     [   11.336314] r8169 0000:02:00.0 eth0: link up
>>>>>>>>     [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0:
>>>> link > > becomes > >    ready
>>>>>>>>     [   27.013903] releasing synth soft
>>>>>>>>     [   27.013975] unregistered /dev/softsynth
>>>>>>>>     [   32.824006] speakup: unregistering synth device /dev/synth
>>>>>>>>     [   56.630004] speakup: module is from the staging
>>>> directory, > > the > >   quality
>>>>>>>>     is unknown, you have been warned.
>>>>>>>>     [   56.630896] input: Speakup as /devices/virtual/input/input7
>>>>>>>>     [   56.631031] initialized device: /dev/synth, node
>>>> (MAJOR 10, > > > >   MINOR 25)
>>>>>>>>     [   56.631055] speakup 3.1.6: initialized
>>>>>>>>     [   56.631057] synth name on entry is: dectlk
>>>>>>>>     [   56.639855] speakup_dectlk: module is from the
>>>> staging > > > >  directory, the
>>>>>>>>     quality is unknown, you have been warned.
>>>>>>>>     [   56.640036] synth probe
>>>>>>>>     [   56.640039] Ports not available, trying to steal them
>>>>>>>>     [   56.640042] Unable to allocate port at 3f8, errno -16
>>>>>>>>     [   56.640044] Dectalk Express: not found
>>>>>>>>     [   56.640045] dectlk: device probe failed
>>>>>>>>     [   67.012005] speakup: unregistering synth device /dev/synth
>>>>>>>>     [   70.985966] speakup: module is from the staging
>>>> directory, > > the > >   quality
>>>>>>>>     is unknown, you have been warned.
>>>>>>>>     [   70.986851] input: Speakup as /devices/virtual/input/input8
>>>>>>>>     [   70.986983] initialized device: /dev/synth, node
>>>> (MAJOR 10, > > > >   MINOR 25)
>>>>>>>>     [   70.987006] speakup 3.1.6: initialized
>>>>>>>>     [   70.987008] synth name on entry is: dectlk
>>>>>>>>     [   70.987055] speakup_soft: module is from the
>>>> staging > >  directory, > >   the
>>>>>>>>     quality is unknown, you have been warned.
>>>>>>>>     [   70.987193] synth probe
>>>>>>>>     [   70.987230] initialized device: /dev/softsynth,
>>>> node (MAJOR > >  10, > >  MINOR
>>>>>>>>    26)
>>>>>>>>    _______________________________________________
>>>>>>>    Speakup mailing list
>>>>>>>    Speakup@linux-speakup.org
>>>>>>>   http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>>>>>>>>>
>>>
>>>
>>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

Re: Help with serial synths in 4.X kernels

[Samuel Thibault]

covici@ccs.covici.com, on Fri 26 Feb 2016 19:34:30 -0500, wrote:
> But even with your patch, serial port access is not  available with
> speakup.

Yes, you also need to prevent the conflict between the 8250 driver and
the speakup driver.

> Also, if you set 8250.nr_uarts=0 what happens  to other serial
> ports you may need for modems, or other applications?

They won't be available.

I'm sorry, but until somebody actually gets to take the time to
implement solutions, that's all we have.

Samuel

Re: Help with serial synths in 4.X kernels

[Samuel Thibault]

covici@ccs.covici.com, on Fri 26 Feb 2016 19:36:34 -0500, wrote:
> What is outreachy intern?

A minimal googling gives https://www.gnome.org/outreachy/

Re: responsibility for speakup, was: Re: Help with serial synths in 4.X kernels

[John G Heim]

Well, I agree with your point but that was not the point I was making 
exactly. My point, in fact, kind of depends on you already believing 
that as a user, you are as responsible for the code as anybody. What I 
said was that people appear to be voting with their feet with respect to 
speakup. You could say that's not true or you could say we need to turn 
that around somehow. But it's wrong to say that it means I don't care. 
Of course I care.

PS: There is a book on bookshare on writing linux device drivers. It 
looks like it's pretty much the same process it was when I was doing it 
20 years ago.






On 02/26/2016 02:37 PM, Gregory Nowak wrote:
> Your presence on a list does not make you responsible for code; it is
> the license under which the code is released that makes us all
> responsible for it. I think I see what John is getting at, so let me
> try to explain. Free software is exactly that, free software. That
> means that everyone is welcome to modify it, and release the
> modifications back to the community. Since the speakup patches are
> licensed under the GPL, they are free software. That means that all of
> us regardless of presence on this list, regardless of ability or
> disability are responsible for it.
>
> Let me try to put this a different way. As citizens in a democracy, we're responsible
> for what our government does. The majority of us don't run for office,
> though most of us could do so. The majority of us aren't programmers,
> though there is nothing stopping most of us from learning to
> code. When we vote for a candidate, we are giving our support for that
> candidate to govern on our behalf. When we use a given piece of free
> software, we are taking an interest in it. Some could say that because
> they don't vote, they aren't responsible for how a country is
> governed. That's not correct; by not voting, a person is simply voting
> for whatever the majority wants. Some could say that because I don't
> like how a piece of free software works, I am not going to use
> it. That still means that others are using that software, and are
> deciding where that software goes as a majority. Admittedly my analogy
> probably isn't perfect, but I do feel it's still very close. I hope
> why we're all ultimately responsible for speakup makes more sense now.
>
> Greg
>
>
> On Wed, Feb 24, 2016 at 02:55:04PM -0500, Karen Lewellen wrote:
>> I made no such accusation.
>> I stated that speaking only for myself, I am  surprised how such
>> projects come  together without considering the variations in how
>> individuals learn, access, and use technologies.
>> You suggested that others should make contingency plans, assuming
>> that such plans were a possibility, otherwise why would you suggest
>> as much.
>> I am not sure why I am responsible for a code, just because I occupy
>> a list.  does that make me responsible for Google's access choices,
>> or Apples, just because I am a list member?
>> Why does my presence on a list make me responsible for the content
>> of the speakup code?
>>
>>
>> On Wed, 24 Feb 2016, John G Heim wrote:
>>
>>> Karen, suggesting one workaround for the problems with serial
>>> synths in speakup does not imply that I am forgetting the basic
>>> needs of my fellow human beings. That's ridiculous. Nothing I said
>>> implies in any way that getting your hands on a braille display is
>>> a solution that works for everyone.
>>>
>>> Maybe the concept of open source is unclear but the truth is that
>>> you, Karen, are as responsible as anyone on this list for the
>>> speakup code. Why don't you rewrite it yourself? If you say you
>>> can't do that, would it be fair for me to accuse you of losing
>>> track of the basic needs of your fellow humans?
>>>
>>>
>>>
>>> On 02/24/2016 12:05 PM, Karen Lewellen wrote:
>>>> I respect that you feel your stance and your work is important.  I agree
>>>> on Samuel, he has given a grand deal, providing much talent to this effort
>>>> as well.
>>>> However, speaking only for myself, I do not find  the suggestion that what
>>>> you are using applies to anyone else    making  a great deal of
>>>> sense...there is only one of you.
>>>> Speaking only for myself, I am amazed how these projects have come
>>>> together forgetting the most fundamental thing about the people using
>>>> them.
>>>> You are talking of humans, millions of them, and all humans learn
>>>> differently.  You are using a braille display and software speech.  that
>>>> is fine, but what if the person using the screen reader is doing so
>>>> because they have a learning disability instead?
>>>> a large percentage  of the population that  can benefit from speech. what
>>>> if they are in the sight loss majority, not braille users, or have no
>>>> access to a display....costly  are they not? what if they, as  I know  can
>>>> be the case, find software speech impossible to hear and understand?
>>>> What if they are managing a combination of print challenges?  I can go on
>>>> and on. Believe me i resonate with the challenges of getting a good answer
>>>> out of the  larger  Linux community...I have been  working on a really
>>>> functional Linux box for a good decade or more at least.
>>>> Still there are some who hold Linux out as a better alternative to say
>>>> using other low graphics options, like DOS...and you indicate here that
>>>> the suggestion may not be reasonable, unless you are willing and able to
>>>> build the house yourself.    You  must be a programmer before you can
>>>> fully  have the program.  I cannot say this is necessary using dos for
>>>> sure.
>>>> I can say, speaking only for myself though that thinking everyone sharing
>>>> a label with you is just like you prevents talent from being used for a
>>>> greater and flexible solution across low graphics platforms.
>>>> Or even more graphical ones for that matter.
>>>> I grant you my Microsoft comparison may not be fair.  Save the same kind
>>>> of arrogance you found in the Linux community has been mirrored  in the
>>>> windows one on many occasions.
>>>> I sincerely wish you success  finding a real solution.  Tony as well.
>>>> However, if anyone starts to wonder why  I personally will choose ssh
>>>> TELNET into any Linux structure from outside, I can point to this entire
>>>> thread, smiles.
>>>> Thanks for engaging with me,
>>>> Karen
>>>>
>>>>
>>>> On Wed, 24 Feb 2016, John G Heim wrote:
>>>>
>>>>>   Well, as I said, I've been relying more and more upon a
>>>> braille display >  and software speech.
>>>>>>   I can't say it's unfair to say linux is no better than
>>>> Microsoft because >  I think in this context, it's comparing
>>>> apples and oranges. IMO, it's >  neiher fair or unfair. It's
>>>> like saying a dolphin is no better than an >  oak tree. Well, at
>>>> what? If you want linux to do something, you have to >  do it
>>>> yourself or maybe pay someone to do it for you.
>>>>>   On the other hand, I would say that developers are ethically
>>>> required to >  allow accessibility software to work with their
>>>> code and the linux >  kernel developers have been woefully
>>>> inadequate in that regard. A year >  or two ago, I took the time
>>>> to drill down through the functions the >  speakup code was
>>>> calling to "steal" the serial port. I found it led to a >
>>>> function inside the main kernel code (not in staging) that could
>>>> never >  return a success. I asked about it on the kernel
>>>> developers list. If >  speakup isn't accessing the serial port
>>>> the right way, what is the right >  way? The answers I got were
>>>> BS. The speakup code is not very well >  written, the whole
>>>> thing should be moved to user space, etc. My reaction >  was
>>>> like, okay, maybe, but can someone please answer the question?
>>>> But >  apparently not. It was infuriating. That's when I started
>>>> posting >  kernels with the function call commented out.
>>>>>>   The whole thing just makes no sense. Why even include code
>>>> that is >  deliberately disabled? Samuel is probably freaking
>>>> out if he has read >  this far. Someone, probably him, went
>>>> through a lot of work just to get >  speakup in staging. And,
>>>> after all, software speech does work. That is >  not trivial.
>>>>>>   On 02/24/2016 10:05 AM, Karen Lewellen wrote:
>>>>>>   May i ask how one finds contingency plans for your ears,
>>>> your brain, > >  and
>>>>>>    your processing? smiles.
>>>>>>    I am not following this debate closely, but it certainly supports my
>>>>>>    worries about Linux as a main computing solution.  If
>>>> someone is > >  going to
>>>>>>    remove the door to functionality, or decide for me how I personally
>>>>>>    accommodate my body differences, then they are no different than say
>>>>>>    Microsoft.
>>>>>>    Access is a human right in some places,  not a feature.
>>>>>>    defining that access begins and ends with the individual,
>>>> which is > >  why the
>>>>>>    best access uses a foundation allowing for many ways  in so to speak.
>>>>>>>>    Going back to the corner now,
>>>>>>    Kare
>>>>>>>>>>    On Wed, 24 Feb 2016, John G Heim wrote:
>>>>>>>>>    Well, first of all, I didn't mean to say you
>>>> shouldn't use a > >  serial >  hardware synth. However,IMO, you
>>>> would be wise to consider > >  contingency >  plans. If your
>>>> livelihood depends on that serial synth, > >  you'd be wise to >
>>>> begin examining your alternatives.
>>>>>>>>    Also, I can't promise to debug the kernel code. When I
>>>> said > >  check the >  syslog, I meant for you to check the
>>>> syslog. If I can > >  find the time to >  take a look at it, I
>>>> certainly will but I can't > >  promise that. I suspect > that
>>>> what's happening is that when speakup > >  tries to "steal" the
>>>> serial >  port, the return value is no longer > >  just null.
>>>> When I last traced back >  the functions that speakup was > >
>>>> calling to steal the serial port, it was >  bullstuff. Speakup
>>>> called > >  a function that did nothing -- which isn't the >
>>>> fault of the speakup > >  developers. I suspect that those
>>>> functions now do >  something -- > >  probably not what we want
>>>> but something.
>>>>>>>>    It has probably been a year since I last posted a rant
>>>> on this > >  list >  about the linux kernel developers. As I
>>>> write this, I find > >  myself >  getting all worked up about it
>>>> again. The one good thing > >  about Trump >  running for
>>>> President is that now I have someone I find > >  more arrogant >
>>>> and irritating than the linux kernel development > >  team.
>>>>>>>>>>    On 02/24/2016 08:29 AM, Tony Baechler wrote:
>>>>>>>>    On 2/23/2016 6:31 AM, John G Heim wrote:
>>>>>>>>>     You should check the syslog. There are almost
>>>> certainly > > messages > > in >    there
>>>>>>>>>     reporting what is happening. I'll try to compile
>>>> 4.3 kernels > > for > > ubuntu >    and
>>>>>>>>>     debian over the next few days. I had planned to
>>>> automate the > > > >   process. >  Every
>>>>>>>>>     time my ubuntu machines download a new kernel,
>>>> generate a > > new > > patched >    kernel
>>>>>>>>>     package. I never got around to it though. I was
>>>> using a sed > > > >   command to
>>>>>>>>>     comment out the line that caused serial synths to
>>>> not work > >  so that
>>>>>>>>>     automation was possible. Part of the problem here
>>>> is that I > > have > >   kind of
>>>>>>>>>     given up on serial synths myself. I have been
>>>> depending more > > and > >   more on >  the
>>>>>>>>>     combination of a braille display and software
>>>> speech. It > >  seems to > > me >   that
>>>>>>>>>     using a hardware speech synth is going against the
>>>> grain > > these > > >    days.
>>>>>>>>>>>>    As Karen and others have pointed out, we all
>>>> have our > >  own personal > >  speech
>>>>>>>>    preferences. In my case, I have multiple reasons for
>>>> wanting > > serial > >   speech
>>>>>>>>    to work. I find it easier to hear and understand for
>>>> one thing. > > There > >   are
>>>>>>>>    some bugs in the DECtalk Express module which might be
>>>> easily > >  fixed, > >  but
>>>>>>>>    the last unpatched kernel I know of that actually
>>>> worked was > >  2.6.32 > >  which
>>>>>>>>    is no longer supported. Anyway, as requested, here is
>>>> the dmesg > > > >   output. I
>>>>>>>>     don't see anything helpful. I did the following:
>>>>>>>>>>     service espeakup stop
>>>>>>>>     rmmod speakup_soft
>>>>>>>>     modprobe speakup_dectlk
>>>>>>>>     rmmod speakup_dectlk
>>>>>>>>     rmmod speakup
>>>>>>>>     modprobe speakup_soft
>>>>>>>>     espeakup
>>>>>>>>>>     [   11.336314] r8169 0000:02:00.0 eth0: link up
>>>>>>>>     [   11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0:
>>>> link > > becomes > >    ready
>>>>>>>>     [   27.013903] releasing synth soft
>>>>>>>>     [   27.013975] unregistered /dev/softsynth
>>>>>>>>     [   32.824006] speakup: unregistering synth device /dev/synth
>>>>>>>>     [   56.630004] speakup: module is from the staging
>>>> directory, > > the > >   quality
>>>>>>>>     is unknown, you have been warned.
>>>>>>>>     [   56.630896] input: Speakup as /devices/virtual/input/input7
>>>>>>>>     [   56.631031] initialized device: /dev/synth, node
>>>> (MAJOR 10, > > > >   MINOR 25)
>>>>>>>>     [   56.631055] speakup 3.1.6: initialized
>>>>>>>>     [   56.631057] synth name on entry is: dectlk
>>>>>>>>     [   56.639855] speakup_dectlk: module is from the
>>>> staging > > > >  directory, the
>>>>>>>>     quality is unknown, you have been warned.
>>>>>>>>     [   56.640036] synth probe
>>>>>>>>     [   56.640039] Ports not available, trying to steal them
>>>>>>>>     [   56.640042] Unable to allocate port at 3f8, errno -16
>>>>>>>>     [   56.640044] Dectalk Express: not found
>>>>>>>>     [   56.640045] dectlk: device probe failed
>>>>>>>>     [   67.012005] speakup: unregistering synth device /dev/synth
>>>>>>>>     [   70.985966] speakup: module is from the staging
>>>> directory, > > the > >   quality
>>>>>>>>     is unknown, you have been warned.
>>>>>>>>     [   70.986851] input: Speakup as /devices/virtual/input/input8
>>>>>>>>     [   70.986983] initialized device: /dev/synth, node
>>>> (MAJOR 10, > > > >   MINOR 25)
>>>>>>>>     [   70.987006] speakup 3.1.6: initialized
>>>>>>>>     [   70.987008] synth name on entry is: dectlk
>>>>>>>>     [   70.987055] speakup_soft: module is from the
>>>> staging > >  directory, > >   the
>>>>>>>>     quality is unknown, you have been warned.
>>>>>>>>     [   70.987193] synth probe
>>>>>>>>     [   70.987230] initialized device: /dev/softsynth,
>>>> node (MAJOR > >  10, > >  MINOR
>>>>>>>>    26)
>>>>>>>>    _______________________________________________
>>>>>>>    Speakup mailing list
>>>>>>>    Speakup@linux-speakup.org
>>>>>>>   http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>
>>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: Help with serial synths in 4.X kernels

[John G Heim]

Samuel,

Is your patch supposed to take the place of that lame patch I used to 
post that just commented out the return code? I cant get my tripletalk 
hardware speech synth to work. I edited /default/grub and added"

8250.nr_uarts=0". Then I compiled a kernel with your patch and installed it. But saying "modprobe speakup_ltlk" doesn't work and generates error messages in the syslog. I've cut/pasted them below. I am guessing the key line is the one that says, " Unable to allocate port at 3f8, errno -16".


Mar  4 13:35:03 vv507k kernel: [  138.527173] speakup_ltlk: module is 
from the staging directory, the quality is unknown, you have been warned.
Mar  4 13:35:03 vv507k kernel: [  138.527351] synth probe
Mar  4 13:35:03 vv507k kernel: [  138.527353] Ports not available, 
trying to steal them
Mar  4 13:35:03 vv507k kernel: [  138.527357] Trying to free nonexistent 
resource <00000000000003f8-00000000000003ff>
Mar  4 13:35:03 vv507k kernel: [  138.527358] Unable to allocate port at 
3f8, errno -16
Mar  4 13:35:03 vv507k kernel: [  138.527360] LiteTalk: not found
Mar  4 13:35:03 vv507k kernel: [  138.527361] ltlk: device probe failed



On 02/27/2016 03:07 PM, Samuel Thibault wrote:
> covici@ccs.covici.com, on Fri 26 Feb 2016 19:34:30 -0500, wrote:
>> But even with your patch, serial port access is not  available with
>> speakup.
> Yes, you also need to prevent the conflict between the 8250 driver and
> the speakup driver.
>
>> Also, if you set 8250.nr_uarts=0 what happens  to other serial
>> ports you may need for modems, or other applications?
> They won't be available.
>
> I'm sorry, but until somebody actually gets to take the time to
> implement solutions, that's all we have.
>
> Samuel
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: Help with serial synths in 4.X kernels

[Samuel Thibault]

Hello,

John G Heim, on Fri 04 Mar 2016 13:50:31 -0600, wrote:
> Is your patch supposed to take the place of that lame patch I used to post
> that just commented out the return code?

No. Both are needed.

> I edited /default/grub and added"
> 
> 8250.nr_uarts=0".

That, however, is supposed to save having to use the lame patch: it just
disables the 8250 driver which conflicts with speakup.

> Then I compiled a kernel with your patch and installed it. But saying "modprobe speakup_ltlk" doesn't work and generates error messages in the syslog. I've cut/pasted them below. I am guessing the key line is the one that says, " Unable to allocate port at 3f8, errno -16".

That's odd. Are you sure the 8250.nr_uarts=0 parameter is effective?
Check in /proc/cmdline and you can also check in /proc/ioports what
driver is keeping them busy.

Samuel

Re: Help with serial synths in 4.X kernels

[John G Heim]

I wrote a quick perl script to scan /proc/ioports for an address. It 
shows that the port 0x3f8 is within the range covered by this line from 
/proc/ioports:

0000-0cf7 : PCI Bus 0000:00

PS: I put the script where anyone can download it, 
http://www.math.wisc.edu/~jheim/debian/ioportscan. By default it scans 
for 0x3f8 but you cn pass any hex number as a parameter.



On 03/04/2016 05:19 PM, Samuel Thibault wrote:
> Hello,
>
> John G Heim, on Fri 04 Mar 2016 13:50:31 -0600, wrote:
>> Is your patch supposed to take the place of that lame patch I used to post
>> that just commented out the return code?
> No. Both are needed.
>
>> I edited /default/grub and added"
>>
>> 8250.nr_uarts=0".
> That, however, is supposed to save having to use the lame patch: it just
> disables the 8250 driver which conflicts with speakup.
>
>> Then I compiled a kernel with your patch and installed it. But saying "modprobe speakup_ltlk" doesn't work and generates error messages in the syslog. I've cut/pasted them below. I am guessing the key line is the one that says, " Unable to allocate port at 3f8, errno -16".
> That's odd. Are you sure the 8250.nr_uarts=0 parameter is effective?
> Check in /proc/cmdline and you can also check in /proc/ioports what
> driver is keeping them busy.
>
> Samuel

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: Help with serial synths in 4.X kernels

[Samuel Thibault]

John G Heim, on Thu 10 Mar 2016 16:43:21 -0600, wrote:
> I wrote a quick perl script to scan /proc/ioports for an address. It shows
> that the port 0x3f8 is within the range covered by this line from
> /proc/ioports:
> 
> 0000-0cf7 : PCI Bus 0000:00

Uh, ok. So the stealing can definitely not work here, commenting the
return line is the only option.

Samuel

USB synths (was: serial synths in 4.X kernels)

[John G Heim]

 >> Maybe my time would be better spent learning how to write
 >> a linux device driver for USB.
> >
> > Well, the drivers do exist already. What lacks so far is the connection
 > between them and the speakup.

Does speakup really have to do anything to talk to a USB synth? I've 
written udev rules to create device files for USB devices. When you plug 
in a USB device, the kernel sees it and creates a device file. You can 
watch the messages scroll by if you tail the syslog while plugging in 
the USB device. Then you can take the identification strings and write a 
udev rule to create another device file for that device. People do this 
all the time so that every time they plug their thumb drive in, it gets 
a name like /dev/thumb. What if I wrote a udev rule to create a 
/dev/speakup_ltlk and fooled speakup into thinking it had successfully 
loaded the speakup_ltlk module?

Re: USB synths (was: serial synths in 4.X kernels)

[Samuel Thibault]

John G Heim, on Fri 11 Mar 2016 12:59:40 -0600, wrote:
> >> Maybe my time would be better spent learning how to write
> >> a linux device driver for USB.
> >>
> >> Well, the drivers do exist already. What lacks so far is the connection
> > between them and the speakup.
> 
> Does speakup really have to do anything to talk to a USB synth?

Yes, it needs to be able to talk with the USB serial driver.

That's a recurring TODO item: see with kernel serial maintainers how
to do that properly. As I said before in another thread, an outreachy
intern is currently having a look.

Samuel

Re: USB synths

[John G Heim]

I wrote a udev rule to create a symlink to the device assigned to my 
tripletalk USB. But echoing a string doesn't make the synth speak the 
string like it does with the serial port. It generates a write error 
message. It's strange because the device file the kernel creates is a 
writable character special file.

The udev system isn't going to recognize a Tripletalk speech synth. It 
must be loading some generic device driver and even though the file has 
read/write permissions, you can't actually write to it.

On 03/11/2016 01:08 PM, Samuel Thibault wrote:
> John G Heim, on Fri 11 Mar 2016 12:59:40 -0600, wrote:
>>>> Maybe my time would be better spent learning how to write
>>>> a linux device driver for USB.
>>>>
>>>> Well, the drivers do exist already. What lacks so far is the connection
>>> between them and the speakup.
>> Does speakup really have to do anything to talk to a USB synth?
> Yes, it needs to be able to talk with the USB serial driver.
>
> That's a recurring TODO item: see with kernel serial maintainers how
> to do that properly. As I said before in another thread, an outreachy
> intern is currently having a look.
>
> Samuel

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: USB synths

[Chris Brannon]

John G Heim <jheim@math.wisc.edu> writes:

> The udev system isn't going to recognize a Tripletalk speech synth. It
> must be loading some generic device driver and even though the file
> has read/write permissions, you can't actually write to it.

The kernel provides a device node for each of your USB devices, but you
aren't really supposed to interact with those using the standard Unix
utilities.  They're used by libusb, which makes it possible to drive
USB devices directly from user space.  For instance, sane's USB scanner
drivers use libusb, and libusb communicates with the kernel via device nodes
under /dev/bus/usb.  I don't know much more about how libusb works
internally.  My understanding is kind of sketchy.

So what I'm saying is that those device nodes are only of interest if
you wanted to write a user-space programm using libusb to directly
interact with the TripleTalk.

-- Chris

Re: USB synths

[John G. Heim]

n 03/11/2016 04:17 PM, Chris Brannon wrote:
> The kernel provides a device node for each of your USB devices, but 
> you aren't really supposed to interact with those using the standard 
> Unix utilities. They're used by libusb, which makes it possible to 
> drive USB devices directly from user space. For instance, sane's USB 
> scanner drivers use libusb,


Do you know if the kernel uses a different system to interact with USB 
devices during boot? For example, during boot, the system knows that you 
have a USB keyboard.

Re: USB synths

[Chris Brannon]

"John G. Heim" <jheim@math.wisc.edu> writes:

> Do you know if the kernel uses a different system to interact with USB
> devices during boot? For example, during boot, the system knows that
> you have a USB keyboard.

I don't know for sure, but I don't think there's any special method
for interacting with USB devices at boot time.  A good deal of code
needs to be loaded and running before Linux can communicate with USB
devices.

-- Chris