[hotplug] /etc/asound.conf verwisselen na USB-headset plugin

[MadEgg]

Ik heb een Plantronics USB-headset die in principe goed ondersteund wordt door ALSA. Nu wil ik graag dat deze als standaard audio-out gebruikt wordt als hij ingeplugd is, en de emu10k1 in mijn computer als hij niet is ingeplugd.

Hiervoor heb ik twee versies van /etc/asound.conf gemaakt, en het volgende scriptje:

/etc/hotplug/usb/plantronics

code:

#!/bin/bash

/usr/bin/touch /etc/plant

if [ "${ACTION}" = "add" ]
then
    /usr/bin/rm /etc/asound.conf
    /usr/bin/cp /etc/asound.conf.plant /etc/asound.conf
fi

if [ "${ACTION}" = "remove" ]
then
    /usr/bin/rm /etc/asound.conf
    /usr/bin/cp /etc/asound.conf.noplant /etc/asound.conf
fi

Het 'touchen' van /etc/plant heb ik erin gezet om te kijken of het scriptje uberhaubt uitgevoerd wordt, tot nu toe is me dat nog niet gelukt.

Ik heb me rot gezocht maar hotplug-documentatie vind ik erg onduidelijk en schaars. Het kwam er een beetje op neer dat ik in /etc/hotplug/usb/DRIVER.usermap een regel moest zetten die het apparaat aan het script koppelt, en dat dat iets met depmod te maken had. Uit depmod haal ik de volgende info:

code:

snd-usb-audio        0x0003      0x0499   0x1000    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x0
snd-usb-audio        0x0003      0x0499   0x1001    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x0
snd-usb-audio        0x0003      0x0499   0x1002    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x0
....

waarbij het derde veld(0x1000) steeds verder oploopt.

Hieruit heb ik de volgende invulling afgeleid voor /etc/hotplug/usb/snd-usb-audio.usermap:

code:

# usb module         match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
plantronics          0x0003      0x0499   0x1000    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x0

Dit werkt echter niet. Het is mij ook nog niet geheel duidelijk waar ik DRIVER door moet vervangen, ik heb nu snd-usb-audio en snd_usb_audio(zoals de echte module heet) geprobeerd, beide werken niet.

Eventueel relevante info:

code:

Daedalus etc # cat /proc/sys/kernel/hotplug
/sbin/hotplug
Daedalus etc # uname -r
2.6.16-gentoo

Ik heb de volgende versies geinstalleerd:

hotplug - 20040923-r1
udev-087

Wat doe ik fout?

[MadEgg]

*schopje*

[MadEgg]

*rotschop*

Iemand een idee?

[MadEgg]

Zo makkelijk geef ik het niet op

[MadEgg]

Toe?

[Verwijderd]

chmod +x /etc/hotplug/usb/plantronics

misschien?

[Blaasvis]

ik weet niet hoe het in gentoo zit, maar in archlinux is heel hotplug zinloos geworden.
Alles word nu afgehandeld door udev en zijn uevents. Wat ik me dus af vraag is of je niet de verkeerde ladder aan het beklimmen bent.

[ Voor 23% gewijzigd door Blaasvis op 17-04-2006 10:37 ]

[MadEgg]

Hangt hotplug niet onder udev dan? Ik heb op google en Gentoo fora en GoT gezocht en kwam steeds zo'n beetje op hotplug uit. Het maakt mij niet zoveel uit hoe ik het scriptje aanroep; hoe doe ik dat met udev dan?


@alexvandenzel
Mijn scriptje is al 777 dus daar zal het niet aan liggen.

[MadEgg]

Hmm, even rondgezocht en het lijkt meer alsof udev onder hotplug hangt. Ook goed.

Ik heb nu in /etc/udev/rules.d/50-udev.rules de volgende regels toegevoegd:

code:

ACTION=="add",    BUS=="usb", SYSFS{product}=="Plantronics headset", RUN+="/usr/bin/plant"
ACTION=="remove", BUS=="usb", SYSFS{product}=="Plantronics headset", RUN+="/usr/bin/remplant"

De twee scripts, /usr/bin/plant en /usr/bin/remplant doen wat ze moeten doen als ik ze op de command-line uitvoer. Met deze regels in dat bestand wordt ook daadwerkelijk /etc/asound.conf overschreven door het goede bestand als ik de headset inplug. Als ik de headset er weer uittrek gebeurt er echter niets. Draai ik dan handmatig /usr/bin/remplant is de situatie weer zo als hij hoort.

De add actie wordt dus blijkbaar wel uitgevoerd; de remove actie komt niet door op de een of andere manier.

[Blaasvis]

ziet dmesg het wel dat je headset er uitgetroken word ?

[MadEgg]

Na een aantal keren in en uitpluggen ziet mijn dmesg er zo uit:

code:

usb 3-1: new full speed USB device using uhci_hcd and address 5
usb 3-1: configuration #1 chosen from 1 choice
input: Plantronics Plantronics headset as /class/input/input6
input: USB HID v1.00 Device [Plantronics Plantronics headset] on usb-0000:00:1d.2-1
usb 3-1: USB disconnect, address 5
usb 3-1: new full speed USB device using uhci_hcd and address 6
usb 3-1: configuration #1 chosen from 1 choice
input: Plantronics Plantronics headset as /class/input/input7
input: USB HID v1.00 Device [Plantronics Plantronics headset] on usb-0000:00:1d.2-1
usb 3-1: USB disconnect, address 6
usb 3-2: new full speed USB device using uhci_hcd and address 7
usb 3-2: configuration #1 chosen from 1 choice
input: Plantronics Plantronics headset as /class/input/input8
input: USB HID v1.00 Device [Plantronics Plantronics headset] on usb-0000:00:1d.2-2
usb 3-2: USB disconnect, address 7
usb 3-2: new full speed USB device using uhci_hcd and address 8
usb 3-2: configuration #1 chosen from 1 choice
input: Plantronics Plantronics headset as /class/input/input9
input: USB HID v1.00 Device [Plantronics Plantronics headset] on usb-0000:00:1d.2-2
usb 3-2: USB disconnect, address 8
usb 3-1: new full speed USB device using uhci_hcd and address 9
usb 3-1: configuration #1 chosen from 1 choice
input: Plantronics Plantronics headset as /class/input/input10
input: USB HID v1.00 Device [Plantronics Plantronics headset] on usb-0000:00:1d.2-1
usb 3-1: USB disconnect, address 9

