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.

[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.

Post by Tony Baechler
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
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.
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.

[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

Post by 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.

Post by Tony Baechler
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
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.
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Tony Baechler]

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)

[c***@ccs.covici.com]

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

Post by Tony Baechler

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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

Post by Tony Baechler

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
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)

[c***@ccs.covici.com]

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.

Post by 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.

Post by Tony Baechler

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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

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

Post by 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.

Post by John G Heim
You should check the syslog. There are almost certainly messages

in > there

Post by John G Heim
reporting what is happening. I'll try to compile 4.3 kernels for

ubuntu > and

Post by John G Heim
debian over the next few days. I had planned to automate the

process. > Every

Post by John G Heim
time my ubuntu machines download a new kernel, generate a new

patched > kernel

Post by John G Heim
package. I never got around to it though. I was using a sed

command to

Post by John G Heim
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

Post by John G Heim
given up on serial synths myself. I have been depending more and

more on > the

Post by John G Heim
combination of a braille display and software speech. It seems to

me > that

Post by John G Heim
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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[c***@ccs.covici.com]

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.

Post by 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.

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

Post by 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.

Post by John G Heim
You should check the syslog. There are almost certainly

messages in > there

Post by John G Heim
reporting what is happening. I'll try to compile 4.3 kernels

for ubuntu > and

Post by John G Heim
debian over the next few days. I had planned to automate the

process. > Every

Post by John G Heim
time my ubuntu machines download a new kernel, generate a new

patched > kernel

Post by John G Heim
package. I never got around to it though. I was using a sed

command to

Post by John G Heim
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

Post by John G Heim
given up on serial synths myself. I have been depending more

and more on > the

Post by John G Heim
combination of a braille display and software speech. It seems

to me > that

Post by John G Heim
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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

Post by c***@ccs.covici.com
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.

Post by 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.

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

Post by 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.

Post by John G Heim
You should check the syslog. There are almost certainly

messages in > there

Post by John G Heim
reporting what is happening. I'll try to compile 4.3 kernels

for ubuntu > and

Post by John G Heim
debian over the next few days. I had planned to automate the

process. > Every

Post by John G Heim
time my ubuntu machines download a new kernel, generate a new

patched > kernel

Post by John G Heim
package. I never got around to it though. I was using a sed

command to

Post by John G Heim
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

Post by John G Heim
given up on serial synths myself. I have been depending more

and more on > the

Post by John G Heim
combination of a braille display and software speech. It seems

to me > that

Post by John G Heim
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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[c***@ccs.covici.com]

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.

Post by 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.

Post by c***@ccs.covici.com
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.

Post by 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.

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

Post by 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.

Post by John G Heim
You should check the syslog. There are almost certainly

messages in > there

Post by John G Heim
reporting what is happening. I'll try to compile 4.3 kernels

for ubuntu > and

Post by John G Heim
debian over the next few days. I had planned to automate the

process. > Every

Post by John G Heim
time my ubuntu machines download a new kernel, generate a new

patched > kernel

Post by John G Heim
package. I never got around to it though. I was using a sed

command to

Post by John G Heim
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

Post by John G Heim
given up on serial synths myself. I have been depending more

and more on > the

Post by John G Heim
combination of a braille display and software speech. It seems

to me > that

Post by John G Heim
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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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?

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

Post by 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.

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

Post by 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.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim

Post by John G Heim
You should check the syslog. There are almost certainly

messages > > in > there

Post by John G Heim

Post by John G Heim

Post by John G Heim
reporting what is happening. I'll try to compile 4.3 kernels

for > > ubuntu > and

Post by John G Heim

Post by John G Heim

Post by John G Heim
debian over the next few days. I had planned to automate the

process. > Every

Post by John G Heim
time my ubuntu machines download a new kernel, generate a

new > > patched > kernel

Post by John G Heim

Post by John G Heim

Post by John G Heim
package. I never got around to it though. I was using a sed

command to

Post by John G Heim
comment out the line that caused serial synths to not work

so that

Post by John G Heim

Post by John G Heim

Post by John G Heim
automation was possible. Part of the problem here is that I

have > > kind of

Post by John G Heim

Post by John G Heim

Post by John G Heim
given up on serial synths myself. I have been depending more

and > > more on > the

Post by John G Heim

Post by John G Heim

Post by John G Heim
combination of a braille display and software speech. It

seems to > > me > that

Post by John G Heim

