On Wed, 13.02.08 12:33, Les Mikesell (lesmikesell(a)gmail.com) 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