diff --git a/CorsairDriverBugfix/doc/notes.txt b/CorsairDriverBugfix/doc/notes.txt
index 4cb9f839337755ed7e45b276b020d0206101f4fd..05dbc52afb29281b3ac2e57772ed5103e079959b 100644
--- a/CorsairDriverBugfix/doc/notes.txt
+++ b/CorsairDriverBugfix/doc/notes.txt
@@ -58,6 +58,12 @@ Interessant hier: Der Report Descriptor liefert Auskunft über alle Telegramme,
 
 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 
@@ -68,4 +74,3 @@ hid-input:
 
 
 
-