Re: spkr vs spkr_synth module

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 10,  9:02am, paul%whooppee.com@localhost (Paul Goyette) wrote:
-- Subject: spkr vs spkr_synth module

| I'm not sure if it's really correct to have the modules/spkr_synth.kmod 
| file contain a module named "spkr".  It makes the modload/modunload 
| asymmetrical (modload spkr_synth vs modunload spkr), and makes it hard 
| to determine, from the output of modstat(8), which module is actually 
| loaded.
| 
| I'm tempted to rearrange things, but I'm concerned about potential 
| confusion.
| 
| 1. Rename i386/amd64-only spkr module to spkr_pcppi and adjust the
|     module name accordingly.
| 2. Rename spkr_synch module to spkr (leaving the module name alone).
| 3. Leave the device-autoload stuff alone, so the default will be to
|     autoload the audio-based spkr module!
| 4. Add spkr, and mark spkr_synth obsolete in the modules/mi sets list;
|     in the i384 and amd64 sets lists, rename spkr --> spkr_pcppi (do
|     NOT mark the old spkr entry as "obsolete" since it will still exist
|     based on the mi file).
| 5. If someone really wants to use the spkr_pcppi module, they will
|     need to manually load, or include it in the kernel config (and
|     remove spkr_synth).
| 
| Thoughts?

I think first we should eliminate the VAUDIOSPEAKER option.
Why does speaker_attach_mi exists? when autoconf calls spkrattach in
the spkr_sync case, the parent is audio0...

Also the wskbd code can just check that bell != NULL and call the bell
stuff else do the normal thing, only in the bell function and nothing else
needs to change...

Or am I missing something?

christos