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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx > >>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > >>>> > >>>> > >> _______________________________________________ > >> Speakup mailing list > >> Speakup@xxxxxxxxxxxxxxxxx > >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > >> > > _______________________________________________ > Speakup mailing list > Speakup@xxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxx _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
