notes.txt

|=== : Trennzeichen

# sysfsutils beinhaltet systool -- Anzeige, welche Parameter akzeptiert werden.
systool -vm usbhid

|===

lsmod # Listen der geladenen Module evtl. einmal ohne dongle und mit dongle in Datei schreiben und mittels diff analysieren, welche Treiber geladen werden.
Links mit Dongle; Rechts ohne:
	diff lsmodWithDongle.txt lsmodWithoutDongle.txt 
	3c3
	< snd_usb_audio         176128  2
	---
	> snd_usb_audio         176128  0
	52c52
	< snd                    81920  27 snd_usb_audio,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_hda_codec_analog
	---
	> snd                    81920  23 snd_usb_audio,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_hda_codec_analog

|===

dmesg # Beinhaltet auch Informationen, welche Treiber geladen werden.
	[ 2560.047464] perf interrupt took too long (2521 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
	[ 3052.284075] usb 3-1: USB disconnect, device number 2
	[ 3085.016021] usb 3-1: new full-speed USB device number 3 using uhci_hcd
	[ 3085.278039] usb 3-1: New USB device found, idVendor=1b1c, idProduct=1b27
	[ 3085.278045] usb 3-1: New USB device strings: Mfr=3, Product=4, SerialNumber=0
	[ 3085.278049] usb 3-1: Product: Corsair VOID Wireless Gaming Dongle
	[ 3085.278052] usb 3-1: Manufacturer: Corsair
	[ 3085.565157] input: Corsair Corsair VOID Wireless Gaming Dongle as /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.3/0003:1B1C:1B27.0008/input/input18
	[ 3085.620234] hid-generic 0003:1B1C:1B27.0008: input,hiddev0,hidraw4: USB HID v1.11 Device [Corsair Corsair VOID Wireless Gaming Dongle] on usb-0000:00:1a.0-1/input3

|===

Treiber einem Gerät zuweisen oder Gerät von Treiber trennen:
cd /sys/bus/usb/drivers/hiddev
ls
#B-P:C.I ist die Form von Interface Dateinamen
B = Bus Nummer, P String der Portnummer, C Konfigurationswert, I Interfacenummer
# Treiber entladen:
	echo -n interface-filename > unbind
# Treiber laden:
	echo -n interface-filename > bind

|===

lsusb liefert die USB Adresse, an der der USB-Dongle zu erreichen ist:
lsusb
	Bus 003 Device 003: ID 1b1c:1b27 Corsair

ls /sys/bus/usb/drivers/hiddev
	lrwxrwxrwx 1 root root    0 Mai 14 18:26 3-1:1.3 -> ../../../../devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.3

|===

lsusb -vvv | more # Hochdetailierte Informationen über alle USB Geräte
Interessant hier: Der Report Descriptor liefert Auskunft über alle Telegramme, die das Gerät als Human Interface Device senden kann und bietet damit die Möglichkeit das Gerät zu betreiben ohne einen speziellen Treiber für dieses spezifische Gerät schreiben zu müssen. Falls der Descriptor nicht zu den in der Realität vorhandenen Daten passt, kann es zu Problemen kommen.

Eine Vermutung von mir: In den HID-Treiben werden Mutexe verwendet. Ich könnte mir vorstellen, dass falls im Descriptor ein Telegramm fälschlicherweise zu lang angemeldet wird, dass ein Mutex für den Lesevorgang blockiert wird und nicht wieder auftaut, da ein zu kurzes Telegramm angekommen ist. (Würde erklären, weshalb Funktionen teilweise noch funktionieren, aber Tasten fälschlicherweise als gedrückt empfunden werden z.B. Eventuell passt die Kommunikation auch nicht mehr, wenn das falsche Telegramm kommt und durch STRG+ALT+F1 und anschließendes zurückwechseln in den xserver werden die Puffer neu initialisiert.

Andere Vermutung: Geräte die eine Fehlfunktionalität auslösen senden ein HID Event, das fehlinterpretiert wird oder vom Hersteller für eine Zusatzfunktionalität missbraucht wird und löst damit das seltsame Verhalten des XServers aus. Ein stark ähnliches Verhalten des XServers ist nachstellbar, indem man eine zweite Maus anschließt und eine beliebige Taste gedrückt hält. Auch in diesem Fall lassen sich manche Elemente nicht mehr anklicken und Fensterelemente geben kein visuelles Feedback mehr, wenn die Maus über sie hinweg fährt. Für diese Vermutung spricht auch, das mittels einer Umschaltung in ein tty und zurück in den XServer der Fehlklick bereinigt bzw. ignoriert oder ungülgtig wird, sodass trotz der weiterhin gedrückten Taste alle Elemente wieder richtig reagieren und bedienbar sind.

Zur genaueren Untersuchung, ob die Vermutung eines fälschlicherweise gesendeten Events von problematischer Hardware die Ursache ist, sollte in dem Treiber für HID-Geräte genauer untersucht werden, welche HID-Events tatsächlich generiert werden. Mittels der Spezifikation von USB.org \cite{USB-HUT_v1-12} ist nachvollziehbar, welche Events sinnvoll und welche vielleicht für eine Sonderfunktion vom Hersteller missbraucht wurden. Über die Analyse des Rohdatenverkehrs ist dann genauer analysierbar, welches ein problematisches Telegramm sein kann.

Für den Fall das es tatsächlich ein Telegramm gibt, dass zwar richtig aufgebaut und vom HID-Treiber interpretiert wird, in dem Kontext der Funktionstasten des Headsets aber fehl am Platze ist, wäre die Lösung die Erstellung eines eigenen Treibers für die Hardware, der den bisherigen HID-Treiber initialisiert und verwendet, problematische Telegrammteile aber zum Beispiel weg schneidet. Für den unwahrscheinlichen Fall, dass der derzeitig aktuelle HID-Treiber ein Telegramm nicht richtig behandelt, kann ein Update des Treibers hid-input das Problem beheben.  

Möglicherweise interessante Treiber, um die Theorie zu bestätigen:
	snd
	hid-input 
	hid-generic

hid-input:
	Implementiert Kommandos (Keycodes) nach Spek.: usb-hid.c Z:749: USB HUT v1.12, pages 75-84 */