Hi. This is true. I just odn't have my box here right now so I can look at the sourcecode. However, what I was looking for was exactly how Speakup initializes itself during the boot process. For example, how is Speakup able to start first in the boot sequence? Are the routines for rs232 communication for external synths defined in speakup.h? ----- Original Message ----- From: 'Georgina' <gena@xxxxxxxxxx> To: <speakup at braille.uwo.ca> Sent: Monday, June 17, 2002 6:19 AM Subject: Re: speakup question > Hi > > I don't understand, you can view the source and for those synthesisers > that are not supported, perhaps you could get the specs and write > drivers yourself. > > Have you tried to ask Kirk specific questions? > > Gena > > > > Blindness Advocacy and Self Help Online www.bashonline.org > > >Hi John. This is all correct, however as far as I know the synthesizer = > >driver is what's up before anything else. It would be nice to have = > >documentation on exactly what Speakup does at boot time i.e., = > >synthesizer driver initialization, etc. This would help me a lot in my = > >development, however such docs don't seem to be available. Looks like = > >I'll have to dig up everything by hand.=20 > >----- Original Message -----=20 > >From: John covici <covici at ccs.covici.com> > >To: <speakup at braille.uwo.ca> > >Sent: Sunday, June 16, 2002 9:10 PM > >Subject: speakup question > > > > > >> The problem is that speakup needs to be alive before modules, before > >> a file system and before much of anything except the console is > >> around. > >>=20 > >> I understand Kirk is working on a scheme to allow modules, but if its > >> a Dectalk pc, it won't talk at boot, but will have to wait till a > >> file is downloaded into it (at least that is my understanding, I > >> don't have one of those). > >>=20 > >> on Sunday 06/16/2002 Igor Gueths(igueths at attbi.com) wrote > >> > Hi all. Does anyone know why Speakup doesn't use the standard = > >conventions when designing kernel modules? In other words, why are the = > >drivers not modularized? Because my plan at least for the dectalk driver = > >was to write the standard module code, and then dump the rest of the = > >driver-specific code into the new re-written version. I am doing this = > >for two reasons. 1. I want to keep the changes as error free as = > >possible. 2. I don't want to have problems after writing new code. And I = > >think most of the driver is fine the way it is. I have other reasons for = > >modularizing the driver, including a project I am currently working on = > >that requires this.=20 > >> >=20 > >> >=20 > >> > _______________________________________________ > >> > Speakup mailing list > >> > Speakup at braille.uwo.ca > >> > http://speech.braille.uwo.ca/mailman/listinfo/speakup > >>=20 > >> --=20 > >> John Covici > >> covici at ccs.covici.com > >>=20 > >> _______________________________________________ > >> Speakup mailing list > >> Speakup at braille.uwo.ca > >> http://speech.braille.uwo.ca/mailman/listinfo/speakup > >>=20 > > > > > >_______________________________________________ > >Speakup mailing list > >Speakup at braille.uwo.ca > >http://speech.braille.uwo.ca/mailman/listinfo/speakup > > _______________________________________________ > Speakup mailing list > Speakup at braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup
