Le Mardi 28 Mars 2006 19:31, Matthias Kretz a écrit : > to finally get us started on the overlap of Phonon and Solid: > http://vir.homelinux.org/audiodeviceconfig_solid.png
Nice diagram. =) Ok, I think it's not desirable to have a connection between the persistent device list and solid. In particular because your persistent device list needs to hold both physical devices and virtual devices. That said, I could provide an helper class that would act as a "persistent storage" for device data, but since it seems your needs are really limited I'm not sure it's worth it since it wouldn't be reused. > The goal is this: > The user plugs a new device into his computer > -> Solid recognizes that this could be interesting for Phonon Well, I'm not really fond of a solid->phonon depend. As I see it we have two solutions: 1) Phonon apps listen to Solid events (we provide the necessary signals), and get notified for devices changes 2) Solid provides a policy manager, and Phonon can register an helper application there. This helper would be launched when particular conditions are met. Davidz: btw, 2) reminds me about an obscure to-be-written fd.o spec... ;-) > -> here could be a necessary step to configure the hardware and drivers so > that the Phonon backends can make use of the hardware > -> Solid tells Phonon, which asks the backend for a new listing of all > available output devices That should be in the hypothetic helper application IMHO. > -> if a new device is in the list it is added to the persistent device list > and a passive popup tells the user that a new audio output is available and > asks whether he wants to open the output device configuration > (http://vir.homelinux.org/deviceconfig.png). Idem. > -> the device is unplugged, but the output device configuration still lists > the device (probably should be marked as "currently not available"). Here > another notification could be needed: > The removal of a USB soundcard can happen while the device is still in > use. The Phonon frontend then needs to ask the backend to use the next > device from device preference list. Once again the signals are already here. > Now we have a problem when devices are removed that will never be used > again. There needs to be a way for the user to remove entries from the > persistent device list... Well, I agree with Hugo here. It should be possible to the persistent device list to forget an entry if it hasn't been used for too long. > A list of devices that Phonon wants to be notified about (probably the last > one is not Solid's responsibility): > - ALSA devices > - OSS devices > - any other platform specific audio hw devices Ok, that's where I'm particularly interested to know which interface I should provide. Currently you'll be notified about the devices, but you can't know that they are interesting to you. What I would like to know is exactly the information you need from a device (apart the fact that it's actually an audio output/input whatever). Currently using the HAL solid backend I can expose the following information: http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html#device-properties-alsa http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html#device-properties-oss That looks pretty exhaustive to me... To the point that I don't see the need to have your own device detection in your phonon backends (configuring the device and actually outputing to it of course belongs to your phonon backends). Otherwise, I have the feeling that we're duplicating the detection logic, and I'd prefer avoid it. I might be wrong of course, I'm not the multimedia expert. ;-) > - computers on the network that are useable as outputs Clearly this last category is out of my scope. ;-) I'm not sure I address all your concerns, but at least we have some more thought for food... Now we have to find the best way for both projects to interact. Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance."
pgpz8sRpehaTt.pgp
Description: PGP signature
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