Post by John G Heim

Post by John G Heim
using a hardware speech synth is going against the grain

these > > > days.

Post by John G Heim

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by Tony Baechler
As Karen and others have pointed out, we all have our

own personal > > speech

Post by John G Heim

Post by John G Heim
preferences. In my case, I have multiple reasons for wanting

serial > > speech

Post by John G Heim

Post by John G Heim
to work. I find it easier to hear and understand for one thing.

There > > are

Post by John G Heim

Post by John G Heim
some bugs in the DECtalk Express module which might be easily

fixed, > > but

Post by John G Heim

Post by John G Heim
the last unpatched kernel I know of that actually worked was

2.6.32 > > which

Post by John G Heim

Post by John G Heim
is no longer supported. Anyway, as requested, here is the dmesg
output. I

Post by John G Heim

Post by Tony Baechler
service espeakup stop

rmmod speakup_soft
modprobe speakup_dectlk
rmmod speakup_dectlk
rmmod speakup
modprobe speakup_soft
espeakup

Post by John G Heim

Post by Tony Baechler
[ 11.336314] r8169 0000:02:00.0 eth0: link up

[ 11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link

becomes > > ready

Post by John G Heim

Post by John G Heim
[ 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

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
quality is unknown, you have been warned.
[ 70.987193] synth probe
[ 70.987230] initialized device: /dev/softsynth, node (MAJOR

10, > > MINOR

Post by John G Heim

Post by John G Heim
26)
_______________________________________________

Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

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?

Post by 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?

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

Post by John G Heim
Well, as I said, I've been relying more and more upon a braille

display > and software speech.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
May i ask how one finds contingency plans for your ears, your

brain, > > and

Post by John G Heim

Post by John G Heim
your processing? smiles.
I am not following this debate closely, but it certainly

supports my

Post by John G Heim

Post by John G Heim
worries about Linux as a main computing solution. If someone

is > > going to

Post by John G Heim

Post by John G Heim
remove the door to functionality, or decide for me how I

personally

Post by John G Heim

Post by John G Heim
accommodate my body differences, then they are no different

than say

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
best access uses a foundation allowing for many ways in so to

speak.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Going back to the corner now,

Kare

Post by Tony Baechler

Post by 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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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 -- >

Post by John G Heim
probably not what we want but something.

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
You should check the syslog. There are almost certainly

messages > > in > there

Post by Tony Baechler

Post by John G Heim
reporting what is happening. I'll try to compile 4.3

kernels > > for > > ubuntu > and

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
debian over the next few days. I had planned to

automate the > > > > process. > Every

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
time my ubuntu machines download a new kernel, generate

a > > new > > patched > kernel

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
package. I never got around to it though. I was using a

sed > > > > command to

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
comment out the line that caused serial synths to not

work > > so that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
automation was possible. Part of the problem here is

that I > > have > > kind of

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
given up on serial synths myself. I have been depending

more > > and > > more on > the

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
combination of a braille display and software speech.

It > > seems to > > me > that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
using a hardware speech synth is going against the

grain > > these > > > days.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler

Post by Tony Baechler
As Karen and others have pointed out, we all have

our > > own personal > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

preferences. In my case, I have multiple reasons for

wanting > > serial > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

to work. I find it easier to hear and understand for one

thing. > > There > > are

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

some bugs in the DECtalk Express module which might be

easily > > fixed, > > but

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

the last unpatched kernel I know of that actually worked

was > > 2.6.32 > > which

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

is no longer supported. Anyway, as requested, here is the

dmesg > > > > output. I

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler
service espeakup stop

rmmod speakup_soft
modprobe speakup_dectlk
rmmod speakup_dectlk
rmmod speakup
modprobe speakup_soft
espeakup

Post by John G Heim

Post by Tony Baechler
[ 11.336314] r8169 0000:02:00.0 eth0: link up

[ 11.336325] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link

becomes > > ready

Post by Tony Baechler

[ 27.013903] releasing synth soft
[ 27.013975] unregistered /dev/softsynth
[ 32.824006] speakup: unregistering synth device

/dev/synth

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 56.630004] speakup: module is from the staging

directory, > > the > > quality

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

is unknown, you have been warned.
[ 56.630896] input: Speakup as

/devices/virtual/input/input7

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 56.631031] initialized device: /dev/synth, node

(MAJOR 10, > > > > MINOR 25)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 70.985966] speakup: module is from the staging

