Help with serial synths in 4.X kernels

John G Heim jheim at math.wisc.edu
Wed Feb 24 16:46:04 EST 2016


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

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

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



More information about the Speakup mailing list