[oss-devel] ossxmix patch to ignore empty mixer groups

[Yair K.]

On Thursday 05 June 2008 23:24:05 Hannu Savolainen wrote:
> Hi all,
> 
> There are some bugs in the current hdaudio driver that may cause empty 
> groups. The driver will create a new group after adding 4 to 8 controls 
> to the group. The purpose of this hack is to prevent the mixer screen 
> from becoming too wide. Unfortunately the driver may after that figure 
> out that none of the remaining controls are connected to anywhere. This 
> will leave unused groups.
> 
> One solution might be moving this logic to ossxmix. The driver will 
> create just one group and ossxmix will break it to multiple "lines" if 
> the current box is getting too wide. Would that be implementable?

I think this is implementable though not trivial:
1. Get width (I think this is related to gdk_screen_get_width (GTK >= 2.2), and use some X function for other case?). I don't know if this works on more exotic configurations (Xinerama?), but I suspect it does.
2. Check constantly in load_devinfo that adding a control won't get past the width.
3. If so, decide to move/split group downward.
4. Gtk only has concept of Horizontal/Vertical boxes. We'll have to recreate some of the box hierarchy in order to get it lower.

> The mixer API is developing to a direction where drivers can create 
> empty groups in advance and the populate them later "on demand". This 
> may cause problems if ossmix just throws away all groups it thinks are 
> empty. It is acceptable if the group h/vboxes are not shown until 
> something is created inside them.

At the moment, the only way I know of to discover whether new control have been added with the current API is to poll the device for total number of mixers (via SNDCTL_MIX_NREXT) and to compare this to the previous number (this is what ossxmix does for VMIX). If so, than the groups may be ignored/throwed away and it won't matter.

(BTW, If controls can also be removed, and not just added, than there's an edge case:
  A. Total number can be the same even in a case of change. (1-1=0)
  B. ossxmix polls the controls, if all the newly added mixers have the same control numbers than get_value won't fail and the display won't be reloaded.

 Not sure how to really fix this: A separate flag in SNDCTL_MIXERINFO to inform of such changes? Or maybe changing a group's modify_counter in SNDCTL_MIX_EXTINFO?)

Yours,
	Yair K.