Mike:
This resolves my concerns about processes running as root inadvertently doing bad things or being tricked into doing bad things.
Good, thanks.
It's strange that the Xsession logic respects $AUDIODEV but the PostSession logic does not. That seems unlikely to produce the correct results if $AUDIODEV is ever set to something other than /dev/audio. Of course it's not easy to get hold of the session's $AUDIODEV in the PostSession context.
That is true. I can't think of any straightforward way to address this. That said, users who are using such alternative interfaces could create a $HOME/.audioctl/audioctl-(host)-(device) file by hand and have it loaded on subsequent logins. So loading the file in the Xsession script may be of some value to users who want to create the file by hand.
You could do something like iterate over all of the stored audio setting files for this machine, but I wonder whether this is just more trouble than it's worth for the intended use case and you might reasonably just wire both scripts to operate on /dev/audio. (Subject to the check that that device is owned by this session's user, of course.) I don't feel strongly either way; my main concern was the running-as-root issue, and that's been addressed.
This is really intended to be a workaround for the common-use case. Many users complain that their audio settings are not preserved well on reboot. While this solution is not perfect and does not work well if users have multiple audio devices, I think it will provide reasonable temporary relief for most users. Brian _______________________________________________ opensolaris-arc mailing list [email protected]
