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