Ook in dbus komen allerlei berichten door over zowel het toevoegen als het verwijderen van de headset.

[MadEgg]

*schopje*

[Equator]

Opmerking in het wilde weg:
Bij het input: event in de kernel komt de naam Plantronics inderdaad voor. Echter bij het remove (USB Disconnect) niet.
Lijkt me ook sterk, wnat de kernel kan niet meer zien welk device er zojuist is verwijderd.
Deze line lijkt dus helmaal niet "gevonden" te worden

code:

ACTION=="remove", BUS=="usb", SYSFS{product}=="Plantronics headset", RUN+="/usr/bin/remplant"

[TheFirepit]

Equator schreef op donderdag 20 april 2006 @ 11:47:
Opmerking in het wilde weg:
Bij het input: event in de kernel komt de naam Plantronics inderdaad voor. Echter bij het remove (USB Disconnect) niet.
Lijkt me ook sterk, wnat de kernel kan niet meer zien welk device er zojuist is verwijderd.
Deze line lijkt dus helmaal niet "gevonden" te worden

code:

ACTION=="remove", BUS=="usb", SYSFS{product}=="Plantronics headset", RUN+="/usr/bin/remplant"

Je zou wel eens gelijk kunnen hebben.

Ik weet niet of het mogelijk is, maar misschien kan je de addressen vergelijken en daarmee bepalen of het de Plantronics headset was die eruit gehaald is of niet.

usb 3-1: new full speed USB device using uhci_hcd and address 6
usb 3-1: configuration #1 chosen from 1 choice
input: Plantronics Plantronics headset as /class/input/input7
input: USB HID v1.00 Device [Plantronics Plantronics headset] on usb-0000:00:1d.2-1
usb 3-1: USB disconnect, address 6

[ Voor 26% gewijzigd door TheFirepit op 20-04-2006 11:53 ]

[MadEgg]

Dan zou ik dus ergens moeten opslaan wat het adres is waarop de headset was aangekoppeld? Dat is toch niet te doen? De kernel weet toch ook dat hij de betreffende device nodes in /dev voor de headset weg moet halen; dan kan hij toch ook weten welk device er afgekoppeld is?

[TheFirepit]

Als ik die output bekijken dan lijkt het mij dat hij dat doet aan de hand van de address nummers. De enige output die er komt als je de usb eruit haalt is het address nummer.

Het zou mij dan ook niks verbazen als kernel het doet aan de hand van het address nummer. Deze kan hij dan terug koppelen naar het address nummer waarmee hij aangesloten is een aan de hand daarvan weet hij dan weer welk apparaat het is.

[MadEgg]

En dus kan udev het toch ook weten?

[MadEgg]

Hoe laat ik dan udev controleren of het apparaat op een adres waar eerder een USB Headset op is aangekoppeld, afgekoppeld is?

[TheFirepit]

Ik weet niet of je het address nummer in een variabele kan stoppen of niet.

Wat trouwens ook een idee zou kunnen zijn (en misschien wel makkerlijker te doen is) is om te kijken in welke usb poort dat er iets ingeplugt zit en als die usb poort gedisconnect wordt om dan de config file weer te overschrijven. Het nadeel hiervan is dan wel dat je de headset altijd op dezelfde usb poort aan moet sluiten...

[ Voor 6% gewijzigd door TheFirepit op 23-04-2006 15:46 ]

[nzyme]

heb je het inmiddels voor elkaar ? want ik zit met hetzelfde "probleem" dat ik op het moment van inpluggen wil switchen van de onboard naar de usb...

[JeroenE]

MadEgg schreef op zondag 23 april 2006 @ 10:28:
Hoe laat ik dan udev controleren of het apparaat op een adres waar eerder een USB Headset op is aangekoppeld, afgekoppeld is?

In jouw remove regel controleer je op een SYSFS waarde. Voor zover ik weet is het probleem daarmee is dat deze niet meer beschikbaar is op het moment dat het device niet meer is aangesloten. Ik vind het zelf ook niet echt fijn, want bij de add regels kan je ze dus wel gebruiken.

Je kan het beste controleren op de kernel name, deze veranderd niet als je zelf een NAME aangeeft in je rules.

Ik neem aan dat dit bij jou een constante is zoals dsp1 ofzo? Je remove regel wordt dan:

ACTION=="remove", KERNEL=="dsp1", RUN+="/usr/bin/remplant"

BTW, je kan deze kernel name ook gebruiken voor je add rule.

Als je niet weet wat de kernel name is dan kan je die achterhalen door die aan je opstartscriptje mee te geven en dan ergens te bewaren. Dus RUN+="/usr/bin/plant %k" en in dat script iets als "echo $1 > /tmp/test". Let op, die waarde moet je natuurlijk wel hard in je remove rule zetten.

NB in de meeste udev howto's wordt aangeraden om niet zelf de 50-udev.rules te gebruiken, maar een apart bestandje te maken (bijvoorbeeld 40-local.rules).