That's the first time I saw KDE respond to changes in hardware. Configuration of such stuff has always been something the distribution had to take care of. Some distro's let you manage this by hand (like my Arch), others provide tools like Yast. But we're now moving one step further - integrating this functionality into the KDE libraries, making applications aware of what's going on beneath them. Very cool, that's for sure...
Unfortunately this only works for apps using Phonon. I hope in time, when other development frameworks catch up, something can be found to make this work out of the box with other apps as well.
Oh, and I hope everybody enjoyed Christmas or the other holidays they've had. New year in a couple of days, enjoy that as well and be careful with fireworks ;-)
This really belongs at a lower level, i.e. a central sound server, in other words PulseAudio. Expecting all apps to use Phonon is not realistic, getting them to all use PulseAudio is actually feasible. So if PulseAudio takes care of such hardware changes (and it does, through HAL), all apps will pick them up at once. I don't think a soundserverless setup will be able to react to such hardware changes in a way which gets picked up by all apps any time soon, PulseAudio really looks like the best solution right now.
ReplyDeleteKevin, this sounds like you looked into the issue in depth and know more about the issue than I do...
ReplyDeleteI did look at Pulse and you should know by now that I'm not trying to stand in its way. To the contrary I think Pulse is doing some things right. That doesn't mean it is the magical solution to everything.
The dialog Jos got to see is about KDE stuff: i.e. Phonon giving a notification that "NVidia CK804" failed and it's falling back to something else. With KDE forgetting about the device it won't try to use it in the first place and so won't give a notification about it anymore. Also you won't see the device greyed out in the device list anymore.
Whether this logic is implemented using Pulse or not is orthogonal.
Jos: glad you like it. :)
What happens if you let phonon delete this devices and turn them on in BIOS again? Will they show up in phonon again or do they disappear for ever?
ReplyDeleteAnonymous: Phonon treats the device like it treats a new device it has never seen before. (Well, not 100% true, but that's an implementation detail.)
ReplyDelete@mkretz: Well, at least in KDE 4.0 and 4.1, phonon-xine shows a single PulseAudio device and in Fedora we patch Phonon to use that device by default if it's available. (And I've looked closely at the code when writing that patch and also done extensive testing.) So there will never be a "Hardware device Foo failed, falling back to Bar" if PulseAudio is in use (well, as long as there's at least one hardware device - if there's none, PulseAudio will reject connections), because what device to output to is considered PulseAudio's business.
ReplyDeleteBut to be honest I haven't looked at how all these things interact in 4.2 yet. I noticed you added some support for querying libpulse for some stuff in the KDE platform plugin, but I haven't had time to look at that yet, so maybe my Phonon knowledge is already obsolete. :-(
I definitely don't know more about Phonon than you, you frigging wrote it. ;-) I'm aware of that, sorry if I didn't sound like it.
I did look into Phonon/PulseAudio interaction to some extent though, with the goal of making it just work for Fedora 9 and 10; the solution I came up with (just make the single PulseAudio device the default if available and let PulseAudio handle the rest) may not be optimal and may not match Phonon's long-term direction, but it did solve the problem of making it work...