On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing). Also, keep in mind that we're going to enable accessible login (including screen readers) for gdm - I wonder if we need pulse audio running there and how it works with the alsa-pulse plug-in - will pulse-audio be activated on demand? Or will the presence of alsa-pulse just break accessible login because there's no PA instance running? Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that. David

On Tue, 2007-02-27 at 18:30 +0100, Pierre Ossman wrote: I don't think this works with f-u-s. I tried. Thinking about it, wouldn't it would be a security issue if it did work? You really don't want dmix to accepting connections from other users... David

On 2/27/07, David Zeuthen <david(a)fubar.dk&gt; wrote: Of course not. But dmix or a system Pulse, there will be no session partitioning until everyone esle can catch up with these changes. Monty

On Tue, 2007-02-27 at 13:04 -0500, xiphmont(a)xiph.org wrote: So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems. One of those is that you want to read user settings and enforce policy depending on users session [1]. Another problem is that if you have system-wide daemons you need to coordinate clients with different identities; e.g. you suddenly need to label your objects and make sure that an object created by uid 500 cannot be manipulated by uid 501. Things like that. Does PA handle that already? For starters, how are all the exiting PA tools going to work with PA running system-wide? How is it going to work with multiple sessions? I don't think there's anything "easy" about this. If it was easy, wouldn't you have RPM's for us already? ;-) I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol. David [1] : see also Lennarts presentation about "Compiz for audio" plans which further marries that idea http://0pointer.de/blog/projects/freedom-lovers.html David

On 2/27/07, xiphmont(a)xiph.org <xiphmont(a)xiph.org&gt; wrote: Rather, I should say the idea up for consideration is a thin authenticator that is the only trusted connection mechanism for a system pulse. That still doesn't directly help out the emulation case though. We can't ship broken stuff, and regressing sound counts as broken. Monty

On 2/27/07, David Zeuthen <davidz(a)redhat.com&gt; wrote: Backwards. Please, no more talk of LD_PRELOAD. I will resign before I pin the future of Linux Audio on an LD_PRELOAD hack. Dead serious. It is a non-starter. Sure, problem solved. Monty

