On Thursday 24 July 2008 23:13:08 Hannu Savolainen wrote: > Better way might be using a MIXF_HOTPLUG flag. For groups it means that > new controls/groups might be added (or removed) to the group > any time. The root group (MIXT_DEVROOT) is an example of such group. > New controls/groups may appear under it for examole when vmix is > attached to the device.
First, the attached patch reverts most of the previous change which was ill
thought out by me. Two changes were left in: ossmix's changes are useful
anyway, and ossxmix will still skip groups with update_counter == 0.
The problem with MIXF_HOTPLUG/etc. is that we end up reading almost the same
info as we would have without it existing, especially since we can't directly
tell what a group's "leafs" are with the API.
For example, the case of adding a control: Since the mixer program can't know
what the "leafs" are, it has to assume the newly added mixers are at :
NREXT(prev).. NREXT(new) regardless of MIXF_HOTPLUG, so it may as well poll
NREXT in the first place to discover controls were added/removed (otherwise, it
could have used EXTINFO->update_counter, though I'm not sure it's actually a
win). The mixer program then has to iterate (using EXTINFO) the newly added
mixers to know which UI widget to assign to them. So it may as well check
EXTINFO->parent and use that - the MIXF_HOTPLUG info doesn't help here either.
The case of removing a control or of MIXF_UNAVAILABLE is probably better
served by erroring on MIX_READ and using an errno value which indicates that
the control no longer exists but the mixer is still valid (since the mixer
program will poll the control anyway).
Yours,
Yair K.
oss-revert-mixer-change.diff.gz
Description: GNU Zip compressed data
_______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