directory, > > the > > quality

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

is unknown, you have been warned.
[ 70.986851] input: Speakup as

/devices/virtual/input/input8

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 70.986983] initialized device: /dev/synth, node

(MAJOR 10, > > > > MINOR 25)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by Tony Baechler

quality is unknown, you have been warned.
[ 70.987193] synth probe
[ 70.987230] initialized device: /dev/softsynth, node

(MAJOR > > 10, > > MINOR

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

26)
_______________________________________________

Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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

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?

Post by 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?

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

Post by John G Heim
Well, as I said, I've been relying more and more upon a

braille display > and software speech.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
May i ask how one finds contingency plans for your ears,

your brain, > > and

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
best access uses a foundation allowing for many ways in so to speak.

Post by Tony Baechler

Going back to the corner now,

Kare

Post by Tony Baechler

Post by 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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
You should check the syslog. There are almost

certainly > > messages > > in > there

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
reporting what is happening. I'll try to compile

4.3 kernels > > for > > ubuntu > and

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
debian over the next few days. I had planned to

automate the > > > > process. > Every

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
time my ubuntu machines download a new kernel,

generate a > > new > > patched > kernel

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
package. I never got around to it though. I was

using a sed > > > > command to

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
comment out the line that caused serial synths to

not work > > so that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
automation was possible. Part of the problem here

is that I > > have > > kind of

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
given up on serial synths myself. I have been

depending more > > and > > more on > the

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
combination of a braille display and software

speech. It > > seems to > > me > that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
using a hardware speech synth is going against the

grain > > these > > > days.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler

Post by Tony Baechler
As Karen and others have pointed out, we all

have our > > own personal > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

preferences. In my case, I have multiple reasons for

wanting > > serial > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

to work. I find it easier to hear and understand for

one thing. > > There > > are

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

some bugs in the DECtalk Express module which might be

easily > > fixed, > > but

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

the last unpatched kernel I know of that actually

worked was > > 2.6.32 > > which

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

is no longer supported. Anyway, as requested, here is

the dmesg > > > > output. I

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler
service espeakup stop

rmmod speakup_soft
modprobe speakup_dectlk
rmmod speakup_dectlk
rmmod speakup
modprobe speakup_soft
espeakup

Post by John G Heim

Post by Tony Baechler
[ 11.336314] r8169 0000:02:00.0 eth0: link up

link > > becomes > > ready

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

quality is unknown, you have been warned.
[ 70.987193] synth probe
[ 70.987230] initialized device: /dev/softsynth,

node (MAJOR > > 10, > > MINOR

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

26)
_______________________________________________

Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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

