On Thu, Mar 07, 2024 at 08:26:46AM -0300, Crystal Kolipe wrote:
> On Thu, Mar 07, 2024 at 11:33:54AM +0100, Alexandre Ratchov wrote:
> > This diff adds a "display string" to sndio controls, and starts using
> > it to report the device names of the server.device control. Ex:
> > 
> > $ sndioctl
> > output.level=1.000
> > output.mute=0
> > server.device=6(uaudio2)
> > 
> > $ sndioctl -i server.device
> > server.device=0(azalia0),2(envy0),3(envy1),4(uaudio0),5(uaudio1),6(uaudio2)
> > 
> > Above strings are simply the driver names. The plan is to change the
> > low-level drivers to report the chipset, the vendor/product name, the
> > codec models, or whatever appropriate; there are preliminary diffs for
> > this.
> 
> With this first version of the code, these strings are unique.  Do we
> intend to guarantee this when the names are expanded to include further
> chipset information?
> 

You're right, the display strings can't be unique,
unfortunately. Furthermore, currently they are not stable with time.

> If not, should we mention this somewhere to avoid userland code relying
> on behaviour that will change later on?
> 

Sure. Something like this?

--- a/libsndio/sioctl_open.3
+++ b/libsndio/sioctl_open.3
@@ -244,6 +244,7 @@ The
 .Fa display
 attribute contains an optional free-format string providing additional
 hints about the control, like the hardware model, or the units.
+It is neither unique at a given time, no stable with time.
 .Ss Changing and reading control values
 Controls are changed with the
 .Fn sioctl_setval