Op maandag 03 oktober 2011 15:38:34 schreef Colin Guthrie: > 'Twas brillig, and Maarten Vanraes at 03/10/11 13:41 did gyre and gimble: > > Op maandag 03 oktober 2011 10:27:02 schreef Colin Guthrie: > >> 'Twas brillig, and Maarten Vanraes at 19/09/11 11:32 did gyre and gimble: > >>>> On 19 September 2011 11:44, Colin Guthrie <[email protected]> wrote: > >>>>>>> Did you fixed the war against webcam another way? > >>>>>> > >>>>>> Is this a problem of webcam mics not working if they are present > >>>>>> during boot? If not, can you remember the problem better? > >>>>>> > >>>>>> If so, no I've not fixed, but will find an official way that we can > >>>>>> submit upstream. > >>>>> > >>>>> Whoops, it seems this conversation went off list accidentally. > >>>>> > >>>>> TV clarified that the problem the snd-usb-audio modprobe rule solved > >>>>> was that of webcams getting the card0 slot on boot and pushing the > >>>>> normal, built in audio system to card1. > >>>>> > >>>>> As this problem attempts to resolve the underlying limitations of > >>>>> alsa (not preserving the audio device order) in a generic way > >>>>> (specific index= arguments could be added to your own specific > >>>>> hardware to solve it also), and considering that device order really > >>>>> shouldn't matter when PulseAudio is used (it has it's own built in > >>>>> system for determining the "priority" of devices when a first boot > >>>>> with a new user is encountered so that the correct defaults will be > >>>>> picked on first boot and there after it's the user's choice), I'm > >>>>> not really inclined to attempt to fix this "bug". > >>>>> > >>>>> If people feel super strongly about it I can look into it, but I > >>>>> think it's really a matter of "tough love" for the non-PA case if it > >>>>> means we have to put in lots of crazy work arounds like this. > >>>>> > >>>>> Opinions welcome. > >>>> > >>>> Not all people use PA. > >>>> We even have options in draksound in order to disable it... > >>>> Hence we must still support the case were PA isn't around... > >>> > >>> can something be done with udev rules, like it happens with other types > >>> of devices? > >> > >> I'm not sure udev rules will fix this. > >> > >> I guess we could provide some default modprobe rule that just left space > >> for the device 0... > >> > >> http://alsa.opensrc.org/MultipleCards#Reordering_the_driver_for_a_partic > >> ula r_card > >> > >> options snd slots=,snd-usb-audio > >> > >> > >> These rules could only be used when PA is not used (via sound profile > >> symlinks) > >> > >> That will probably cover most bases and if users want to have more > >> configuration when they do not use PA then they can write their own > >> modprobe rules. I'd say that's an acceptable trade off. > >> > >> WDYT? > >> > >> Col > > > > what i mean is to have some kind of udev rule generator, so that the ones > > you had when you started at first are kept in that order (they still can > > be added or removed, but the existing ones will keep their device name? > > Potentially, tho' I'd much rather avoid complicated rules generators > like that as it'll just lead to problems at some point when it stops > working or syntax changes etc. > > IMO it's just added complexity for questionable gain. > > Col
debian uses this system to make sure devices have the same device names and numbers as long as they are uniquely identifyable. perhaps we can take a look at how debian does it?
