On Wed, 19.12.07 11:44, Olivier Galibert (galibert@xxxxxxxxx) wrote: > > That means, for now, you have to use the raw ALSA "spdif" device if > > you want to playback audio on spdif. That hasn't changed from pre-PA times. > > I can use alsa for everything, I know that already. That was not the > point of the email. > > If your answer to "how can PA be used to support my configuration" is > systematically "don't use PA", why are you working on PA in the first > place? Come on. The are a lot of thing PA doesn't do right now. Not just this one. However, there happen to be a couple of things PA can do very well. What kind of stupid game is this, anyway? You find cases where PA doesn't work without manual reconfigration. And then you ask me, and I say, "yes, it doesn't work", and then you tell me "yes, i thought so, PA is total crap." I you want we can play this game with swapped roles: I find a feature that software you wrote doesn't do and then I tell you "Your software sucks big time." It certainly would be a lot more fun for me that way! Also, in this case the bad support of SPDIF in PA is not really PA's fault. It's more ALSA's since it doesn't really have any (working) API for discovering if spdif is available and if it is exclusive to analog out. Also note, that PA supports spdif quite fine if you do manual reconfiguration in style of adding a single line to /etc/pulse/default.pa: load-module module-alsa-sink device=spdif:0 Oh, and it is also not the case that I wouldn't be aware of the messy SPDIF support right now, and that I wouldn't be working with the ALSA people to find a resolution. > > You should be using the normal fast-user-switching for that. > > So now gdm and using a panel is a fedora requirement for multiuser > support? We try our best to supply you with easy-to-use software for doing f-u-s. And all you do is telling us is that you refuse to use our software, but go on complaining that f-u-s doesn't work for you? How do you think we should be fixing this? I mean, it's hard to get this fixed for you if you don't want to use our code. Don't you think? The f-u-s code is open. You're welcome to hack up your one UI for it. That's what Free Software is all about: scracthing your own itches. We already supply you with a couple of UIs, if they are not good enough for you, then I guess you need to get your hands dirty yourself and teach us fools how a really good UI should look like. > > PA supports f-u-s just fine, as I think I already wrote about 555 > > times on this thread. > > Where fine means "only the currently selected user can do sound", from > what you wrote too. Which, if you had bothered to read my use case > with your brain on, you'd have noticed is not fine at all. Let's stop this stupid discussion now. I already wrote countless times on this thread: with some minimal reconfiguration you can get PA working for you, or can bypass it, whatever suits you best. And I already explained in detail why we chose to do multi-session support the way we are doing it. We tend to do our stuff for good reasons the way we do. And we explain them to anyone who asks. And we take suggestions. But in the end, the one who produces the code is ... the one who produces the code. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
