It's fine being a system daemon if it's a pure mechanism. Tell me, said emu system daemon knows the uid/pid of the opener of the device.
Yes.
Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered)
That's orthogonal to the argument of system pulse vs. session pulse-- but yes it could talk to pulse either way. It would not be passing an fd (it's using shared mem), but that's an implementation aside.
> Many applications of sound are more appliance-like than > application-like. A session daemon is all fine and good until the > applicance has its appliance disappear. The session daemon approach > does not allow even the possibility of appliance-like sound > applications. Either - tell them to startup Pulse themselves; or better - we automatically launch Pulse when needed (through libasound or the system emulation daemon)
Either would be incompatable with the desktop arrangement; you've set up a situation where serious audio software would be inherently at least partially incompatable with working on a Gnome desktop. Or we'd have to implement both-- a system Pulse for 'appliance' applications that implements auth, etc, anyway, and a coordinated cloud of session pulses. Of course, since they're not really sharing-- one pulse can have the sound devices at a time-- the appliance pulse would lock out the others.
We'll have the pop whenever we want to suspend the audio hardware and we do want to do that in the default install for laptops anyway.
We can suspend Pulse without suspending the hardware, BTW... the kernel drivers will take care of pushing silence...
Because saving power is very important and may in the future be a requirement to sell to governments.
Sure and there are cases where we do want the full-blown suspension. Does that mean we mandate the lowest common denominator? Most people will not want the popping.
Besides, your assumption that the sound card will be switched off/on during session switch (and cause a pop) is utterly wrong - the kernel driver for the hardware would of course only suspend the sound card after N seconds of no openers.
Demonstrably incorrect.
> An earlier question still stands, and it is central: does UID == > console session ID? Nope.
How do you regulate /dev access? A user logged in twice would hand both sessions full access. Monty -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
