On Wed, 2008-07-09 at 13:32 -0700, nate wrote:
William L. Maltby wrote:
CD is playing alright. Volume Control Panel mute, volume, balance all work. In *my* original thread (not the one from ech - Jim?), I couldn't even open the Volume Cont... crap that's too long - VCP ;-) (you know who you are!)
I'm not sure it's a bug though, it may be a feature(tm) (the changing of permissions on devices). I don't think it should work that way.
I'll forgo my tendency to start a philosophical discussion about that. I'll just say that whatever method is chosen, I don't think correct behavior locks out the desktop user when the other current user (especially when that user was instantiated from the same desktop, implying that the *ending* ownership should be at least such that it allows the original gnome user access to the facilities) is finished with the device(s).
ISTM it is either a design flaw or an implementation flaw.
For an example of correct behavior, just think of ttys where multiple users can use the same device at different times. When a user logs on, ownership is given to that user. When the user logs out, ownership is returned to root.
System resources are *ultimately* managed by the system.
I checked my Debian Etch desktop at home for any devices that were owned by my userid and the only ones that came up were terminal devices(/dev/pts/ stuff), which is normal if your logged in. It appears Debian hasn't adopted the stuff that changes the ownership of /dev devices and instead relies upon group access rights(what I think is the right way to do it). So any user in the audio group for example has a right to play audio. I don't have any RHEL or CentOS desktops, I have a Fedora 8 desktop in VMWare ESX but it doesn't appear to provide a virtual sound device so I can't check anything there either. My servers get a minimal version of gnome, not enough to login to a desktop with but enough to run some gnome or gtk related apps over a SSH tunnel.
Sharing via group access rights is OK too. But it is not appropriate for all devices or even some uses. Think of 3 users printing to a non-spooled printer simultaneously. Or writing a CD/DVD.
Regardless, when one user of the group accessible device is finished, subsequent users are not locked out.
So even this scenario supports "buginess" of the RHEL/CentOS situation.
- When the using application(s) are terminated, the devices ownership
should be returned to root, as with tty devices, or back to the desktop user (if that user ever owned them *before* the devices were used - which they weren't in this case) allowing later allocation to another user again and making them also available for the desktop user.
While this may be possible I can imagine the logic getting confusing if there are multiple people that are logged in.
Not too bad. My background includes some extensive programming and early UNIX kernel internals. Shared devices start out owned by root, are allocated (implying ownership changes) when opened by the user and ownership returns to root when usage ends. There are use counts and associated structures that are checked to see if the device is in use.
With Linux it may be different, but some facility that implements some sort of similar control has to exist as a general purpose resource for management of the system.
The Q now is will changing ownership of these affect the volumeslider? Shouldn't? First one is an LSB shared object, second one is data.
No neither of these should impact volume. What impacts volumes with regards to flash is if the plugin is actually loaded(which requires going to a page that has a flash object), and actually plays some audio. Before that happens nothing with the audio subsystem is touched as far as I know..
Yep. In my case, it was the T'bird mail notification that played the sound.
Before I write a bug report (after seeing that one doesn't exist), anything else you think I could look for or try?
Not off the top of my head.. I guess last words would be don't be surprised if it doesn't get fixed(short of getting off the scheme of changing ownership of dev devices entirely for things like audio), which I don't think(hope) would happen until a major OS rev is issued.
I agree. Since this would (apparently, based on what is seen) necessitate the changing of some important library routines and/or application logic.
It wouldn't surprise me if the response was something like "Why are you running as multiple users? That's stupid!".
nate
<snip sig stuff>
Regardless, your assistance has been most generous and helpful. I appreciate your selflessness.
Thanks,