On 09/07/2011 04:27 PM, Colin Guthrie wrote: > 'Twas brillig, and David Henningsson at 07/09/11 14:37 did gyre and gimble: >> The idea of "start to use what you plug in" is nice. If you plug >> something in, you likely want to use it. Or do you? Anyway, that >> approach seems to me to have an unsolvable problem: We don't know that >> it actually was plugged in. >> >> I've tried to talk to a few people, and from what I can tell, there is >> no point in time when the system can be considered to be fully "up and >> running". This means e g, if a new bluetooth device shows up say 30 >> seconds after PulseAudio starts, we don't know if this was because >> someone actually connected the bluetooth headset at that point, or if it >> was connected from start but took 30 seconds to respond and negotiate >> with the bluez stack. Same goes for USB, and in theory other devices as >> well, but I've never seen it happen in practice to anything internal/PCI. >> >> Also, this applies not only at boot, but also at resume from suspend or >> hibernate. >> >> Given that lack of information from the kernel/hardware, I can only >> assume that order-based handling is bound to fail. And so is >> module-switch-on-connect, that implements this. (And so is Ubuntu's >> suspend/resume script, btw.) > > Yay, I never did like that script :p Probably stupid to mention it here as it risks the conversation going off-topic, but anyway, the day PulseAudio upstream offers an alternative solution I don't think anybody would mind removing it. >> This leaves us rule/priority-based policy decisions, which I believe is >> what Colin thinks as well. Comments? > > Yup, but you outlined it nicely :) > > That said, there is likely still scope for changing where in the > priority list new devices are injected (top or bottom being the only two > valid choices), Hrm. I think we have to do a little bit more clever than that. I'd like some kind of base priority for a device that is used given that the user never configures anything, based on form factor and other things. Then exactly how a new device would interact with a priority list that user has messed around with, might require some thought to get intuitive. > although that will still be subject to the problems you > outline above. Hopefully the general use case is more "hotplug" related > than "first boot", so I'm not sure there will be overly many practical > problems, but you're absolutely right to consider them. Having things working as expected out-of-the-box should not be underrated. First impressions last and might save me quite a few unnecessary bug reports as well. So IMO we need to solve both. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
