Re: spkr vs spkr_synth module

[Nathanial Sloss <nat%netbsd.org@localhost>]

On Mon, 12 Dec 2016 21:01:28 Paul Goyette wrote:
> On Sat, 10 Dec 2016, Christos Zoulas wrote:
> > 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.
> 
> You already did this, right?
> 
> > 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?
> 
> Nat, can you respond to these?

As for the module I think more platforms have audio than pcppi, so that spkr 
synth should be the prominent one.

And as for wskbd I was thinking that the bell function should use the speaker 
ioctl. Opening /dev/speaker would either use pcppi or spkr_synth if they were 
available.

Best regards,

Nat.