[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

Post by 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

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?

Post by 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?

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

Post by John G Heim
Well, as I said, I've been relying more and more upon a

braille display > and software speech.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
May i ask how one finds contingency plans for your ears,

your brain, > > and

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
best access uses a foundation allowing for many ways in so to speak.

Post by Tony Baechler

Going back to the corner now,

Kare

Post by Tony Baechler

Post by 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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
You should check the syslog. There are almost

certainly > > messages > > in > there

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
reporting what is happening. I'll try to compile

4.3 kernels > > for > > ubuntu > and

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
debian over the next few days. I had planned to

automate the > > > > process. > Every

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
time my ubuntu machines download a new kernel,

generate a > > new > > patched > kernel

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
package. I never got around to it though. I was

using a sed > > > > command to

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
comment out the line that caused serial synths to

not work > > so that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
automation was possible. Part of the problem here

is that I > > have > > kind of

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
given up on serial synths myself. I have been

depending more > > and > > more on > the

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
combination of a braille display and software

speech. It > > seems to > > me > that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
using a hardware speech synth is going against the

grain > > these > > > days.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler

Post by Tony Baechler
As Karen and others have pointed out, we all

have our > > own personal > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

preferences. In my case, I have multiple reasons for

wanting > > serial > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

to work. I find it easier to hear and understand for

one thing. > > There > > are

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

some bugs in the DECtalk Express module which might be

easily > > fixed, > > but

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

the last unpatched kernel I know of that actually

worked was > > 2.6.32 > > which

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

is no longer supported. Anyway, as requested, here is

the dmesg > > > > output. I

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler
service espeakup stop

rmmod speakup_soft
modprobe speakup_dectlk
rmmod speakup_dectlk
rmmod speakup
modprobe speakup_soft
espeakup

Post by John G Heim

Post by Tony Baechler
[ 11.336314] r8169 0000:02:00.0 eth0: link up

link > > becomes > > ready

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

quality is unknown, you have been warned.
[ 70.987193] synth probe
[ 70.987230] initialized device: /dev/softsynth,

node (MAJOR > > 10, > > MINOR

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

26)
_______________________________________________

Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

Post by 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

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?

Post by 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?

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

Post by John G Heim
Well, as I said, I've been relying more and more upon a

braille display > and software speech.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
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.

Post by John G Heim

Post by John G Heim
May i ask how one finds contingency plans for your ears,

your brain, > > and

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
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

Post by John G Heim

Post by John G Heim
best access uses a foundation allowing for many ways in so to speak.

Post by Tony Baechler

Going back to the corner now,

Kare

Post by Tony Baechler

Post by 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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
You should check the syslog. There are almost

certainly > > messages > > in > there

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
reporting what is happening. I'll try to compile

4.3 kernels > > for > > ubuntu > and

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
debian over the next few days. I had planned to

automate the > > > > process. > Every

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
time my ubuntu machines download a new kernel,

generate a > > new > > patched > kernel

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
package. I never got around to it though. I was

using a sed > > > > command to

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
comment out the line that caused serial synths to

not work > > so that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
automation was possible. Part of the problem here

is that I > > have > > kind of

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
given up on serial synths myself. I have been

depending more > > and > > more on > the

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
combination of a braille display and software

speech. It > > seems to > > me > that

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim
using a hardware speech synth is going against the

grain > > these > > > days.

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler

Post by Tony Baechler
As Karen and others have pointed out, we all

have our > > own personal > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

preferences. In my case, I have multiple reasons for

wanting > > serial > > speech

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

to work. I find it easier to hear and understand for

one thing. > > There > > are

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

some bugs in the DECtalk Express module which might be

easily > > fixed, > > but

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

the last unpatched kernel I know of that actually

worked was > > 2.6.32 > > which

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

is no longer supported. Anyway, as requested, here is

the dmesg > > > > output. I

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

Post by John G Heim

Post by Tony Baechler
service espeakup stop

rmmod speakup_soft
modprobe speakup_dectlk
rmmod speakup_dectlk
rmmod speakup
modprobe speakup_soft
espeakup

Post by John G Heim

Post by Tony Baechler
[ 11.336314] r8169 0000:02:00.0 eth0: link up

link > > becomes > > ready

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

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)

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

[ 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

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

quality is unknown, you have been warned.
[ 70.987193] synth probe
[ 70.987230] initialized device: /dev/softsynth,

node (MAJOR > > 10, > > MINOR

Post by John G Heim

Post by John G Heim

Post by Tony Baechler

26)
_______________________________________________

Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

Date: Wed, 24 Feb 2016 10:44:51
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.

Post by Tony Baechler

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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

--

[John G Heim]

The hardware might be available but that doesn't mean it will work with
the linux kernel.

Post by 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.

Date: Wed, 24 Feb 2016 10:44:51
Speakup is a screen review system for Linux.
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.

Post by Tony Baechler

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
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[c***@ccs.covici.com]

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.

Post by 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
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.
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
Phone: [phone] SMS text: 1-619-375-2545
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[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.

Post by c***@ccs.covici.com
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.

[c***@ccs.covici.com]

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.

Post by 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.

Post by c***@ccs.covici.com
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Hello,

Post by c***@ccs.covici.com
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

[c***@ccs.covici.com]

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?

Post by Samuel Thibault
Hello,

Post by c***@ccs.covici.com
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)
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Post by c***@ccs.covici.com
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.

Post by c***@ccs.covici.com
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

[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

Post by Samuel Thibault

Post by c***@ccs.covici.com
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.

Post by c***@ccs.covici.com
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Hello,

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]

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.

Post by Samuel Thibault
Hello,

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

[Samuel Thibault]

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
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

[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?

[Samuel Thibault]

Post by 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?

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]

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.

Post by Samuel Thibault

Post by 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?

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

[Chris Brannon]

Post by John G Heim
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

[John G. Heim]

Post by Chris Brannon
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.

[Chris Brannon]

Post by John G. Heim
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

[c***@ccs.covici.com]

What is outreachy intern?

Post by Samuel Thibault
Hello,

Post by c***@ccs.covici.com
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
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Post by c***@ccs.covici.com
What is outreachy intern?

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