On Tue, 2007-02-27 at 13:28 -0500, xiphmont(a)xiph.org wrote: Oh please. Keep this discussion technical. X is getting fixed. See Keith's blog for this http://keithp.com/blog/kernel-mode-drivers.html See also below. Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please. Users can use LD_PRELOAD for such broken apps that we can't patch to live in this century. We all know that /dev/dsp is fundamentally broken and no-one but people living stuck in the 90's are using it. We're a *free software distribution*, we don't have to support legacy crap the nice way. If you want, use LD_PRELOAD hacks. Or some emulation daemon that can forward the stream from then open(2)'er to the right PA instance (not hard). Heck, so uid 501 can poke the streams created by uid 500? That's a show stopper just because of security implications. Do you disagree? That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted. Heck, we're getting revoke() soon (see #230006) so whether the PA instance in a session likes it or not it's going to have access to the sound device revoked. It just needs to cope with that *just like* it needs to cope with devices being hot-removed. Well, there's no politics here apart from wishing not to introduce short-term hacks that will haunt us for ever. See X.org mode setting in user space for a brilliant example of how this hack is STILL HAUNTING US in 2007. Ding ding ding, it's 2007 already! Yes, we need to sort out this audio situation. Right now PA, until it's fixed in a sensible way, makes f-u-s not work so we can only do one of them. That's not my call though. What is the view of all this from PA upstream? I talked a lot to Lennart at LCA about this and he said system-wide pulse was a non-starter exactly for the reasons I listed. David

On Tue, 2007-02-27 at 14:04 -0500, xiphmont(a)xiph.org wrote: Ding ding ding. We want to ship a distro that is secure by default. Seriously, this is a stop-ship thing whether you personally like it or not. My gods. Do not pass start. Do not collect $200. Hint, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006 and come back when you understand the implications. Thanks. It's because I live in this century and don't use OSS myself. Either LD_PRELOAD or some emulation daemon that forwards the stream to the right PA instance. Either is ugly because OSS is ugly. Of course, we wouldn't enable such things by default because we don't have OSS apps in the default install. Perhaps enterprise distros that care about old crap would. *plonk* Here's a quarter, Monty. Go use it to try a modern Linux desktop. David

On Tue, 2007-02-27 at 15:01 -0500, xiphmont(a)xiph.org wrote: ^^^ How nice. No, we're just fixing past design mistakes to make the Linux desktop be true multi-user (again). In some circles it's called progress; looking forward and doing new exciting things. If such things happen to be useful, hey, more power to the Linux desktop. I'm not dismissing OSS; there are, at least two mechanisms to support it; let me repeat - LD_PRELOAD (widely used by LTSP) - emulation devices Let me repeat again: both are ugly as hell because OSS is ugly as hell. Whether we as a distro want to keep compat for these around in the *default* install is a separate issue and up to the Fedora project at large. I don't really care and I'm sure people who have a better idea of our user base does. It could go in a compat-oss package for all I care. For the record we have other compat* packages that you need to use antiquated interfaces. No, it's fine, apps use libasound and there's a plug-in for Pulse. I don't understand this. OSS compat is possible through two mechanisms already. Plus I have a lot of faith in the PA developers not to screw up. No, it's fine, apps use libasound and there's a plug-in for Pulse. David

Hi Monty, On 2/27/07, xiphmont(a)xiph.org <xiphmont(a)xiph.org&gt; wrote: To me, this is very much like asking "Does UID == $DISPLAY"? And the answer of course is - not in general. Jon

On Tue, 2007-02-27 at 15:44 -0500, xiphmont(a)xiph.org wrote: If the emu system daemon runs as root you, then /dev/dsp and friends would only need to be accessible by root assuming the emu system daemon passes the fd to the PA instances. That's what I meant in the other mail with: In order to identify the correct PA session instance you would look at $XDG_SESSION_COOKIE in the environment (/proc/pid/environ) for the caller. Or, more portable, make a D-Bus call to ConsoleKit to get this given the pid. Of course, this means that PA needs to be changed to name it's sockets using the Session name (not the cookie!) instead of the username. But that change is easy. And for now GNOME (probably not KDE either) support multiple logins by the same user on the same box. But that's something we want to fix eventually. Hope this helps. David

On Tue, 2007-02-27 at 15:32 -0500, xiphmont(a)xiph.org wrote: As I said, it's not my call whether the Fedora project should support this in the default install. For the record, if you want to run GTK 1.x apps you need to install compat packages. That's a decision that the Fedora project made after doing cost/benefit analysis etc. Things like 'cost' included - including GTK 1.x meant fewer people ported to GTK 2.x - the apps we include in the distro were all migrated - size/complexity of maintenance - and things like... If supporting OSS out of the box just works and is cheap to maintain, hey, go for it. If there's a huge cost.. then.. back to your cost/ benefit analysis. Personally, I'd like OSS to just work, don't get me wrong it would be *nice* to have but not something that should dictate an architecture and make it *very hard* to do future stuff (running PA system-wide). 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. 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) Either - tell them to startup Pulse themselves; or better - we automatically launch Pulse when needed (through libasound or the system emulation daemon) 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. Because saving power is very important and may in the future be a requirement to sell to governments. 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. Further, only few sound card drivers do this already, I can only think of the one for OLPC hardware. Nope. David

On Tue, 2007-02-27 at 16:13 -0500, xiphmont(a)xiph.org wrote: Not really. We're arguing what's best to do - either a system or session PA and this demonstrates that OSS compat has nothing to do with that. Right. I think if you building an appliance - it's not too much work to start another instance of PA; if this can be done on-demand (as you didn't argue it couldn't) then it's all automatic - your appliance would probably run unprivileged (See: flumotion) I think ideally we'd have a system-wide daemon that all per-session PA's connect to which does mixing and handling emulation devices. Perhaps, for you, that is PA (with few modules loaded) and we're talking about the same thing. Such a thing would be ConsoleKit aware, e.g. it would enforce (tweakable) policy such as muting inactive sessions. Still, I _do_ want PA in my session so I can do all the "compiz for sound" things (settings) and, in particular, I don't want other users to be able to tweak my streams (security). Yea, but the chip is powered up and eating battery as long as someone has the device file open - the kernel driver has no chance to know it's silence and it shouldn't. (actually some drivers power down parts of the chip depending on whether capture/playback device files are open.) I think it's a user preference really. We have this thing in g-p-m to tweak this desktop-wide preference http://people.freedesktop.org/~david/g-p-m-prefer-power-savings.png (for some reason this is not in Rawhide - I'll investigate) (actually these are two settings; one for when running on battery that defaults to TRUE; one is for running on AC which defaults to FALSE. Which I think is sane). but perhaps Pulse itself could offer a setting whether to use the desktop-wide setting or the user could specify a timeout. My point being, it's a user setting. If the user says "never turn off sound card when there is silence" (by some setting) then the in-session PA just streams silence to the system-wide daemon or kernel driver. So I take it you can point to a kernel driver that doesn't wait N seconds. Return to dealer :-) - more seriously, you do know that runtime power management isn't really set in stone in the Linux kernel yes? Anyway, the point is that this is the behavior we want, don't you agree? Access in Linux is per-user/per-group and that's hard to change. The $XDG_SESSION_COOKIE thing is simply a way for a system-wide process to identify what desktop session a process belongs to. It isn't used to enforce any security whatsoever. Yup. David

