On Wed, 13.02.08 12:33, Les Mikesell (lesmikesell@xxxxxxxxx) wrote: >>> Have you considered just muting the sound rather than blocking the >>> applications? The obvious drawback is that the user doesn't automatically >>> get back to where he/she left, but on the other hand, you can't really >>> expect sound applications to know how to handle a blocked sound device, >>> and it is also application-specific whether returning to where you left >>> is a good or bad idea (think of a live stream, for example: in that case, >>> returning to where you left might not even be possible, and if it is, >>> it's usually not what the user wants). >> It's a bit difficult to continue streaming audio based on the sound >> cards clock if you don't have access to the sound card anymore. > > Does this mean you should always use Xnest, NX client, vnc, ssh, etc, > instead of VTs to get login sessions that don't accidentally grab > unrelated "accidentaly"? "unrelated"? The whole point of CK is that we change ownership of *related* devices, i.e. those directly attached to the seat in some way. > hardware ownership? That seems backwards if what you really want is an > audio player as a server that isn't tied to a particular login session. Hmm, I think we had this discussion multiple times already on this ML... You can always change the HAL/CK policy to not limited access to audio devices to the current session. The default however is that only the active user session can access the device. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
