2 Bluetooth-Devices

Languages Deutsch
1

Ich habe 2 Bluetooth-Adapter
1x fest onboard
1x extra gekauft

Den onboard hatte ich bis jetzt per udev Regel deaktiviert. Siehe hier :

Das erzeugt aber eine Menge Fehlermeldungen im journalctl.
Wie geht es eleganter ?

Der onboard scheint default zu sein. Wenn ich mit rfkill den onboard blocke geht Bluetooth überhaupt nicht mehr.
Und nach einem Neustart ist auch wieder alles beim alten.

Edit:

inxi -Eazy                                                                                                                                    

Bluetooth:
  Device-1: ASUSTek ASUS USB-BT500 type: USB driver: btusb v: 0.8
    bus-ID: 1-4.2:3 chip-ID: 0b05:190e class-ID: e001 serial: <filter>
  Report: rfkill ID: hci1 rfk-id: 1 state: up address: see --recommends
  Device-2: Cambridge Silicon Radio Bluetooth Dongle (HCI mode) type: USB
    driver: btusb v: 0.8 bus-ID: 7-1:2 chip-ID: 0a12:0001 class-ID: fe01
  Report: ID: hci0 rfk-id: 0 state: up address: N/A

bluetoothctl list                                                                                                                                   
Controller 00:02:72:D5:4A:3A weingeist-PC #1 [default]
Controller 04:42:1A:54:DA:3A weingeist-PC

Nach Eingabe von

bluetoothctl select 04:42:1A:54:DA:3A                                                                                                               
Controller 04:42:1A:54:DA:3A weingeist-PC [default]

Soweit funktioniert das. Ich mache mal einen Neustart

Edit 2:

Nach dem Neustart ist natürlich wieder alles beim alten :sleepy:

Hilfe

2

Welches DE nutzt du? Du könntest bei KDE beispielsweise mit dieser Anleitung ein simples Skript erstellen, welches

bei jedem Start deines Systems für dich ausführt.

3

Danke dir, eine sehr interessante Alternative. Probiere ich aus.
Natürlich wäre es mir lieber wenn man einen Adapter irgendwie deaktivieren könnte.
So wie zB blacklist bei Modulen.

EDIT: Das funktioniert ! Befehl wird beim Start ausgeführt.

1 Like
4

Die udev Regel

SUBSYSTEM=="usb", ACTION=="add" , ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001", ATTR{authorized}="0"

funktioniert ja, erzeugt aber diese Fehlermeldung :

systemd-udevd[397]: 7-1:1.0: /etc/udev/rules.d/01-Cambridge-Silicon-Radio.rules:3 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/authorized}, ignoring: No such file or directory
systemd-udevd[386]: 7-1:1.2: /etc/udev/rules.d/01-Cambridge-Silicon-Radio.rules:3 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/authorized}, ignoring: No such file or directory
systemd-udevd[394]: 7-1:1.1: /etc/udev/rules.d/01-Cambridge-Silicon-Radio.rules:3 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/authorized}, ignoring: No such file or directory
5

Ich glaube (ich weiß es noch nicht 100%) ich habe den Fehler gefunden.
Die hoffentlich korrekte udev Regel

SUBSYSTEM=="usb", ACTION=="add" , ATTR{idVendor}=="0a12", ATTR{idProduct}=="0001", ATTR{authorized}="0"

Es erscheinen keine Fehlermeldungen.
Der Unterschied anstatt ATTRS jetzt ATTR

Kann da wer mal schauen ob das so richtig ist ?