Mention EXAMPLES section in mixer_get_nmixers().

Update mixer_get_nmixers() entry in mixer.3.

Address Florian's comments.

In D45256#1032818, @dev_submerge.ch wrote:

In D45256#1032314, @christos wrote:

@dev_submerge.ch I am not really sure if we can implement this in SNDCTL_ENGINEINFO as well. In SNDCTL_ENGINEINFO we choose an "engine"/channel on a device that is already opened, so in the case of an unavailable device, we won't be able to open it in the first place.

There's no 1:1 mapping from engines (virtual channels) to pcm devices anyway. I think the only thing we care about with SNDCTL_ENGINEINFO is that applications can iterate them using numaudioengines as expected.

Merged with D45256.

Merge with D45150.

Address Mark's comments.

D45275 and D45276.

Address Mark's comment.

In D45150#1030208, @dev_submerge.ch wrote:

In D45150#1030167, @christos wrote:

In D45150#1029983, @dev_submerge.ch wrote:

We're missing a piece of the puzzle, as mixer_oss_mixerinfo() still skips unavailable devices. Which means SNDCTL_MIXERINFO returns an error instead of a device with enabled == 0, thus breaking the ossinfo utility from audio/oss, and probably other software using the same approach.

That's right. So before I implement this I want to make sure we agree on what each oss_mixerinfo field should contain:

dev	loop counter
id	mixer<loop counter> (unavailable)
name	Perhaps something like pcm<loop_counter>:mixer (unavailable)
modify_counter	0
card_number	loop counter
port_number	0
enabled	0
caps	Not supported.
nrext	Not supported.
priority	Not supported.
devnode	Nothing.
legacy_device	loop counter

I am not really sure whether we want to include the mixer name in id and name or simply leave it blank, or unavailable.

I would include the mixer name both in id and name, as those fields may be shown to the user in a list of mixer devices. It's more obvious than leaving them blank. I think your suggested strings are fine, except that id is only 16 bytes. Maybe mixer<loop counter> (n/a)?

The other values look good to me.

Also, in oss_mixerinfo() there are two cases where we can skip a device:

1. if (!PCM_REGISTERED(d) || PCM_DETACHING(d))
2. if (d->mixer_dev != NULL && d->mixer_dev->si_drv1 != NULL && ((mi->dev == -1 && d->mixer_dev == i_dev) || mi->dev == i))

I think it's better to handle both cases the same way, that is, return a structure with the values described above, instead of handling them differently.

Not sure I understand the question here. I think I would use ((mi->dev == -1 && d->mixer_dev == i_dev) || mi->dev == i) as an outer if to select the requested device, and then the other indicators to decide whether the requested device is available or not. Does that make sense?

Add locking around loop in AUDIOINFO. Haven't addressed Florian's comments yet.

@dev_submerge.ch I am not really sure if we can implement this in SNDCTL_ENGINEINFO as well. In SNDCTL_ENGINEINFO we choose an "engine"/channel on a device that is already opened, so in the case of an unavailable device, we won't be able to open it in the first place.

Address brooks' comments.

In D45237#1032029, @dev_submerge.ch wrote:

The current check is never false and If nvlist_unpack(), we might panic later down the road.

Commit message should probably be "... if nvlist_unpack() fails, ..."?

Address brooks' comment.

In D45236#1031986, @brooks wrote:

You need to decide the type of data based on the command passed before you examine it so you'll need a case statement before the tests. I'd also tend not to assign the arg/arg32 until you've decided the type. Additionally, data will be NULL for at least SNDSTIOC_REFRESH_DEVS and SNDSTIOC_FLUSH_USER_DEVS,

Also it seems like this fallback mechanism is needed by a few other ioctls, so I think it's better to fix all of them in a single patch.

In D45150#1029983, @dev_submerge.ch wrote:

In D45150#1029901, @christos wrote:

@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.

The mixer does see devices now that come after the unavailable ones. But it shows no device description for it.

We're missing a piece of the puzzle, as mixer_oss_mixerinfo() still skips unavailable devices. Which means SNDCTL_MIXERINFO returns an error instead of a device with enabled == 0, thus breaking the ossinfo utility from audio/oss, and probably other software using the same approach.

@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.