On 2/27/07, David Zeuthen <davidz(a)redhat.com&gt; wrote: I know you didn't *say* LTSP.... But seriously, how is that currently done with, say, two webcams? Monty

On 2/27/07, David Zeuthen <davidz(a)redhat.com&gt; wrote: I meant technically orthogonal. It can be done regardless of session vs. system. Ah, so it boils down to a semantic argument... yes, that 'system daemon' is what I am calling Pulse Audio, in that it will have most of the actual mechanism in it. We could do it that way, the worry is the latency/complexity introduced by the sound stream having to touch too many hands/endure extra context switches before making it to the actual hardware. We are talking about, for the most part, the same conceptual abstractions, but I'm talking about them all existing in the same process space. A 'system' pulse must, at a very minimum, exhibit full session personalities/awareness to the apps. We're not arguing at all about the end-functionality in this case. Actually, the driver *does* know it's silence because of the way the transactions are handled by ALSA; if the device is open and no app is feeding data, ALSA can be told to supply silence (or hold last value, or an y number of things). As for 'eating power', if it's a hundred mA, I fully agree with you. If it's 10mA, I'm less sure. If it's a mA or less, I laugh at your requirements unless it's OLPC :-) I know it's fashonable to make this a session preference, but it isn't really. This is a decision it makes more sense to give to root. But I don't care enough to argue. Well, I argue for it being a system (not desktop) setting as it has to do with a system resource. But enh. ..and what happens during the transition? It depends on the settings of each user combined....? None of the USB sound cards wait, because USB shuts them down immediately upon last transaction finishing. For other cards, it's by driver and they're not consistent. I know, never was. Brand new system every three years.... My thinkpad could suspend properly in 2004 :-( I'd opt toward 'smoothest behavior in all cases' unless demostrated that a powered sound chip is causing measurable drain. That's not an argument against full options being available regardless. Oh, well if that's an accepted part of the design, my work is easier. Monty

On 2/27/07, David Zeuthen <davidz(a)redhat.com&gt; wrote: If we are talking about a watt. Or a milliwatt. What if we're talking about 100uWatt? Is it worth it then? Again, those USB sound devices are on the touchy side and a notebook is even more likely to be using one... Well, it would be on the Wiki if I actually had any edit permissions, which I don't... Monty

On 2/27/07, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote: I mean, I *should* have editing access, I've supposedly been given edit access, but I don't have edit access. Monty

On 2/28/07, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote: I can't. When I attempt to recover a lost password for 'ChristopherMontgomery', the wiki sends me a mail for 'XiphMont' instead. I had assumed the system somehow internally had aliased the two. Monty

On 2/28/07, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote: Thank you. Although I don't want to continue to cause trouble, is it possible to change it from ChristopherMontgomery? The problem is, essentially, that Christopher isn't my name, I've never used it, I've never answered to it, not even my siblings/parents use it. Aside from being on my birth certificate it has nothing to do with me. I didn't choose it for the wiki, Redhat did. (Monty Montgomery is weird, but at least I know it's me.) Thanks, and sorry for the hassle. Monty

On 3/1/07, Jesse Keating <jkeating(a)redhat.com&gt; wrote: "Yeah Well" It was there waiting for me when they put us through 'wiki training' during new-hire orientation. Monty

On 3/1/07, Jesse Keating <jkeating(a)redhat.com&gt; wrote: Oh, um, duh, of course. My brain went off in the weeds here. So how the heck did I end up with two Fedora wiki accounts.... Hmm.... Monty

On 2/28/07, Matej Cepl <mcepl(a)redhat.com&gt; wrote: That's exactly the point, it does work (at least, it's supposed to. if it doesn't work, then I will *make* it work). Monty

On 2/28/07, Alexander Boström <abo(a)kth.se&gt; wrote: This viloates the tenent of 'fast user switching does not lose state'. Switching to the other login should not cause, eg, Audacity which is holding an hour of unsaved editing work to crash or get killed. Monty

On 2/28/07, Alexander Boström <abo(a)kth.se&gt; wrote: Well, the idea is that the Pulse (be it session or system) doesn't die or get killed and applications running on the desktop are generally unaware anything changed w.r.t sound-- the Pulse mutes their streams, sample and playback get zeroed. The Pulse server, of course, will be 'cooperating', but trusted system software is allowed to be cooperative without being mocked. Monty

Le mardi 27 février 2007 à 13:20 -0500, David Zeuthen a écrit : Per-session daemons may be nice for stuff that does not require exclusive access, to manage hardware they're a disaster. I don't want to log in at midnight so my GUI recording software is authorised to access the tuner card, wireless link should not go down at user logout, power management should happen even on a mostly headless system, etc The "modern" Linux desktop seems limited to a single-user laptop in brick mode when one logs out. Per-sessions daemons are not simple they're dumb. -- Nicolas Mailhot

