Re: [gnome-love] device sharing bug -- where to file
- From: "David Berg" <drberg1000 gmail com>
- To: "Ross Golder" <ross golder org>
- Cc: gnome-love gnome org
- Subject: Re: [gnome-love] device sharing bug -- where to file
- Date: Sat, 10 Jun 2006 08:23:47 -0500
On 6/10/06, Ross Golder <ross golder org> wrote:
On Mon, 2006-06-05 at 13:50 -0500, David Berg wrote:
> I'd like to file a bug addressing the way the audio and video devices
> are shared on a multi user work station. If I start a movie then
> someone else switches to a different VT the audio and video devices
> should not be available for use. More particularily the music should
> stop and the new user can start their own music. And processor time
> should not be taken computing screens that will never be seen. The
> biggest problem programs I see are the screensavers, movie players,
> and any music program.
> I don't have a clue where this problem should be addressed though.
I'm guessing that the applications in question will all need some kind
of DBUS love. Signals will need to be sent from the kernel (or the
xserver?) when virtual terminals are changed, and programs (movie
players, screensavers) will need to listen for and re-act to those
signals by releasing the resources they are holding.
That route would require that all of the apps be well behaved in order
for sharing to work properly. Shouldn't the issue of a program being
well behaved affect only one user on a well configured system?
If I set up process accounting properly then if someone leaves their
3D screensaver running or uses a screensaver that doesn't throttle on
a VT change then I still get a fair allotment of process time. And
while the screensaver should still throttle it doesn't affect other
users so much since the system is still usable.
As far as I can tell though there is nothing similar to be done with
the sound card. The sound device should belong to the current console
user in almost every case. When you switch terminals the video
doesn't try to display two sessions, but the sound card does.
I think that user space programs definately should have bugs filed for
system sharing issues but I'm more interested in addressing the
permissions problem and letting programs follow.
So perhaps I should have phrased my question like this: what program
should be in charge of controlling the owner of /dev/dsp? I know this
might not be quite the appropriate forum for the question, if you know
of a better one I'm all ears.
> Can someone help me out?
I hope so :) It sounds like something that ought to be done to me.
] [Thread Prev