-----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-----
