From faa3208bdb2efaff3723997b0433204a23bf7a5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20L=C3=B6pke?= <loepke@edfritsch.de>
Date: Sat, 14 May 2016 19:49:08 +0200
Subject: [PATCH] Updated some content.

---
 CorsairDriverBugfix/doc/notes.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/CorsairDriverBugfix/doc/notes.txt b/CorsairDriverBugfix/doc/notes.txt
index b2b7c99..4cb9f83 100644
--- a/CorsairDriverBugfix/doc/notes.txt
+++ b/CorsairDriverBugfix/doc/notes.txt
@@ -58,6 +58,14 @@ 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.
 
+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 */
+
 
 
 
-- 
GitLab