On Tue, 2007-02-27 at 14:41 -0500, David Zeuthen wrote: And, for the record, the reason this is super desirable is that to configure system-wide policy (e.g. when no one is logged in), we can re-use exactly the same configuration applets, e.g. for the g-p-m preference dialog you'd have a button [ Set these settings as system wide ] that would (possibly after auth) copy these settings to the system-wide preference area. For a single-user laptop probably this would be done by default. All this could (possibly) be useful on servers too; e.g. you could have the policy for g-v-m when no-one is logged in to automount media and share it on the local network via Avahi. Use case would be some system that have a CD with patches he needs 100 different servers to access; just pop in the disc and it's available on the network. But now I'm drifting off-topic.... David

On Wed, 2007-02-28 at 07:28 +0100, Nicolas Mailhot wrote: First I was going to say that 1) v4l devices are exclusive-openers; and 2) use O_EXCL for other kinds of devices. But then I realized you're talking about a PVR getting ready to capture a recording in the future. So, sure, you could have some system-wide mechanism for obtaining exclusive access to the hardware that, in the process, would use revoke() to kick out other openers already hogging the device. That's something I've been wanting to put in HAL anyway (since HAL is just a mechanism); it's probably the right place since ACL is managing your permissions. Then your conceived[1] example of a PVR appliance would just work; it would - You're capturing video in your login session (uid=500) - you're tuned into channel 825 - Time passes - PVR appliance decides it wants to record BSG for you. Bummer, that's on channel 62 and, rats, someone is hogging the device files - PVR user (uid=501) calls into system-wide mechanism to get exclusive access on /dev/video0 and /dev/dsp - System-wide mechanism removes ACL's on /dev/video0, /dev/dsp for uid 500 (it keeps ACL's for uid 501 because that's what the caller of of GetExclusiveAccess() has) - System-wide mechanism revoke()'s access to /dev/foo, /dev/bar for uid 500. Your TV capture app in the session hopefully doesn't crash because access is revoked. Today it probably would :-) - System-wide mechanism returns to PVR user in response to the GetExclusiveAccess() call. - PVR appliance now have exclusive access, opens the devices and records your show - Time passes. Disks are spinning. - PVR appliance is done recording. It calls into ReleaseExclusiveAccess() and the system-wide mechanism reconfigures the ACL's. uid 500 can now access the devices again. - Perhaps the video capture thing in the session for uid=500 starts showing something again. Perhaps the kernel should have an option to open(2), say, heh, O_EXCL_AND_KICK_OTHER_OPENERES that does this but all this involves a policy decision (is uid 501 really privileged to do such a powerful operation? The kernel just don't know...) and ACL management. I'll think a bit more about this; we need to get the interface right.. anyway, thanks for bringing this to my attention. [1] : actually I bet the example is not so conceived That's just device access again - I hope with Keith's and others work on that the kernel will, in the future, finally export device files (for GPU's, CRTC's and monitors [2]) so we can manage permissions on them like any other device. Then, you know, we can also run the X server as an unprivileged process. Wouldn't that be something? :-) Lesson here is that multi-user is *hard*. Doesn't mean it's not fixable. It does require that apps adapt and use new infrastructure to learn about the environment in which they're running. That's not different from Windows or Mac OS X - many apps there don't work properly with multi-user simply because the app developer didn't write his app with this in mind. David [2] : Hope I got that right

On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote: Does esound work that way? If it doesn't, then you have the exact same problem when a user switches on the sound bling in the control-center. If it does, then what's stopping us from using PA as a drop-in replacement for esound? It would/should work just as well as esound did before (apart from the fact that I'm told PA hogs the physical device instead of going through dmix, which means nothing works unless you have a PA sink, or use the ALSA plugin for PA).

On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote: If f-u-s breaks, right now, when the user ticks the "start up esound so I can get desktop bling", then something is broken, and needs fixing, whether or not we want to enable PA.

On Tue, 2007-02-27 at 13:57 -0500, Matthias Clasen wrote: Well, what pisses me off is the fact that "per-session daemon is hard, let's just do a system-wide daemon" without realizing all the implications of this (settings, security). I'm perfectly fine with having PA as a per-session daemon and sound on f-u-s not working if the following is on the PA roadmap - PA giving up sound devices on silence - PA being able to give up sound devices on session switching - emulation daemon can forward fd to per-session PA daemon or - some kind of ultra-light system-wide daemon for arbitrating access to sound hardware for per-session PA instances because then we can clean this up for F8 and/or an F7 update. But deciding on an architecture (system-wide PA) that I consider broken by design is just the wrong thing. Monty, what do you think? David

On Tue, 2007-02-27 at 13:02 -0500, Christopher "Monty" Montgomery wrote: I'm using SELinux in permissive mode, and don't see any errors in /var/log/messages relating to SELinux errors (some avc denied).