Tastatur - Umwandlung von Keyboard-Scancode in ASCII-Zeichen
-
Hallo,
zufällig bin ich via google über dieses Projekt gestolpert und habe eine Frage zu der Umsetzung der Tastaturscancodes in ASCII-Zeichen. Ich hoffe, ihr könnt mir da bei einem Verständnisproblem weiterhelfen. Ich nehme an, ich habe da ein Brett vor dem Kopf.
Die Funktion UCHAR k_getch() hier http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId845287 zieht einfach über einen Aufruf
retchar = asciiNonShift[scan];
ein Zeichen aus der Keymap von hier http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId185043 um vom Scancode zum ASCII-Zeichen zu gelangen.Wenn ich vom üblichen Keyset2 einer Tastatur ausgehe und z.B. den Buchstaben 'c' nehme, hat dieser den Scancode 0x21. Mir ist völlig schleierhaft wie man mit
retchar = asciiNonShift[0x21];
auf das 'c' in diesem Array kommt. Einfach mal 33 abzählen geht nicht. Worin besteht da der Kniff?
-
Hallo commander_keen,
Da ich den Keyboard-Treiber von PrettyOS grade neu geschrieben habe, hab ich zufällig grade recht genau im Kopf, wie der alte (der weitgehend dem aus dem Tutorial entspricht) arbeitete.
Wenn ich vom üblichen Keyset2 einer Tastatur ausgehe
Die Prämisse ist falsch: Der KBC sendet standardmäßig Set 1 (Übersicht: http://www.marjorie.de/ps2/scancode-set1.htm). Es ist zwar richtig, dass die Tastatur Set 2 an den KBC sendet, der KBC übersetzt das jedoch nach Set 1 und sendet das dann an das OS.
Der Buchstabe 'c' aus deinem Beispiel hat also den Scancode 0x2E. Jetzt guckt der Keyboard-Treiber in dem array asciiNonShift an der Stelle 0x2E nach, und findet dort den Buchstaben 'c'.
Das im Tutorial verwendete Verfahren ist allerdings untauglich, um alle Tasten einer normalen Tastatur zu behandeln. Das war auch der Grund für den Rewrite des Tastaturtreibers von PrettyOS. Wie Du der o.g. Scancode-Tabelle entnehmen kannst, gibt es auch E0 und E1-codes, die aus mehreren Bytes bestehen. Der Keyboard-Treiber im Tutorial ignoriert diese. In PrettyOS hatten wir einige dieser Tasten über einen HACK zugänglich gemacht, indem wir das E0 einfach ignoriert haben und dann auf Kosten anderer Tasten (NUM-Block) einfach das zweite Byte des Scancodes mit der gleichen Tabelle wie für die normalen Scancodes übersetzt haben.
Ansonsten kann ich dir einen Blick in den neuen Keyboard-Treiber von PrettyOS empfehlen: http://prettyos.svn.sourceforge.net/viewvc/prettyos/trunk/Source/kernel/
Relevant sind die Dateien keyboard.h, keyboard.c und keyboard_GER.h, um das Prinzip zu verstehen.
Im neuen Treiber werden die Scancodes zunächst in Tasten (KEY_t) übersetzt, und diese dann, sofern es ein ASCII-Äquivalent gibt, unter Berücksichtigung des eingestellten Tastaturlayouts und dem Status der Shift- und AltGr-Taste übersetzt.mfg
Mr X
-
Hallo!
Nungut, ich sollte vielleicht hinzufügen, dass ich nicht an einem PC hinter einem extra Controller arbeite, sondern eine Tastatur an einem Mikroprozessor (Atmega88) betreibe. Mit KBC meinst du wahrscheinlich den auf dem Mainboard eines PCs? Dieser entfiele bei mir dann.Aber danke für den Hinweis, dann müsste ich das Array bei mir entsprechend für das verwendete Scanset erschaffen. Das sollte ja hoffentlich problemlos funktionieren. (auf die AltGr-Umschaltung etc. werde ich wohl verzichten für dieses kleine Projekt)
Leider hänge ich derzeit daran, dass derzeit manche Scancodes korrekt im µC ankommen und andere nicht (was sehr verwirrend ist, da ich die Bitmuster bereits als korrekt habe verifizieren können und der Code zur Umwandlung bzw. zum Mitschreiben der einzelnen Bits im Simulator perfekt funktioniert), aber damit hänge ich wohl eine Ebene tiefer als in diesem Projekt hier und stehe erstmal allein auf weiter Flur.
Übrigens habe ich hier 5 PS/2 Tastaturen und 1 oder 2 senden nicht mal Paritäts- oder Stoppbit richtig, es grenzt an ein Wunder, dass der KBC eines PC-Mainboards diesen "Murks" in jedem Fall korrekt umsetzt. :-o