two problems installing software speech with speakup

[Charles Hallenbeck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gary,

On Thu, Jun 29, 2006 at 06:31:11PM -0400, Gary Cramblitt wrote:
> 
> Are you saying that sftsyn cannot be loaded as a module and *must* be compiled 
> into the kernel, or is it a matter of forcing a load of the sftsyn module 
> (/etc/modules) and properly configuring udev?

As I understand it, speakup itself is either a module or a 
built-into-the-kernel item, and each device driver is also either 
compiled as a module or a built-in component. If a device is to be used 
immediately upon startup, both speakup and the relevant driver MUST be 
built in, and not modules. But the other drivers, perhaps to be invoked 
after system startup, might go either way, That is the case with sftsyn, 
since it cannot be invoked until after the speech-dispatcher package and 
the synthesis engines it uses have been activated. When speakup switches 
drivers, it does so by echoing the desired river name to a variable in 
the /proc/speakup area, which triggers a modprobe if necessary, or a 
simpler switch to a built-in driver, depending on how the kernel was 
configured at compile time. If sftsyn is a module, this is when the 
/dev/synth device needs to be registered (created), and so udev must 
have already been informed about the matter at some earlier point. Here 
is the relevant passage from the readme.debian file from the udev 
package:

- ----

Short summary: when a driver is loaded it makes some information available
in /sys/ and a message is sent to udevd which reads them and creates the
appropriate devices.

This means that:
- - modules cannot be loaded on demand when applications open their device,
  because the device is not yet there!
- - since modules are not loaded on demand, if for some reason the drivers
  cannot be automatically loaded at boot time you will have to add them
  to /etc/modules.

- -----

I have not tried adding sftsyn to /etc/modules. Perhaps that would be a 
simpler solution than compiling it into the kernel. But the reliance on 
dynamically loading and unloading the module when needed seems to cause 
udev to fail to know how to create the needed device.

This is mostly way over my head. Perhaps there is a better solution than 
the one I found, but I simply noticed that one of my systems had it 
built in and the other had it as a module, and the first worked while 
the second did not.

Chuck


- -- 
The Moon is Waxing Crescent (17% of Full)
Get downloads from http://www.mhcable.com/~chuckh
  and remember, INFORMATION WANTS TO BE FREE!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEpFo9XnuiIOyDVQURAuXjAKC0KVJrIy88EEgpPv9Rk4jBEtP8iwCeNqyq
0GTj6nYCrAMpu/mZCuOKX+g=
=vBkJ
-----END PGP SIGNATURE-----