* Serial conflict @ Jacob Schmude ` covici ` Chuck Hallenbeck 0 siblings, 2 replies; 24+ messages in thread From: Jacob Schmude @ UTC (permalink / raw) To: speakup -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Well, it's been a while but here I am again to stir up a bit of trouble. <grin> I'm attempting to use Speakup with a serial synthesizer on Archlinux with kernel 2.6.37.1-1 (2.6.37-ARCH is the in-kernel version number). Speakup is included in these kernels, but trying to load any of the speakup synthesizer drivers results in the following: synth probe Ports not available, trying to steal them Trying to free nonexistent resource <00000000000003f8-00000000000003ff> Unable to allocate port at 3f8, errno -16 LiteTalk: not found ltlk: device probe failed This happens with any serial synth I have, though obviously substitute the other driver names in these errors. I've tried the Doubletalk LT, Dectalk Express, and Accent SA (yes, all of which I do have). I get the same result whether I allow Speakup to probe or whether I specify a ser=0 parameter. I've trieed a few things. First, I tried unbinding the in-kernel serial driver from that port via sysfs, but there's no change although the port does seem to successfully unbind. Second, I searched the speakup archives and found a post from January detailing this problem, and the poster had success removing the return NULL statement at that point in serialio.c. This didn't work for me, however, and I'm not all that surprised it didn't. I've tried the staging speakup in the kernel, and with the latest git. The return NULL removal was attempted on the git source tree. Can anyone shed a bit of light on what I'm probably doing wrong? I can compile a custom kernel if necessary, though I was hoping not to need this. It worked in kernel 2.6.36, but obviously something critical has changed. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNbar4AAoJEDtK6CrF/Uo1IwEH/R7wM2GoBwVss4rtEzSSBbxC uUQox6uCAbOkvO1f6BualtyOkbFoyUrGcEinpA2vIlZ8avyPnucSCZd+ehNgtoWi vQjpnOsBKoEun7H41aJ42DojRhfdwBgeeXOJCT4Gxz63XWNjM+Uc/po/X9mz6qyG yYTEKBOuwGVQur+wKjMi3RLNhSxJwqhNxcfF+6uwTdixP8nq8wpDSuqj/z6PvdWj OaN4ew5O73hw3+C5y/nfnxFMkwQwn6ZMvApl/57EL5ZwAyF7dGMg2dRNkZWOlCiX pLAunnsZrbFDGuLLzD9s60bjAiDp60DMolYly989kvNLsuySgsxVEBNzrlrsqVk= =meVR -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict Serial conflict Jacob Schmude @ ` covici ` Jacob Schmude ` Chuck Hallenbeck 1 sibling, 1 reply; 24+ messages in thread From: covici @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Once you delete that return statement, you have to recompile the kernel -- in 2.6.37 I would using the staging driver instead of git. This works for me , at any rate. Jacob Schmude <j.schmude@gmail.com> wrote: > Hi all, > Well, it's been a while but here I am again to stir up a bit of > trouble. <grin> > I'm attempting to use Speakup with a serial synthesizer on Archlinux > with kernel 2.6.37.1-1 (2.6.37-ARCH is the in-kernel version number). > Speakup is included in these kernels, but trying to load any of the > speakup synthesizer drivers results in the following: > synth probe > Ports not available, trying to steal them > Trying to free nonexistent resource <00000000000003f8-00000000000003ff> > Unable to allocate port at 3f8, errno -16 > LiteTalk: not found > ltlk: device probe failed > > This happens with any serial synth I have, though obviously substitute > the other driver names in these errors. I've tried the Doubletalk LT, > Dectalk Express, and Accent SA (yes, all of which I do have). I get > the same result whether I allow Speakup to probe or whether I specify > a ser=0 parameter. > I've trieed a few things. First, I tried unbinding the in-kernel > serial driver from that port via sysfs, but there's no change although > the port does seem to successfully unbind. Second, I searched the > speakup archives and found a post from January detailing this problem, > and the poster had success removing the return NULL statement at that > point in serialio.c. This didn't work for me, however, and I'm not all > that surprised it didn't. > I've tried the staging speakup in the kernel, and with the latest git. > The return NULL removal was attempted on the git source tree. > Can anyone shed a bit of light on what I'm probably doing wrong? I can > compile a custom kernel if necessary, though I was hoping not to need > this. It worked in kernel 2.6.36, but obviously something critical has > changed. > > Thanks > > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` covici @ ` Jacob Schmude 0 siblings, 0 replies; 24+ messages in thread From: Jacob Schmude @ UTC (permalink / raw) To: speakup -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Doesn't work, unfortunately. I do have it sort of working with the git version (staging isn't working) but not the way it should be. Speakup and the kernel's serial driver constantly battle over it. Seriously, this is 2011. One would think we'd be over having to recompile kernels for things like this. On 03/01/2011 10:46 PM, covici@ccs.covici.com wrote: > Once you delete that return statement, you have to recompile the > kernel -- in 2.6.37 I would using the staging driver instead of > git. This works for me , at any rate. > > Jacob Schmude <j.schmude@gmail.com> wrote: > >> Hi all, Well, it's been a while but here I am again to stir up a >> bit of trouble. <grin> I'm attempting to use Speakup with a >> serial synthesizer on Archlinux with kernel 2.6.37.1-1 >> (2.6.37-ARCH is the in-kernel version number). Speakup is >> included in these kernels, but trying to load any of the speakup >> synthesizer drivers results in the following: synth probe Ports >> not available, trying to steal them Trying to free nonexistent >> resource <00000000000003f8-00000000000003ff> Unable to allocate >> port at 3f8, errno -16 LiteTalk: not found ltlk: device probe >> failed >> >> This happens with any serial synth I have, though obviously >> substitute the other driver names in these errors. I've tried the >> Doubletalk LT, Dectalk Express, and Accent SA (yes, all of which >> I do have). I get the same result whether I allow Speakup to >> probe or whether I specify a ser=0 parameter. I've trieed a few >> things. First, I tried unbinding the in-kernel serial driver from >> that port via sysfs, but there's no change although the port does >> seem to successfully unbind. Second, I searched the speakup >> archives and found a post from January detailing this problem, >> and the poster had success removing the return NULL statement at >> that point in serialio.c. This didn't work for me, however, and >> I'm not all that surprised it didn't. I've tried the staging >> speakup in the kernel, and with the latest git. The return NULL >> removal was attempted on the git source tree. Can anyone shed a >> bit of light on what I'm probably doing wrong? I can compile a >> custom kernel if necessary, though I was hoping not to need this. >> It worked in kernel 2.6.36, but obviously something critical has >> changed. >> >> Thanks >> >> >> _______________________________________________ Speakup mailing >> list Speakup@braille.uwo.ca >> http://speech.braille.uwo.ca/mailman/listinfo/speakup > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNbeoKAAoJEDtK6CrF/Uo18q0IAK4cf2bcXvvdzLF52erlDud4 Vg5QyMPjRkpr700NUpG0FN7/e6CpuPLjoYD3g/Kgeq0all/rPpMDDCH4If+IYPGH wEgNBITVB1tV7JZbN7ZGfEfb2lThrx9P8MKFFKinlvC3T2xcYYXrsN9tfgdGnN/J HMm/DK96js51xby6Ge/F4JxYo01cTQ66bVldphUf9mRsyfe4vPoS6MpRRPQl19c+ RHBjmt6XoyxXYY8R4RssIuTtYiyvyEy4w096IDn3VLrUYByblUjWOCBGcDpIucjp 7zSSislZEoJlpZaMEoTUW40kv0wKvIQAQRkLyEw0hJa86H/4pTlymMWrSDNhvhI= =xHmE -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict Serial conflict Jacob Schmude ` covici @ ` Chuck Hallenbeck ` Jacob Schmude 1 sibling, 1 reply; 24+ messages in thread From: Chuck Hallenbeck @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Jacob, My distro is identical to yours, also on a 64 bit machine, and here is how I configure speakup for both a software synthesizer and a serial synthesizer: 1. In /etc/rc.conf, my MODULES line looks like this: MODULES=(ipv6 speakup speakup_soft speakup_ltlk) 2. In /etc/modprobe.d/modprobe.conf, add these lines: options speakup_soft start=0 options speakup_ltlk ser=0 start=0 3. In /etc/rc.local, add these lines: # start talking talkwith soft espeakup speakupconf load In the last group, the talkwith command could specify either device, and once the syhstem is running, the talkwith command switches between devices gracefully, I use sudo to run it as root. Hope that elps. Chuck -- Chuck in Hudson. My website is hallenbeck.ftml.net, my Jabber ID is chuckh1@jabber.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Chuck Hallenbeck @ ` Jacob Schmude ` Steve Holmes 0 siblings, 1 reply; 24+ messages in thread From: Jacob Schmude @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chuck I wish it did, but I can't load any of the hardware synth modules. When I try, I get the serial conflict where by Speakup tries to steal the ports from the kernel and can't. I know how to configure Speakup and things like that, but I need to figure out what is going wrong with the serial driver before it will work. I'm horrible at kernel hacking, so I've only gotten it to half work where by the kernel and speakup battle for control of the port constantly. Speakup does talk when I have it do this, but responsiveness is awful. Using either an unchanged staging or clean git, however, just does not work. It is rather irritating, since it did work in 2.6.36 and, examining the configs for both kernels, I can't see anything that even remotely looks related to this. Thanks On 03/02/2011 03:01 AM, Chuck Hallenbeck wrote: > Jacob, > > My distro is identical to yours, also on a 64 bit machine, and here is > how I configure speakup for both a software synthesizer and a serial > synthesizer: > > 1. In /etc/rc.conf, my MODULES line looks like this: > > MODULES=(ipv6 speakup speakup_soft speakup_ltlk) > > 2. In /etc/modprobe.d/modprobe.conf, add these lines: > > options speakup_soft start=0 > options speakup_ltlk ser=0 start=0 > > 3. In /etc/rc.local, add these lines: > > # start talking > talkwith soft espeakup > speakupconf load > > In the last group, the talkwith command could specify either device, > and once the syhstem is running, the talkwith command switches between > devices gracefully, I use sudo to run it as root. > > Hope that elps. > > Chuck > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNboCGAAoJEDtK6CrF/Uo1X9kIAKujzbKsoJ+luB+GIOJ8KVWH AQgttbR8x/vfmpIRvbQOmP2153EI3yBl9WmC9ByySBcTr8ZbIKm1eakd5o43w768 nLmUYxxzTagzYak+rYoT0/FUVT6gIfR1AcDRhIgiJ1+8TpDSwIJ/6ZbN2QxXUpL4 FxCB9lV7tdRH2zE68L/T8VVSENz0ij+fBbm8isBbL6GnxyUvexAT6suyUu/nTbOM f/d3Tu7DS2EhOcki2hUoX26zfvAGi6ggmqnXx32NNkEsbMKL1DXILsez91Ql1Xo7 RfPYjaLTvDaGTiylr8H161EaCmczizKA5aoKBXyeSkA5pPc6+8XufhErIOc0sGk= =S5TH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Jacob Schmude @ ` Steve Holmes ` Jacob Schmude 0 siblings, 1 reply; 24+ messages in thread From: Steve Holmes @ UTC (permalink / raw) To: speakup Hi Jacob, I too use Arch Linux but also experience the same problem you do. Though I didn't get into messing with kernel details, I tried the solution that Chuck suggested in his previous message, but no joy for me either. My failure to get serials to work goes back to something like 2.6.34. 've been trying this with a Speakout, using the speakup_spkout driver. I thought someone told me that driver had a bug of some kind but I really would like to be able to use an external synthesizer, especially if software speech goes south when playing with pulse audio or other such evil things. I really wish we could get to the bottom of this serial problem since that used to be speakup's life blood. I think many of us are hoping the recent kernel integration might lead us to support in getting the serial support beefed up so you could even use USB or PCI serial ports and not be locked into the old ones which hardly exist anymore on most new computers. On Wed, Mar 02, 2011 at 09:38:21AM -0800, Jacob Schmude wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Chuck > I wish it did, but I can't load any of the hardware synth modules. > When I try, I get the serial conflict where by Speakup tries to steal > the ports from the kernel and can't. I know how to configure Speakup > and things like that, but I need to figure out what is going wrong > with the serial driver before it will work. I'm horrible at kernel > hacking, so I've only gotten it to half work where by the kernel and > speakup battle for control of the port constantly. Speakup does talk > when I have it do this, but responsiveness is awful. Using either an > unchanged staging or clean git, however, just does not work. It is > rather irritating, since it did work in 2.6.36 and, examining the > configs for both kernels, I can't see anything that even remotely > looks related to this. > > Thanks > > On 03/02/2011 03:01 AM, Chuck Hallenbeck wrote: > > Jacob, > > > > My distro is identical to yours, also on a 64 bit machine, and here is > > how I configure speakup for both a software synthesizer and a serial > > synthesizer: > > > > 1. In /etc/rc.conf, my MODULES line looks like this: > > > > MODULES=(ipv6 speakup speakup_soft speakup_ltlk) > > > > 2. In /etc/modprobe.d/modprobe.conf, add these lines: > > > > options speakup_soft start=0 > > options speakup_ltlk ser=0 start=0 > > > > 3. In /etc/rc.local, add these lines: > > > > # start talking > > talkwith soft espeakup > > speakupconf load > > > > In the last group, the talkwith command could specify either device, > > and once the syhstem is running, the talkwith command switches between > > devices gracefully, I use sudo to run it as root. > > > > Hope that elps. > > > > Chuck > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJNboCGAAoJEDtK6CrF/Uo1X9kIAKujzbKsoJ+luB+GIOJ8KVWH > AQgttbR8x/vfmpIRvbQOmP2153EI3yBl9WmC9ByySBcTr8ZbIKm1eakd5o43w768 > nLmUYxxzTagzYak+rYoT0/FUVT6gIfR1AcDRhIgiJ1+8TpDSwIJ/6ZbN2QxXUpL4 > FxCB9lV7tdRH2zE68L/T8VVSENz0ij+fBbm8isBbL6GnxyUvexAT6suyUu/nTbOM > f/d3Tu7DS2EhOcki2hUoX26zfvAGi6ggmqnXx32NNkEsbMKL1DXILsez91Ql1Xo7 > RfPYjaLTvDaGTiylr8H161EaCmczizKA5aoKBXyeSkA5pPc6+8XufhErIOc0sGk= > =S5TH > -----END PGP SIGNATURE----- > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Steve Holmes @ ` Jacob Schmude ` Steve Holmes ` Christopher Moore 0 siblings, 2 replies; 24+ messages in thread From: Jacob Schmude @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Steve I'm glad I'm not the only one, though I know that doesn't help. It's definitely not the speakout driver in this case. I don't have one, but I do have a doubletalk lt, accent sa, and dectalk express, all of which I've tried. I'd try my Keynote SA as well except Speakup doesn't support that one. I understand the hope of better serial support, though I think the logic is flawed. I remember once before when speakup/kernel integration was being pursued, and one of the reasons it didn't get in was because of its self-contained and ancient serial stack. However, expecting others to help--others who, I might add, don't need speakup and probably never will--is probably not going to gain results. If this is going to be done, it's going to be someone who needs speakup and has good kernel development skills, not some random kernel developer with nothing else to do. Things just don't work that way. I wish I could do it, but what I know about kernel hacking you could write on a 3 by 5 card in jumbo braille and still have blank space left over. <grin> Application programming is fine, but once I hit kernel land my head starts to hurt. On 03/02/2011 01:20 PM, Steve Holmes wrote: > Hi Jacob, > > I too use Arch Linux but also experience the same problem you do. > Though I didn't get into messing with kernel details, I tried the > solution that Chuck suggested in his previous message, but no joy > for me either. My failure to get serials to work goes back to > something like 2.6.34. 've been trying this with a Speakout, using > the speakup_spkout driver. I thought someone told me that driver > had a bug of some kind but I really would like to be able to use an > external synthesizer, especially if software speech goes south when > playing with pulse audio or other such evil things. > > I really wish we could get to the bottom of this serial problem > since that used to be speakup's life blood. I think many of us are > hoping the recent kernel integration might lead us to support in > getting the serial support beefed up so you could even use USB or > PCI serial ports and not be locked into the old ones which hardly > exist anymore on most new computers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNbrhSAAoJEDtK6CrF/Uo1VpoIAIacStbNQuDqqB6hViV3Pru8 fgsXELuFB7Vt3FKXYREXumLWyHQq1GCRxAPIoQbyC5oQaFYPbFSgVVXa7NRNk1jZ MigBzAIqtiW5ZBUqwf1R/VtiJS9pYirXqgDj9ZbJkFrkSvSIpqujMNju77dfvOjI an2VWw3qNE7Ol8iN3ptBxRW6NZ+CEvf2itNi8QFZGB+16ba2OZGsiatYRRtGfHq4 WBocSDf5QBuKIbBxUii9DrdiP50wlGAGiHB7A6RhtQaHYkPvdAaM9VyQqSRnTG7i 6kZ+H6TdyiAZkxPdMLE7DHWIXHeAWfRa1Gwy+GKLsc9h3a6RDuO9bbyeCla7cy0= =Jxjn -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Jacob Schmude @ ` Steve Holmes ` Christopher Brannon ` Christopher Moore 1 sibling, 1 reply; 24+ messages in thread From: Steve Holmes @ UTC (permalink / raw) To: speakup Yeah, mine too. I never delved into kernel programming either. Maybe it isn't all that hard but I don't know where to start in that world. The thing that bugs me here with the serial port problems is that this stuff seems to work on some people's machines and not on others. Where I run into serial issues is on a machine that apparently has 64 bit capability but at the time I built my Arch installation, I hadn't realized it so it is basically built as a 32 bit system (x86). Hey, I might try the speakup-enabled Arch live CD; wonderif I can override the speakup.synth parameter on that; never tried so far. Chris, can one do that with your live CD? if so, what name is used for the image or first word of the command line? I guess I could inspect the grub lines you have on that disk to figure that out. On Wed, Mar 02, 2011 at 01:36:21PM -0800, Jacob Schmude wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Steve > I'm glad I'm not the only one, though I know that doesn't help. It's > definitely not the speakout driver in this case. I don't have one, but > I do have a doubletalk lt, accent sa, and dectalk express, all of > which I've tried. I'd try my Keynote SA as well except Speakup doesn't > support that one. > I understand the hope of better serial support, though I think the > logic is flawed. I remember once before when speakup/kernel > integration was being pursued, and one of the reasons it didn't get in > was because of its self-contained and ancient serial stack. However, > expecting others to help--others who, I might add, don't need speakup > and probably never will--is probably not going to gain results. If > this is going to be done, it's going to be someone who needs speakup > and has good kernel development skills, not some random kernel > developer with nothing else to do. Things just don't work that way. I > wish I could do it, but what I know about kernel hacking you could > write on a 3 by 5 card in jumbo braille and still have blank space > left over. <grin> Application programming is fine, but once I hit > kernel land my head starts to hurt. > > > On 03/02/2011 01:20 PM, Steve Holmes wrote: > > Hi Jacob, > > > > I too use Arch Linux but also experience the same problem you do. > > Though I didn't get into messing with kernel details, I tried the > > solution that Chuck suggested in his previous message, but no joy > > for me either. My failure to get serials to work goes back to > > something like 2.6.34. 've been trying this with a Speakout, using > > the speakup_spkout driver. I thought someone told me that driver > > had a bug of some kind but I really would like to be able to use an > > external synthesizer, especially if software speech goes south when > > playing with pulse audio or other such evil things. > > > > I really wish we could get to the bottom of this serial problem > > since that used to be speakup's life blood. I think many of us are > > hoping the recent kernel integration might lead us to support in > > getting the serial support beefed up so you could even use USB or > > PCI serial ports and not be locked into the old ones which hardly > > exist anymore on most new computers. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJNbrhSAAoJEDtK6CrF/Uo1VpoIAIacStbNQuDqqB6hViV3Pru8 > fgsXELuFB7Vt3FKXYREXumLWyHQq1GCRxAPIoQbyC5oQaFYPbFSgVVXa7NRNk1jZ > MigBzAIqtiW5ZBUqwf1R/VtiJS9pYirXqgDj9ZbJkFrkSvSIpqujMNju77dfvOjI > an2VWw3qNE7Ol8iN3ptBxRW6NZ+CEvf2itNi8QFZGB+16ba2OZGsiatYRRtGfHq4 > WBocSDf5QBuKIbBxUii9DrdiP50wlGAGiHB7A6RhtQaHYkPvdAaM9VyQqSRnTG7i > 6kZ+H6TdyiAZkxPdMLE7DHWIXHeAWfRa1Gwy+GKLsc9h3a6RDuO9bbyeCla7cy0= > =Jxjn > -----END PGP SIGNATURE----- > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Steve Holmes @ ` Christopher Brannon ` Steve Holmes 0 siblings, 1 reply; 24+ messages in thread From: Christopher Brannon @ UTC (permalink / raw) To: speakup Steve Holmes <steve@holmesgrown.com> writes: > might try the speakup-enabled Arch live CD; wonderif I can override > the speakup.synth parameter on that; never tried so far. There's no speakup.synth parameter. It just loads the softsynth module and starts espeakup. -- Chris ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Christopher Brannon @ ` Steve Holmes 0 siblings, 0 replies; 24+ messages in thread From: Steve Holmes @ UTC (permalink / raw) To: speakup On Thu, Mar 03, 2011 at 04:24:44PM +0000, Christopher Brannon wrote: > There's no speakup.synth parameter. It just loads the softsynth module > and starts espeakup. Oh, so there's no way to override the startup boot options like other live media? I thought that was a native function of the kernel. But if those other modules aren't loaded in the initial RAMFS, maybe that wouldn't be possible. I was just thinking if one wanted to try out serial support at boot time. No big deal here but I thought it would be interesting to try. > -- Chris > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Jacob Schmude ` Steve Holmes @ ` Christopher Moore ` Zachary Kline ` speakup in user space (was Re: Serial conflict) Jacob Schmude 1 sibling, 2 replies; 24+ messages in thread From: Christopher Moore @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Hello, Here's another thought: Suppose we did away with all the hardware synth modules in speakup. All interaction with speakup could be done through the /dev/softsyn device. This would require converting the hardware modules to user-space programs which would communicate with speakup over the /dev/softsyn device and to the hardware synth over the /dev/tts serial device. What I'm suggesting is to remove serial port support from speakup since it appears to be problematic at best. Chris ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Christopher Moore @ ` Zachary Kline ` Albert Sten-Clanton ` Frost ` speakup in user space (was Re: Serial conflict) Jacob Schmude 1 sibling, 2 replies; 24+ messages in thread From: Zachary Kline @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. This is an excellent suggestion, if at all practical. If we did this it might also let us handle USB serial ports and the like with ease, since we'd then be in userspace. Hope we can make something of it, Zack. On Mar 4, 2011, at 8:10 AM, Christopher Moore wrote: > Hello, > Here's another thought: Suppose we did away with all the hardware synth modules in speakup. All interaction with speakup could be done through the /dev/softsyn device. This would require converting the hardware modules to user-space programs which would communicate with speakup over the /dev/softsyn device and to the hardware synth over the /dev/tts serial device. > > What I'm suggesting is to remove serial port support from speakup since it appears to be problematic at best. > > Chris > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Serial conflict ` Zachary Kline @ ` Albert Sten-Clanton ` David Csercsics ` Frost 1 sibling, 1 reply; 24+ messages in thread From: Albert Sten-Clanton @ UTC (permalink / raw) To: 'Speakup is a screen review system for Linux.' Would this influence how early in the boot-up Speakup could kick in using a hardware synthesizer? I'm sorry to say I know nothing about this area. Thanks! Al -----Original Message----- From: speakup-bounces@braille.uwo.ca [mailto:speakup-bounces@braille.uwo.ca] On Behalf Of Zachary Kline Sent: Friday, March 04, 2011 11:12 AM To: Speakup is a screen review system for Linux. Subject: Re: Serial conflict This is an excellent suggestion, if at all practical. If we did this it might also let us handle USB serial ports and the like with ease, since we'd then be in userspace. Hope we can make something of it, Zack. On Mar 4, 2011, at 8:10 AM, Christopher Moore wrote: > Hello, > Here's another thought: Suppose we did away with all the hardware synth modules in speakup. All interaction with speakup could be done through the /dev/softsyn device. This would require converting the hardware modules to user-space programs which would communicate with speakup over the /dev/softsyn device and to the hardware synth over the /dev/tts serial device. > > What I'm suggesting is to remove serial port support from speakup since it appears to be problematic at best. > > Chris > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup _______________________________________________ Speakup mailing list Speakup@braille.uwo.ca http://speech.braille.uwo.ca/mailman/listinfo/speakup ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Albert Sten-Clanton @ ` David Csercsics 0 siblings, 0 replies; 24+ messages in thread From: David Csercsics @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. On Fri, Mar 04, 2011 at 12:16:38PM -0500, Albert Sten-Clanton wrote: > Would this influence how early in the boot-up Speakup could kick in using a > hardware synthesizer? I'm sorry to say I know nothing about this area. It shouldn't provided we keep the userspace programs small enough to be contained nicely on a ramfs. This is what the kernel's early userspace stuff is designed for. Going to make building custom kernels a bit more of a pain and there will need to be init scripts to start the synth program back up after the system has properly transferred control to the real root file system but you could make that happen very early so you'd only lose speech for less than a second unless there's some error or other with the boot process which likely means you'll need to pull out your rescue CD to fix it anyway. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Zachary Kline ` Albert Sten-Clanton @ ` Frost ` covici 1 sibling, 1 reply; 24+ messages in thread From: Frost @ UTC (permalink / raw) To: speakup On Fri, Mar 04, 2011 at 08:12:23AM -0800, Zachary Kline wrote: > This is an excellent suggestion, if at all practical. If we did this > it might also let us handle USB serial ports and the like with ease, > since we'd then be in userspace. Then what's the point of getting SpeakUP into the kernel. And what about "power-of to power-off support. How is ANY blind linux user going to manage to fsck a disk when needed. We might as well go back to friggin yasr. We just got SpeakUP into the kernel and may soon be getting support from other kernel developers to support serial ports properly from kernelspace, and you want to ditch it all and go back to prehistoric SpeakUP and scratching at fleas. You people disgust me. Michael -- Linux User: 177869 # Powered By: Intel # http://rivensight.dyndns.org Postings Copyrighted 2010-2011 by: Michael Ferranti ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Serial conflict ` Frost @ ` covici 0 siblings, 0 replies; 24+ messages in thread From: covici @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. I agree, don't take speakup out of the kernel -- I had something the other day, where I had the wrong ramdisk version and it would not load any modules, but I had speakup -- since my synth is built into the kernel and was able to figure out what happened -- if speakup were in user space I would have been sunk. But how about the following -- can we put a notify into the serial synth initialization so speakup would know when things were happening and could simulate an open for whatever device, or steal the port before the serial synth could do anything -- prefer the former if possible. Frost <znvyyvfgf@gmail.com> wrote: > On Fri, Mar 04, 2011 at 08:12:23AM -0800, Zachary Kline wrote: > > This is an excellent suggestion, if at all practical. If we did this > > it might also let us handle USB serial ports and the like with ease, > > since we'd then be in userspace. > > Then what's the point of getting SpeakUP into the kernel. And > what about "power-of to power-off support. How is ANY blind linux user > going to manage to fsck a disk when needed. We might as well go back to > friggin yasr. > > We just got SpeakUP into the kernel and may soon be getting > support from other kernel developers to support serial ports properly > from kernelspace, and you want to ditch it all and go back to > prehistoric SpeakUP and scratching at fleas. > > You people disgust me. > > Michael > > -- > Linux User: 177869 # Powered By: Intel # http://rivensight.dyndns.org > Postings Copyrighted 2010-2011 by: Michael Ferranti > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* speakup in user space (was Re: Serial conflict) ` Christopher Moore ` Zachary Kline @ ` Jacob Schmude ` William Hubbs 1 sibling, 1 reply; 24+ messages in thread From: Jacob Schmude @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi If that were done, why have Speakup in the kernel at all? Software speech cannot be included in the kernel itself, and this would mean that hardware speech would not be able to kick in as early if needed. Also, we would then be under the limitations of user-space programs in that when a kernel panic happens, we may not be able to review it whether we're using hardware synthesizers or not. If we were to go this route, my suggestion would be to get Speakup out of the kernel entirely and convert the whole thing to user-space. I'd use an approach similar to BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything more than if serial support were removed, and the integration problems with various distributions would be completely gone. No kernel conflicts, no module versioning, none of that. It would also remove the necessity for middleware between speakup and software speech. The only reason I think Speakup was in the kernel in the first place was the advantage it gave hardware synthesizers as far as early boot sequences and reading even the worst kernel panics (remember hardware speech was the only option in Linux back then). Take that away, and we might as well take Speakup out of the kernel and move the whole thing into user-space, since that would remove the one and only advantage for speakup being in kernel-space. To be clear, I'm not against moving speakup into user-space. In fact, I think it would be for the best in the long run, but there's no need to keep any of it in the kernel if we do. On 03/04/2011 08:10 AM, Christopher Moore wrote: > Hello, > Here's another thought: Suppose we did away with all the hardware > synth modules in speakup. All interaction with speakup could be > done through the /dev/softsyn device. This would require converting > the hardware modules to user-space programs which would communicate > with speakup over the /dev/softsyn device and to the hardware synth > over the /dev/tts serial device. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNcSomAAoJEDtK6CrF/Uo1OxkH/irNp/uXpnlpNnhBa1CQ3SBD SoURw4o4QKI3ik85Ym7gtj0Z1CufSyKNocY7M5wDfDfAZmfkN37wdeFSwWcLeioM eJCpakaCmvs5WN7HW5bn50l8kh0GybNtxCSdRfXNN/xLEhCnP85IuXStqahesNvJ wcqljpGEgm8CCdM4tLxykPN+j6A5mG/p1NW5Dx+QKM33WwXZFkY6rM8VR8//0gJM 8JKKrnEbrvUjaDOY7vVHlhEzcZKUb+T8dZMTtkcegISKqi7elIogGCuNngHjesXi p2SogGa3m023ozuZW3E/MikVIZ/67H8Onr+e0maWWluQg26xwNA1T+8KAwHUOSA= =wn0H -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` speakup in user space (was Re: Serial conflict) Jacob Schmude @ ` William Hubbs ` Jacob Schmude 0 siblings, 1 reply; 24+ messages in thread From: William Hubbs @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > If that were done, why have Speakup in the kernel at all? Software > speech cannot be included in the kernel itself, and this would mean > that hardware speech would not be able to kick in as early if needed. > Also, we would then be under the limitations of user-space programs in > that when a kernel panic happens, we may not be able to review it > whether we're using hardware synthesizers or not. > If we were to go this route, my suggestion would be to get Speakup out > of the kernel entirely and convert the whole thing to user-space. I'd > use an approach similar to BRLTTY, using the /dev/vcsa devices. WE > wouldn't lose anything more than if serial support were removed, and > the integration problems with various distributions would be > completely gone. No kernel conflicts, no module versioning, none of > that. It would also remove the necessity for middleware between > speakup and software speech. SBL uses the vcsa devices. I attempted to use this screen reader, but I found very quickly that it doesn't work the way we expect screen readers to work. For example, if you type the date command, the next thing you hear read back to you is the command prompt. You are required to use the screen review mode to find the output from the command and read it. As I understand it, this is a limitation of the vcsa devices. The closest thing as I understand it to a user space screen reader that really works is yasr, but you have to be logged in to use that. William ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` William Hubbs @ ` Jacob Schmude ` Steve Holmes ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Jacob Schmude @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I don't think that's a limitation of the VCSA devices themselves, but rather how they are used. These devices show the screen as it currently is at any given time, although documentation for them is rather sparse. But couldn't we, rather than querying the device, monitor it instead for incoming text? I'll do some digging and see what I can find out. It just seems that to have speakup in the kernel even after removing serial support would leave us with all of the problems with none of the advantages remaining. On 03/04/2011 10:52 AM, William Hubbs wrote: > On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Hi If that were done, why have Speakup in the kernel at all? >> Software speech cannot be included in the kernel itself, and this >> would mean that hardware speech would not be able to kick in as >> early if needed. Also, we would then be under the limitations of >> user-space programs in that when a kernel panic happens, we may >> not be able to review it whether we're using hardware >> synthesizers or not. If we were to go this route, my suggestion >> would be to get Speakup out of the kernel entirely and convert >> the whole thing to user-space. I'd use an approach similar to >> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything >> more than if serial support were removed, and the integration >> problems with various distributions would be completely gone. No >> kernel conflicts, no module versioning, none of that. It would >> also remove the necessity for middleware between speakup and >> software speech. > > SBL uses the vcsa devices. I attempted to use this screen reader, > but I found very quickly that it doesn't work the way we expect > screen readers to work. For example, if you type the date command, > the next thing you hear read back to you is the command prompt. You > are required to use the screen review mode to find the output from > the command and read it. As I understand it, this is a limitation > of the vcsa devices. > > The closest thing as I understand it to a user space screen reader > that really works is yasr, but you have to be logged in to use > that. > > William > > _______________________________________________ Speakup mailing > list Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNcVF1AAoJEDtK6CrF/Uo1Lk0H/i6q5fKxDiCYLo3dNO9djAtT aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1 MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO v1xj2oKZOCUBEIjlZhLXYOdyOPPmLLLpwKSfFHDICwMcTeNAxVbg1bDSOWiETlw= =zJ6i -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` Jacob Schmude @ ` Steve Holmes ` Kyle ` Jason White ` Ari Moisio 2 siblings, 1 reply; 24+ messages in thread From: Steve Holmes @ UTC (permalink / raw) To: speakup I've always preferred the kernel-based solution and find it to be so responsive and fast and I remember the days of early access to deal with kernel panics and similar stuff. The forced fsck's that come up from time to time also can be tracked earlier with speakup in the kernel with good hardware support. I do miss that when using software speech. I understand the advantages of user-space solutions and I always thought a combination could really give a super experience. Have basic support in the kernel and have user space stuff to provide for things like keyboard-macros, flexible speak windows and stuff. I really wish we could fix the serial support stuff as that was a land-mark feature of speakup in the past. The fact that it is basically broken on most machines is particularly disturbing. Why it works on some machines and not others, really bugs me! I wish I had the expertese to help here. On Fri, Mar 04, 2011 at 12:54:15PM -0800, Jacob Schmude wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > I don't think that's a limitation of the VCSA devices themselves, but > rather how they are used. These devices show the screen as it > currently is at any given time, although documentation for them is > rather sparse. But couldn't we, rather than querying the device, > monitor it instead for incoming text? I'll do some digging and see > what I can find out. > It just seems that to have speakup in the kernel even after removing > serial support would leave us with all of the problems with none of > the advantages remaining. > > > > On 03/04/2011 10:52 AM, William Hubbs wrote: > > On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote: > >> > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > >> Hi If that were done, why have Speakup in the kernel at all? > >> Software speech cannot be included in the kernel itself, and this > >> would mean that hardware speech would not be able to kick in as > >> early if needed. Also, we would then be under the limitations of > >> user-space programs in that when a kernel panic happens, we may > >> not be able to review it whether we're using hardware > >> synthesizers or not. If we were to go this route, my suggestion > >> would be to get Speakup out of the kernel entirely and convert > >> the whole thing to user-space. I'd use an approach similar to > >> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything > >> more than if serial support were removed, and the integration > >> problems with various distributions would be completely gone. No > >> kernel conflicts, no module versioning, none of that. It would > >> also remove the necessity for middleware between speakup and > >> software speech. > > > > SBL uses the vcsa devices. I attempted to use this screen reader, > > but I found very quickly that it doesn't work the way we expect > > screen readers to work. For example, if you type the date command, > > the next thing you hear read back to you is the command prompt. You > > are required to use the screen review mode to find the output from > > the command and read it. As I understand it, this is a limitation > > of the vcsa devices. > > > > The closest thing as I understand it to a user space screen reader > > that really works is yasr, but you have to be logged in to use > > that. > > > > William > > > > _______________________________________________ Speakup mailing > > list Speakup@braille.uwo.ca > > http://speech.braille.uwo.ca/mailman/listinfo/speakup > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJNcVF1AAoJEDtK6CrF/Uo1Lk0H/i6q5fKxDiCYLo3dNO9djAtT > aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M > fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1 > MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo > Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO > v1xj2oKZOCUBEIjlZhLXYOdyOPPmLLLpwKSfFHDICwMcTeNAxVbg1bDSOWiETlw= > =zJ6i > -----END PGP SIGNATURE----- > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` Steve Holmes @ ` Kyle 0 siblings, 0 replies; 24+ messages in thread From: Kyle @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Just my $0.02, unless things have changed recently, Speakup needs much better USB support. Speaking from the perspective of having a machine that doesn't have a serial port, and more and more machines are built that way now, USB is certainly the way to go. In the very near future, this will be entirely necessary, as motherboards with serial ports are becoming harder and harder to find, and most available plug-in serial ports are USB adapters. ~Kyle ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` Jacob Schmude ` Steve Holmes @ ` Jason White ` Jason White ` Ari Moisio 2 siblings, 1 reply; 24+ messages in thread From: Jason White @ UTC (permalink / raw) To: speakup Jacob Schmude <speakup@braille.uwo.ca> wrote: >I don't think that's a limitation of the VCSA devices themselves, but >rather how they are used. These devices show the screen as it >currently is at any given time, although documentation for them is >rather sparse. But couldn't we, rather than querying the device, >monitor it instead for incoming text? I'll do some digging and see >what I can find out. Even if the VCSA devices have such a limitation, you could propose changes to overcome it, or write a relatively simple kernel module just to expose the necessary information and implement the screen reader itself in user space. >It just seems that to have speakup in the kernel even after removing >serial support would leave us with all of the problems with none of >the advantages remaining. As I understand the situation, keystrokes can be intercepted from user space as well now; support for this was integrated into BRLTTY relatively recently. If I were designing a screen reader for Linux, I wouldn't put it in the kernel unless there were really no workable alternative. If I had to touch the kernel, it would be by way of a minimal driver just to provide the necessary interfaces. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` Jason White @ ` Jason White 0 siblings, 0 replies; 24+ messages in thread From: Jason White @ UTC (permalink / raw) To: speakup Just one point of clarification here: Jason White <speakup@braille.uwo.ca> wrote: >If I were designing a screen reader for Linux, I wouldn't put it in the kernel >unless there were really no workable alternative. If I had to touch the >kernel, it would be by way of a minimal driver just to provide the necessary >interfaces. The above isn't meant as a criticism of the Speakup design, which may have been the best of the available options when it was decided upon. My point, rather, is that in today's environment there are very limited benefits to be obtained from implementing the entire screen reader in the kernel. If your kernel panics and you have a serial synthesizer, then there's an added benefit, provided that Speakup is still running after the crash. Linux supports other means of reporting kernel panics, kexec, serial cosnole, network console, and so on. Thus I'm not convinced of the importance of this particular scenario. Speakup can theoretically start very early in the boot process, but the advantage really only accrues if it is compiled into the kernel image. If it's a module, then you'll need the initrd image to be loaded before it starts, as will be the case in just about every distribution these days. In that circumstance, however, you can just as easily load a user-space screen reader in the initrd image. Hardware-based speech synthesizers are undoubtedly on the way out, and have been so for at least a decade, quite aside from the issues associated with serial port access that have given rise to this discussion. I'm an outsider to the Speakup "community", and not really qualified to assess all of the alternatives. >From my perspective, this will head in either of two possible directions. 1. Speakup developers will write kernel code to access the kernel's support for serial devices (including serial to USB converters) to solve the hardware synthesizer problem; likewise, support will be provided for synthesizers with USB interfaces. I don't know whether there is likely to be pressure from the kernel community suggesting that the whole project should be in user-space and hence it should not be accepted into the mainline. I'm not making this argument, just suggesting that it could be raised when the time comes to move Speakup out of staging and into the kernel proper. This could be a barrier to final merging, depending on the criteria applied in making that decision. 2. Alternatively, a decision will be taken to move the entire implementation, or most of it, into user space, possibly leaving behind a small kernel module if the existing interfaces don't provide everything that is needed. Obviously there'll be plenty of code rewriting involved if this option is taken up. I suppose part of the question to be considered is: how hard would it be to pursue option 1, and is that really the best way to proceed over the long term? One could argue that there's a marginal advantage in certain corner cases of a kernel-based implementation and that there's a solution here which works now, and which, moreover, has done so since the late 90s. On the other hand, an implementation in user-space can't bring down your entire system in the same way that a kernel module can, all of the device support provided by the kernel is available via /dev through interfaces that will continue to be supported; there's the possibility of supporting some of the user-space terminal emulators (such as that used by the Debian installer) if a suitable API is created; working with user-space speech servers etc., is straightforward; the implementation of the screen reader may be less complex, etc. Ultimately it's the developers of Speakup who will collectively decide how it evolves from here. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: speakup in user space (was Re: Serial conflict) ` Jacob Schmude ` Steve Holmes ` Jason White @ ` Ari Moisio 2 siblings, 0 replies; 24+ messages in thread From: Ari Moisio @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Hi I have made a screen reader that almost relies on the /dev/vcsa devices. There are also options to read everything that an application spits out to stdout but only application i have found this useful is teh bc calculator. There is also a mode to read changing content on the screen but it's not very usefull either, only when monitoring slowly changin status pages. This screen reader works completely in the user space and will start after use has logged in. Application will capture keyboard input and application output bu starting a new shel and tapping to it's stdin and stdout. Not very elegant solutions but it works for me. The source code is awful mess and both comment in the code are in finnish:-( -- mr. M01510 & guide Loadstone-GPS hkp://wwwkeys.pgp.net B784D020 0C1F 6A76 DC9D DD58 3383 8B5D 0E76 9600 B784 D02 On Fri, 4 Mar 2011, Jacob Schmude wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > I don't think that's a limitation of the VCSA devices themselves, but > rather how they are used. These devices show the screen as it > currently is at any given time, although documentation for them is > rather sparse. But couldn't we, rather than querying the device, > monitor it instead for incoming text? I'll do some digging and see > what I can find out. > It just seems that to have speakup in the kernel even after removing > serial support would leave us with all of the problems with none of > the advantages remaining. > > > > On 03/04/2011 10:52 AM, William Hubbs wrote: >> On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> Hi If that were done, why have Speakup in the kernel at all? >>> Software speech cannot be included in the kernel itself, and this >>> would mean that hardware speech would not be able to kick in as >>> early if needed. Also, we would then be under the limitations of >>> user-space programs in that when a kernel panic happens, we may >>> not be able to review it whether we're using hardware >>> synthesizers or not. If we were to go this route, my suggestion >>> would be to get Speakup out of the kernel entirely and convert >>> the whole thing to user-space. I'd use an approach similar to >>> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything >>> more than if serial support were removed, and the integration >>> problems with various distributions would be completely gone. No >>> kernel conflicts, no module versioning, none of that. It would >>> also remove the necessity for middleware between speakup and >>> software speech. >> >> SBL uses the vcsa devices. I attempted to use this screen reader, >> but I found very quickly that it doesn't work the way we expect >> screen readers to work. For example, if you type the date command, >> the next thing you hear read back to you is the command prompt. You >> are required to use the screen review mode to find the output from >> the command and read it. As I understand it, this is a limitation >> of the vcsa devices. >> >> The closest thing as I understand it to a user space screen reader >> that really works is yasr, but you have to be logged in to use >> that. >> >> William >> >> _______________________________________________ Speakup mailing >> list Speakup@braille.uwo.ca >> http://speech.braille.uwo.ca/mailman/listinfo/speakup > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJNcVF1AAoJEDtK6CrF/Uo1Lk0H/i6q5fKxDiCYLo3dNO9djAtT > aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M > fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1 > MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo > Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO > v1xj2oKZOCUBEIjlZhLXYOdyOPPmLLLpwKSfFHDICwMcTeNAxVbg1bDSOWiETlw= > =zJ6i > -----END PGP SIGNATURE----- > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup > ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~ UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
Serial conflict Jacob Schmude
` covici
` Jacob Schmude
` Chuck Hallenbeck
` Jacob Schmude
` Steve Holmes
` Jacob Schmude
` Steve Holmes
` Christopher Brannon
` Steve Holmes
` Christopher Moore
` Zachary Kline
` Albert Sten-Clanton
` David Csercsics
` Frost
` covici
` speakup in user space (was Re: Serial conflict) Jacob Schmude
` William Hubbs
` Jacob Schmude
` Steve Holmes
` Kyle
` Jason White
` Jason White
` Ari Moisio
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).