>On Mon, Dec 08, 2008 at 04:46:37PM -0600, Brian Cameron wrote: >> >Is there a shortcomming in VT here? >> >> I guess it depends on how you think VT should work. My understanding >> is that VT works on a first-come-first-serve basis, so the first user >> who calls logindevperm interfaces gets permission. While it might seem >> nicer for the last user to get the device, this is much harder to manage. > >No, I think audio should be virtualized. The current session should >have access to the real audio hardware, and the others should not be >able to produce sound (though as afar as apps go, they shouldn't know >the difference).
I think we talked about this at the time but in the end we made a vt subsystem which works like others do. But I agree with you. It doesn't necessarily virtualizing /dev/audio, adding but adding $AUDIODEV to the environment of such a session. (E.g., /dev/vt/sound/...). At this time, it seems that the last one to login gets /dev/sound? >> Making it work the other way would require logindevperm to be enhanced. > >Perhaps. It will also require virtualizing the audio device. And possibly not, because a simple rule can be used if we give the virtualized audio a different device node. >When I switch away from a session where programs are producing sound >what should happen is this: a) those programs continue to operate, b) >but they don't produce actual sound until I switch back to that VT (and >unlock the screen). I'm not sure why the programs should stop; it's just as valid to throw the output away. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
