Colin Guthrie wrote: > 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: >> I wrote down a few use cases here, I'm sure there are more: >> >> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio > > For user Foo, the sound card sounds like it's dedicated for Foo. If this > is the case the a udev rule should be written to ensure that only Foo > has ACL rights on this file and any console-kit udev-acl callouts are > ignored. That makes sense, thanks. I added that reply to the blueprint. > For user Bar, I feel this is invalid. Why should user Bar have the right > to output a sound any more than he has the right to display a popup > window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? > If either scenario is to be supported, then what I > suggested elsewhere in this thread is still valid I reckon. i.e > something needs to be run as the active user that acts as an agent for > some kind of (system?) service that actually generates said alarm. The > agent will be running as the active user and it will be responsible for > playing the sound/displaying the popup. Right, this would make sense for some use cases as well and worth considering. > As for multi-seat, this is already in hand. Console-Kit has support for > multi-seat stuff (tho' it may not be complete - I'm not overly sure > here). What may still remain to be done is to tag certain devices as > being for particular seats so that console-kit/udev can apply the > appropriate ACLs when the set becomes active for a given user. All the > multi-seat stuff is below PA tho' We'll just honour what it tells us. I > don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? // David
