Wird die Fn Taste Hardwaremässig anders ausgewertet, als andere Tasten ? Sie Liefert keinen Scancode, und unter einem frisch installierten Windows klappen meist die Fn Sonderfunktionen ohne Treiben, und das obwohl sich die Fn Funktionen und Tasten je Laptop stark unterscheiden. Ich habe den Eindruck, das diese Taste gar nicht an den Tastaturkontroller angeschlossen ist, sondern direkt mit einem Controllerchip verbunden ist. Kurz gesagt: wie funktioniert die Fn Taste ?
Der Controller der Tastatur wertet die FN Taste aus. Wenn FN+XXX dann sende YYY, wenn FN+ZZZ dann sende ÄÖÜ, ...
Die Tastencodes werden mit einer Matrix aus Reihen und Zeilen ausgelesen. Vermutlich wird mit der FN-Taste auf eine andere Reihe (nur für fn) umgeschaltet. Die Shift-taste hat degegen einen eigenen scancode, da diese Taste von vielen Betriebssystemen auch alleine benutzt wird.
Ich denke das wird im Bios stattfinden, denn mit der FN Taste kann man ja uch die Helligkeit steuerern - das kann aber normalerweise der Tastaturcontroller nicht. Im Bios kann auch jeder Hersteller die Belgung der FN-Sonderfunktionen anpassen.
Einen dedizierten Tastaturcontroller kennen die meisten Notebooks nicht, da hängt mehr dran. Beispiel Thinkpad: Dort hat beim letzten (?) CCC-Congress jemand einen Hack vorgestellt, in dem der Controller die Funktion eines Keyloggers übernommen und per Tastaturbeleuchtung versendet hat. Um die Ereignisse unter Windows abzufragen (z.B. für's OSD oder Helligkeitsregelung per Mobilitätscenter etc.), klinkt sich die Software an den Controller an. Details: http://de.wikipedia.org/wiki/Embedded_Controller
Zusammenfassend: Die Tastatur hängt bei PCs und Laptops nicht direkt am eigentlichen Rechner, sondern da ist schon immer ein kleiner Mikrocontroller in der Tastatur selbst. (und ab dem AT auch einer im Rechner) Bei Laptops macht dieser Microcontroller auch häufig noch andere Sachen wie beispielsweise die Tastaturbeleuchtung oder den Ladezustand. Das BIOS muss da normalerweise nichts groß machen außer gegebenenfalls die gewünschten Einstellungen an den Tastaturcontroller schicken.
hownottobeseen (ohne login) schrieb: > Einen dedizierten Tastaturcontroller kennen die meisten Notebooks nicht, > da hängt mehr dran. Ich stell mir das so vor: der Kontroller fragt die Tastaturmatrix ab, generiert die Scancodes, Steuert die LCD Helligkeit, Lautstärke und die anderen Funktionen der Fn Taste. Ist da meine Vorstellung korrekt ? hownottobeseen (ohne login) schrieb: > Um die Ereignisse unter Windows abzufragen (z.B. für's OSD oder > Helligkeitsregelung per Mobilitätscenter etc.), klinkt sich die Software > an den Controller an. Soweit klar, kann das Betriebssystem denn überhaupt das Drücken der Fn Taste erkennen ? Bios: Ich glaube jetzt nicht, das das Bios noch irgendwas mit der Tastaur zu tun hat (ausser beim Booten)
Silvia A. schrieb: > Ich stell mir das so vor: der Kontroller fragt die Tastaturmatrix ab, > generiert die Scancodes, Steuert die LCD Helligkeit, Lautstärke und die > anderen Funktionen der Fn Taste. Ist da meine Vorstellung korrekt ? Naja, nicht ganz. Bei den aktuellen Laptops macht das alles das Betriebssystem. Bei meinem Dell kann ich ohne laufendes OS und das entsprechende Systemprogramm keine Lautstärke, Helligkeit usw. regeln. Nicht mal CD auswerfen geht ohne OS, weil da ein Slot-In Laufwerk drin ist. > Soweit klar, kann das Betriebssystem denn überhaupt das Drücken der Fn > Taste erkennen ? Nein, im Normalfall nicht. Wie schon gesagt, das wird im Tastatur Controller abgefangen. Ob der jetzt ein dedizierter Tastaturcontroller ist oder Teil eines größeren Controllers, ist dabei egal. Im Windows kommen nur die generierten Scancodes an, und die wechseln, je nachdem ob du die Fn Taste drückst oder nicht.
>Ich denke das wird im Bios stattfinden, denn mit der FN Taste kann man >ja uch die Helligkeit steuerern - das kann aber normalerweise der >Tastaturcontroller nicht. Im Bios kann auch jeder Hersteller die Belgung >der FN-Sonderfunktionen anpassen. Das sind normalerweise ACPI Events und einige von denen haben auch einen Scancode den sie zurückgeben. z.B. mein Thinkpad T61 und mein X61 geben für Helligkeit sowie die Tastaturbeleuchtung einen Scancode, ein ACPI Event und schalten unabhängig vom Betriebssystem die Beleuchtung ein und aus bzw. dimmen die Displaybeleuchtung. >klinkt sich die Software an den Controller an. ACPI >Ich stell mir das so vor: der Kontroller fragt die Tastaturmatrix ab, >generiert die Scancodes, Steuert die LCD Helligkeit, Lautstärke und die >anderen Funktionen der Fn Taste. Ist da meine Vorstellung korrekt ? Halbwegs, manche Tastaturcontroller machen das von sich aus, manche generieren direkt ein ACPI Event, manche lassen das BIOS die Arbeit machen. >Soweit klar, kann das Betriebssystem denn überhaupt das Drücken der Fn >Taste erkennen ? Mir ist bisher noch kein Laptop in die Finger gekommen, der gemeldet hat, dass die FN Taste gedrückt wurde. Gibt es aber mit sicherheit auch irgendwo... Es gibt ja auch PC Tastaturen mit FN, müsste man mal xev unter Linux anschmeissen und gucken. Unter Windows weiss ich kein Programm beim Namen...
>Wird die Fn Taste Hardwaremässig anders ausgewertet, als andere Tasten ? >Sie Liefert keinen Scancode, Kaum. Die funktioniert wie die Shift oder Ctrl-Taste auch. Der Code dafür wandert über den Bus und kann dann auch von anderen Peripherie-Geräten abgefragt werden.
...die FN-Taste wird genauso ausgewertet wie alle anderen Tasten. Der einzige Unterschied ist, dass die FN-Taste selbst keinen Scancode produziert. Die FN-Taste verändert aber die Scancode der anderen gedrückten Tasten. (i.d.R. nur einen "Make"-Code, aber keinen "Break"-Code) Gruß Tom
Stuntman Mike schrieb: > Kaum. Die funktioniert wie die Shift oder Ctrl-Taste auch. Nö. Shift/Ctrl/Alt usw. schicken Scan-Codes. Der Rechner (Tastatur-Treiber) verwaltet selber, ob diese gerade gedrückt sind oder nicht. Dieser entscheidet dann, ob dein Druck auf die "z"-Taste ein Z oder z (oder Y, ...) generiert. die Fn-Tasten, die ich bislang (mit xev) überprüft habe, tun dies nicht. Da wertet der Tastaturcontroller selber den Fn-Status aus, und modifiziert die Scancodes der damit zusammen gedrückten Tasten. > Der Code > dafür wandert über den Bus und kann dann auch von anderen > Peripherie-Geräten abgefragt werden. Wie jetzt? Irgendwelche Peripherie-Geräte sollen immer den Systembus belauschen, um festzustellen, ob da in den vielen, vielen MB an sonstigen Festplatten/Video/... - Daten ein Tastendruck für sie dabei ist? Bei PCIe geht das dann wohl nicht mehr, wegen Point-To-Point Verbindungen?
>Nö. Shift/Ctrl/Alt usw. schicken Scan-Codes. Der Rechner >(Tastatur-Treiber) verwaltet selber, ob diese gerade gedrückt sind oder Richtig. >Da wertet der Tastaturcontroller selber den Fn-Status aus, und >modifiziert die Scancodes der damit zusammen gedrückten Tasten. Durchaus möglich. >Wie jetzt? Irgendwelche Peripherie-Geräte sollen immer den Systembus >belauschen, um festzustellen Prinzipiell ist jedes Busgerät fähig den Master zu spielen. Die Fn-Taste kann ganz einfach einen eigenen Interrupt erzeugen, der dann (unter Ausschluss der CPU) weiter gereicht wird. Das heist aber nicht, dass es prinzipiell nicht möglich ist diese Taste in Software zu tracen, denn man kann den Tastaturcontroller auch bitten Zeichen zu wiederholen. Das ist aber spezifisch.
Stuntman Mike schrieb: > Prinzipiell ist jedes Busgerät fähig den Master zu spielen. Die Fn-Taste > kann ganz einfach einen eigenen Interrupt erzeugen, der dann (unter > Ausschluss der CPU) weiter gereicht wird. Du bist Dir aber schon dessen bewusst, daß weder der Controller, der die Tastaturmatrix abfragt (und diversen Pofel der Notebookhardware ansteuert) noch der klassische irgendwo im Chipsatz vergrabene sogenannte "Tastaturcontroller" am PCI(e)-Bus hängt?
Stuntman Mike schrieb: > Das heist aber nicht, dass es > prinzipiell nicht möglich ist diese Taste in Software zu tracen, denn > man kann den Tastaturcontroller auch bitten Zeichen zu wiederholen. Das > ist aber spezifisch. Sehr spezifisch. Beim 08/15-Fall könnt ich das ja mal prüfen. USB-Tastatur mit FN-Taste hätte ich (zuhause), aber ob USB-Snoopy/wireshark &co auch USB-Traffic mitloggen können, den der HID-Treiber schon für sich geclaimt hat? Oder einen einfacheren, weniger aussagekräftigen Test: Mit Shift/Ctrl/Alt alleine krieg ich den Rechner aus dem Sleep geweckt. Ob das mit Fn alleine auch geht, könnte ich testen. Stuntman Mike schrieb: > Prinzipiell ist jedes Busgerät fähig den Master zu spielen. das heißt aber nicht, dass es auch auf Daten zugreifen kann, die ein komplett anderes Gerät auf einem anderen Bus an einen anderen Empfänger schickt. So ein Bus-"Sniffing" wird zwar an manchen Stellen im PC tatsächlich gemacht (z.B. für Cache Coherency im SMP-Betrieb) aber ganz sicher nicht dafür, dass z.B. die Soundkarte auch ohne Mitwirken der CPU die Lautstärke-Tastendrücke mitlesen kann. Das macht normalerweise das Bios, und/oder ein Windows-Treiber, der dann z.B. auch gleich passende Symbole am Bildschirm einblenden kann. Oder es läuft über eine seperate Verbindung, z.B. der "rf-kill" Switch zum Abschalten von Wlan bei manchen Notebooks.
>Du bist Dir aber schon dessen bewusst, daß weder der Controller, der die >Tastaturmatrix abfragt (und diversen Pofel der Notebookhardware >ansteuert) noch der klassische irgendwo im Chipsatz vergrabene >sogenannte "Tastaturcontroller" am PCI(e)-Bus hängt? Das ist absolut dem Chipdesigner überlassen und ein USB-Gerät wird ganz sicher am PCI-Bus hängen. Wie es mit dem klassischen 8042 zusammen hängt weiss ich nicht und spielt auch keine Rolle, denn aus Sicht der Cpu ist der Vorgang transparent. Über EA-Befehle kann ich direkt mit dem Tastaturprozessor kommunizieren (wie mit jedem anderen Gerät auch). Möglich, dass er mir die Fn-Taste vorhält aber das glaub ich nicht. >das heißt aber nicht, dass es auch auf Daten zugreifen kann, die ein >komplett anderes Gerät auf einem anderen Bus an einen anderen Empfänger >schickt. Haste dir eigentlich mal angeguckt, wie so ein Datenbus mit angeschlossener Peripherie aussieht? Jedes Gerät was dran hängt kann zumindest mitlesen und theoretisch auch manipulieren. Du musst die Daten bloss mit mehr Strom treiben wie dein Kontrahent. Das ist die eine Methode und die andere ist so dirty, dass ich sie hier nicht hinschreibe. (Wer im PCI-Bereich arbeitet, kann es sich aber selbst herleiten.)
Tom schrieb: > Die FN-Taste verändert aber die Scancode der anderen > gedrückten Tasten. Irgendwie bezweifel ich das. Ich vermute, das es nicht einen einzigen Scancode gibt, der durch Fn + $Taste erzeugt wird. Ich lass mich aber gerne eines besseren belehren.
Bemerkenswert mit wie wenig Ahnung hier jede Menge Behauptungen aufgestellt werden... Also ich entwickle seit Jahren Tastaturcontroller, von da her habe ich so ein kleines Bisschen Einblick wie das funktioniert. Grundsätzlich ist die Fn-Taste keine Taste wie alle anderen. Sie erzeugt KEINEN Scancode, sondern wird i.d.R. vom Tastaturcontroller (also dem Chip der in der Tastatur sitzt) ausgewertet und sorgt dafür, dass dann ggf. andere Scancodes gesendet werden. Ähnlichkeiten mit den Modifiers (Shift, Control, Alt, GUI) sind da wenig vorhanden, weil die Modifiers, abgesehen von ein paar strunzdummen Kombinationen am PS/2, halt genau nicht den Scancode der anderen Tasten ändern, sondern dazu führen, dass der Tastaturtreiber andere Zeichen bzw. Signale aus den Scancodes erzeugt. Bei Notebooks kann es vorkommen, dass die interne Tastatur elektronisch anders aufgebaut ist und nicht am USB oder PS/2 hängt. Aber auch hier wird die Fn-Taste dann von der wie auch immer gearteten Tastaturkonstruktion intern ausgewertet und erzeugt selbst keinen Scancode. Allerdings kann es hier ggf. möglich sein den Status der Fn-Taste abzufragen. @Stuntman Mike: Lehn Dich nicht zu weit aus dem Fenster. Von USB hast Du offensichtlich keine Ahnung. Es ist da grundsätzlich nicht sicher, dass andere Geräte die Daten überhaupt auf ihrem Zweig des USB sehen. Das hängt u.a. von der Topologie (Hubs usw.) und der Busgeschwindigkeit ab. Abgesehen davon kennt der USB nur einen Master und das ist der Host, Devices haben hier genau nicht die Möglichkeit Master zu werden. Eine Abweichung davon ist USB-on-the-go, aber hier kann dann ein Gerät wahlweise als Device oder Host funktionieren und das muss dann wieder der einzige Host sein und kann nicht dynamisch zwischen den Betriebsarten wechseln.
>Bemerkenswert mit wie wenig Ahnung hier jede Menge Behauptungen >aufgestellt werden... Dass ich mich hier nicht auch angepisst fühle, gehe ich davon aus, dass der Herr und Meister mich damit nicht meint, da ich ja wohl genau das selbe wie er schon ganz weit oben geschrieben habe. Ich habe nichts mit den Controllern an sich zu tun, ich habe schon mehrere Tastatur-Treiber geschrieben. AT, PS/2 und USB auf PC, AVR, 8051 und ARM. Einen Steuercomputer mit 8080 aus einer Laufschrift einer Waschanlange hab ich auf PS/2 Tastatur (zum Programmieren der Texte) umgebaut, da der eine XT Tipse wollte, die aber nicht immer 100%ig erkannt wurde. Ich kenn mich da wohl auch ein wenig aus...
Nils S. schrieb: > Dass ich mich hier nicht auch angepisst fühle Das bezog sich wohl ziemlich eindeutig auf den Herrn, der meinte, alles wäre an irgendwelchen Bussen sichtbar.
>Das bezog sich wohl ziemlich eindeutig auf den Herrn, der meinte, alles >wäre an irgendwelchen Bussen sichtbar. Es ging auch nicht um den USB-Bus sondern um PCI. Auch eine USB-Tastatur wird irgendwann den Scancode da rüberschicken und dort kann sie eben jedes masterfähige und an den PCI-Bus angeschlossene Gerät abfragen. Das kann die Haupt-Cpu sein, der Grafikcontroller oder die Netzwerkkarte. Und ob die Tastatur nun einen Modifier für den Scancode einer Taste oder den modifizierten Scancode selbst sendet ist dabei völlig belanglos.
Stuntman Mike schrieb: > jedes masterfähige und an den PCI-Bus angeschlossene Gerät abfragen Abgesehen davon, dass deine Vorstellung "etwas" verquer ist: Was machen dann neue PCs mit PCIe? Haben die dann keine Tastatur mehr, weil PCIe nur noch serielle Punkt-zu-Punkt Verbindungen hat?
Stuntman Mike schrieb: > Es ging auch nicht um den USB-Bus sondern um PCI. Auch eine USB-Tastatur > wird irgendwann den Scancode da rüberschicken Wenn die Tastatur per USB und der USB-Controller per PCI angeschlossen ist, und Dein "masterfähiges Gerät" den kompletten USB-Host-Stack nachbildet, um das zwischen USB-Controller und Prozessor ausgetauschte Protokoll mitzuhören, dann mag Deine These zutreffen. Das ist aber für die eigentliche Betrachtung vollkommen irrelevant. Außerdem sind die Tastaturen in üblichen Wintel-Notebooks nicht per USB angeschlossen, sondern nach wie vor über Fragmente der klassischen IBM-AT-Architektur (PS/2-Tastatur an an ISA-Bus angebundenen "Tastaturcontroller"), und der fragmentarische ISA-Bus via LPC mit dem Chipsatz verbunden ist, wird da Dein PCI-Device schlichtweg nichts von mitbekommen können. Aber selbst wenn es das könnte, wäre dies für die Klärung der Frage, wer wann und wo diese spezielle Taste auswertet, völlig irrelevant, denn es ist sicher, daß das nicht so geschieht, wie Du Dir zusammenreimst.
Beim Loslassen der Fn-Taste (ohne andere zusätzlich gedrückte Tasten) an meinem Thinkpad gibt es folgende unerwartete X-Events:(auch das Keypress-Event kommt erst beim Loslassen)
1 | KeyPress event, serial 33, synthetic NO, window 0x4000001, |
2 | root 0x83, subw 0x0, time 85326097, (-335,168), root:(289,247), |
3 | state 0x10, keycode 151 (keysym 0x1008ff2b, XF86WakeUp), same_screen YES, |
4 | XLookupString gives 0 bytes: |
5 | XmbLookupString gives 0 bytes: |
6 | XFilterEvent returns: False |
7 | |
8 | KeyRelease event, serial 33, synthetic NO, window 0x4000001, |
9 | root 0x83, subw 0x0, time 85326109, (-335,168), root:(289,247), |
10 | state 0x10, keycode 151 (keysym 0x1008ff2b, XF86WakeUp), same_screen YES, |
11 | XLookupString gives 0 bytes: |
12 | XFilterEvent returns: False |
Stuntman Mike schrieb: > Es ging auch nicht um den USB-Bus sondern um PCI. Auch eine USB-Tastatur > wird irgendwann den Scancode da rüberschicken und dort kann sie eben > jedes masterfähige und an den PCI-Bus angeschlossene Gerät abfragen. Das war ungefähr so hilfreich wie die Aussage, dass der Computer mit Strom funktioniert und daher jeder der eine Katze streichelt auch einen Computer versorgen kann. Abgesehen von den bereits gegen Deinen verqueren Einwurf vorgebrachten Argumenten: Wie erkennt denn ein Busteilnehmer wann da Tastaturdaten vorbei kommen? Ich denke mal Du hängst gedanklich noch in der Zeit der RS-232 Schnittstellen. USB ist ungleich komplexer und spielt eher in der Gewichtsklasse einer Netzwerkverbindung, dank der Geräteklassen teilweise sogar noch komplizierter. Und im Gegensatz zum "Hineinlauschen" direkt in den Kommunikationskanal, also das USB Kabel, ist das Abfangen der Daten hinter dem Hostcontroller auf dem lokalen Bus praktisch zum Scheitern verurteilt, da dort jede Menge Daten vorbei kommen. Ganz abgesehen davon, dass so keine sinnvollen Funktionen in einem Computer arbeiten, derartiges würde man ggf. im Labor beim Entwickeln und Testen verwenden, nennt sich "Busanalyzer", davon stehen für verschiedene Busse einige um mich rum... @Nils S.: Du darfst Dich völlig unangepisst fühlen ;)
Guido Körber schrieb: > Abgesehen von den bereits gegen Deinen verqueren Einwurf vorgebrachten > Argumenten: Wie erkennt denn ein Busteilnehmer wann da Tastaturdaten > vorbei kommen? Wieso sollten sich Grafikkarte und co. für Tastatureingaben interessieren ? ist doch nur für die cpu von interesse
Rufus Τ. Firefly schrieb: > Stuntman Mike schrieb: >> Es ging auch nicht um den USB-Bus sondern um PCI. Auch eine USB-Tastatur >> wird irgendwann den Scancode da rüberschicken > > Wenn die Tastatur per USB und der USB-Controller per PCI angeschlossen > ist, und Dein "masterfähiges Gerät" den kompletten USB-Host-Stack > nachbildet, um das zwischen USB-Controller und Prozessor ausgetauschte > Protokoll mitzuhören, dann mag Deine These zutreffen. Als Busmaster hört es aber nicht mit, sondern macht selbst die Kommunikation. Die Host-CPU darf also den USB-Controller gar nicht verwenden, dafür muß das Gerät auch noch den Treiber für den USB-Controller enthalten. Tom K. schrieb: > Beim Loslassen der Fn-Taste (ohne andere zusätzlich gedrückte Tasten) > an meinem Thinkpad gibt es folgende unerwartete X-Events:(auch das > Keypress-Event kommt erst beim Loslassen) Interessant. Bei mir kommt das auch. Aber es wäre gut möglich, daß das nur gemacht wird, damit die bei anderen Tasten üblichen "Nebenwirkungen", wie z.B. das Abschalten des Screensavers, auch mit dieser Taste gehen. Deshalb kommen die Events auch erst beim Loslassen, denn erst dann weiß der Controller, daß man keine Fn-Kombination drücken wollte. Entsprechend kommen diese Events dann übrigens auch nicht, wenn ich Fn mit einer beliebigen anderen Taste in Kombination drücke.
Am EeePC 701 erzeugt ein Drücken/Loslassen der Fn-Taste gar keinen Scan/Keycode. In Verbindung mit den entsprechenden Tasten kommt sowas wie Xf86AudioRaiseVolume raus.
@rufus >Wenn die Tastatur per USB und der USB-Controller per PCI angeschlossen >ist, und Dein "masterfähiges Gerät" den kompletten USB-Host-Stack >nachbildet, um das zwischen USB-Controller und Prozessor ausgetauschte >Protokoll mitzuhören, dann mag Deine These zutreffen. >Das ist aber für die eigentliche Betrachtung vollkommen irrelevant. Du brauchst bloss den PCI-Controller abzufragen (adr.: 0xcf8 / data: 0xcfc; geht auch über das Bios). Der listet dir alle angeschlossenen Geräte sukzessive auf und dann wirst du auch sehen, dass da der USB-Controller ganz sicher mit auftaucht, genauso wie die Grafikkarte oder der Realtek-Chip. >Außerdem sind die Tastaturen in üblichen Wintel-Notebooks nicht per USB >angeschlossen, sondern nach wie vor über Fragmente der klassischen >IBM-AT-Architektur (PS/2-Tastatur an an ISA-Bus angebundenen >"Tastaturcontroller"), und der fragmentarische ISA-Bus via LPC mit dem >Chipsatz verbunden ist, wird da Dein PCI-Device schlichtweg nichts von >mitbekommen können. Richtig, habe ich aber auch nicht anders behauptet. >Aber selbst wenn es das könnte, wäre dies für die Klärung der Frage, wer >wann und wo diese spezielle Taste auswertet, völlig irrelevant, denn es >ist sicher, daß das nicht so geschieht, wie Du Dir zusammenreimst. Es ist ein theoretiches Beispiel, welches sich auch in die Praxis umsetzen lässt. @Guido Körber >ist das Abfangen der Daten hinter dem Hostcontroller auf dem lokalen Bus >praktisch zum Scheitern verurteilt, da dort jede Menge Daten vorbei >kommen. Das... :-))) >Ganz abgesehen davon, dass so keine sinnvollen Funktionen in >einem Computer arbeiten, derartiges würde man ggf. im Labor beim >Entwickeln und Testen verwenden, nennt sich "Busanalyzer", davon stehen >für verschiedene Busse einige um mich rum... und dieses, passt so schon mal nicht zusammen. Im übrigen hatte ich schon das Vergnügen Full-Speed-USB zum Ansprechen von USB-Sticks auf einem x3s400-tq144 zu implementieren. Die Phy hat weniger wie 200 slices gekostet.
Stuntman Mike schrieb: > Es ist ein theoretiches Beispiel, welches sich auch in die Praxis > umsetzen lässt. Ich kann auch die Tastatur mit einer Kamera überwachen, und erkennen, wenn der Benutzer den Finger auf der fn-Taste hat, und per Mikrophon den "Klick" beim Betätigen auswerten. Ist auch ein theoretisches Beispiel, welches sich auch in die Praxis umsetzen lässt. Trotzdem wirst du keinen PC oder Notebook finden, der das so implementiert.
>"Tastaturcontroller"), und der fragmentarische ISA-Bus via LPC mit dem >Chipsatz verbunden ist, wird da Dein PCI-Device schlichtweg nichts von >mitbekommen können. Ich muss mich korrigieren. Die ISA-Bridge lässt sich über den PCI-Controller auch fangen, ich weiss aber nicht, ob man die Tastatur auf diesem Weg auch abfragen kann.
>Trotzdem wirst du keinen PC oder Notebook finden, der das so >implementiert. Kannst du das überhaupt beurteilen?
Stuntman Mike schrieb: > @rufus >>Wenn die Tastatur per USB und der USB-Controller per PCI angeschlossen >>ist, und Dein "masterfähiges Gerät" den kompletten USB-Host-Stack >>nachbildet, um das zwischen USB-Controller und Prozessor ausgetauschte >>Protokoll mitzuhören, dann mag Deine These zutreffen. >>Das ist aber für die eigentliche Betrachtung vollkommen irrelevant. > Du brauchst bloss den PCI-Controller abzufragen (adr.: 0xcf8 / data: > 0xcfc; geht auch über das Bios). Der listet dir alle angeschlossenen > Geräte sukzessive auf und dann wirst du auch sehen, dass da der > USB-Controller ganz sicher mit auftaucht, genauso wie die Grafikkarte > oder der Realtek-Chip. Er hat nirgends behauptet dass der USB-Controller nicht auftaucht...
Stuntman Mike schrieb: > Du brauchst bloss den PCI-Controller abzufragen (adr.: 0xcf8 / data: > 0xcfc; geht auch über das Bios). Der listet dir alle angeschlossenen > Geräte sukzessive auf und dann wirst du auch sehen, dass da der > USB-Controller ganz sicher mit auftaucht, genauso wie die Grafikkarte > oder der Realtek-Chip. Zwar ist das so, aber das hat mit der Funktion der Tastatur erst recht überhaupt gar nichts zu tun. Und den USB-Controller am PCI-Bus zu finden bringt Dich der Erkennung der gedrückten Tasten exakt keinen Schritt weiter. Einerseits wird Dein PCI-Bus-Master nicht den Datenverkehr eines anderen PCI-Bus-Masters abhören können, andererseits ist auch dann eine sehr aufwendige Analsyse des USB-Protokolls erforderlich, schließlich hängt am USB mehr als nur eine Tastatur. Mir scheint, daß Du die eigentliche Problemstellung nicht erkannt hast (oder erkennen willst) - es geht nicht darum, herauszufinden, auf welchen verworrenen Wegen man möglicherweise eine Tastatur abfragen könnte, sondern darum, wie eine reale Tastatur in einem realen Notebook ausgewertet wird.
Ich hab mal den Eingabegeräten meines EeePC versucht nachzuspüren. Die Tastatur scheint von einer i8042-Atrappe gelesen zu werden, das Touchpad scheint an einem (virtuellen) PS/2-Port zu hängen; nach dem Entladen des psmouse-Moduls geht das Touchpad nichtmehr.
>Einerseits wird Dein PCI-Bus-Master nicht den Datenverkehr eines >anderen PCI-Bus-Masters abhören können Der Koprozessor macht nichts anderes, als den Datenbus mitzuschneiden und er wird genauso separat vom Pci-Controller gelistet. >Und den USB-Controller am PCI-Bus zu finden bringt Dich der Erkennung der >gedrückten Tasten exakt keinen Schritt weiter. Der Pci-Controller ist nicht nur für die programmierbare Recourcenverteilung (I/O, Interrupts) zuständig, man kann über ihn auch jedes Gerät ansprechen was dran hängt. Er ist Mittler für jedes Gerät und kann bei jedem Tastendruck selektiv entscheiden, welches Gerät (Grafikkarte, CPU) zu benachrichtigen ist. >sondern darum, wie eine reale Tastatur in einem realen >Notebook ausgewertet wird. Na, das muss ich irgendwie übersehen haben.
Ich habe hier das gefühl, das jede menge Sonderfälle angesprochen werden, aber der Standartfall (Laptop) irgendwie untergegangen ist. Ich freue mich das so viele Experten hier mitmischen, aber ich hab den durchblick verloren. Wieso lauschen da irgendwelche Bus Komponenten auf Tastatureingaben ? Ich war bisher immer der meinung, lediglich die CPU interessiert sich für Tastatureingaben. >...sondern darum, wie eine reale Tastatur in einem realen Notebook ausgewertet wird. Und wie geschieht das ? >(also dem Chip der in der Tastatur sitzt) Bei Laptops gibt es einen Chip in der Tastatur ? Wieso haben dann die Folienleiter so viele Pinne ? Ich hab den Eindruck, das hier die Tastaturmatrix selbst rausgeführt ist. Stuntman Mike schrieb: > Die Fn-Taste kann ganz einfach einen eigenen Interrupt erzeugen Kann sie das Wirklich ? Oder ist sie nur eine Taste von vielen in der Tastaturmatrix ?
Silvia A. schrieb: > Wieso lauschen da irgendwelche Bus Komponenten auf Tastatureingaben ? Das tun sie nicht, das ist nur die etwas bizarre Annahme von "Stuntman Mike". Silvia A. schrieb: > Bei Laptops gibt es einen Chip in der Tastatur ? > Wieso haben dann die Folienleiter so viele Pinne ? Ich hab den Eindruck, > das hier die Tastaturmatrix selbst rausgeführt ist. Der "Chip in der Tastatur" sitzt auf der Notebook-Hauptplatine, und ist mit dem Folienleiter verbunden. Dieser Chip ist üblicherweise auch für die Ansteuerung diverser anderer notebookspezifischer Dinge zuständig. Verbunden ist dieser Chip auf mehrfachem Wege mit der "Standard-PC-Hardware" des Notebooks, einerseits über die klassische "PS/2"-Tastaturschnittstelle, andererseits für Akkumanagement, Displaybeleuchtungssteuerung, weitere Powermanagementdinge, Lüftersteuerung etc. mit anderen Schnittstellen des Chipsatzes. Die klassische "PS/2"-Tastaturschnittstelle wiederum besteht aus dem sogenannten "Tastaturcontroller", der seit 1986 im IBM AT-Hardwaredesign verwendet wird. Der ist natürlich bei allen PCs der letzten Jahre nur noch als IP-Core in irgendeinem hochintegrierten Baustein enthalten.
Silvia A. schrieb: > Wieso lauschen da irgendwelche Bus Komponenten auf Tastatureingaben ? Tun sie nicht. Was Stuntman vermutlich meint: Mit viel Geld und teuren Komponenten könnte man einen Recher bauen, bei dem Komponenten ausser der CPU auf Tastatureingaben lauschen. >>...sondern darum, wie eine reale Tastatur in einem realen > Notebook ausgewertet wird. > Und wie geschieht das ? Der Tastaturkontroller wertet die Fn-Taste aus. d.H. das läuft anders als Shift/Ctrl/Alt/Numlock/Capslock, wo die Auswertung vom Tastaturtreiber übernomen wird. > Bei Laptops gibt es einen Chip in der Tastatur ? Immer. der macht aus "vielen Leitungen" für die Tastenmatrix "wenige Leitungen" (üblich: Serielle übertragung) zum Chipsatz. Der Chip muss aber natürlich nicht mechhanisch in/unter der Tastatur liegen, wenn sich das besser ausgeht, kann der auch anders positioniert werden. Aber "logisch"/"historisch bedingt" ist er Teil der Tastatur, auch wenn er inzwischen als Siliziumkrümel in einem anderen Chip mit verschwunden ist. >> Die Fn-Taste kann ganz einfach einen eigenen Interrupt erzeugen > Kann sie das Wirklich Könnte (unwarscheinlich, eher polling). Aber wenn: der Interrupt wäre lokal nur für den Tastaturcontroller. Hat nix mit Interrupts die an die CPU gehen zu tun. Zum Aufwachen mit "Fn" aus dem Sleep: Tom K. schrieb: > Beim Loslassen der Fn-Taste (ohne andere zusätzlich gedrückte Tasten) > an meinem Thinkpad Ist eine Eigenheit des Thinkpad-Tastaturcontrollers, und macht deshalb auch keinen anderen Wakeup-Interrupt als jede andere Taste.
Εrnst B✶ schrieb: > Silvia A. schrieb: >> Wieso lauschen da irgendwelche Bus Komponenten auf Tastatureingaben ? > > Tun sie nicht. Was Stuntman vermutlich meint: Mit viel Geld und teuren > Komponenten könnte man einen Recher bauen, bei dem Komponenten ausser > der CPU auf Tastatureingaben lauschen. Selbst das wird heutzutage kaum noch klappen. Man schaue sich mal das Blockdiagramm einer typischen Southbridge an: http://www.via.com.tw/en/products/chipsets/southbridge/vt8261/index.jsp Tastautur und Maus gehen da parallel zum externen PCI-Bus in die Bridge rein, d. h. man kann auf dem externen PCI-Bus von deren Aktivititäten nichts mehr mitmeißeln.
Jörg Wunsch schrieb: > Selbst das wird heutzutage kaum noch klappen. Klar doch (Für den Tastatur->USB->PCIe Fall, der oben skiziert war). LA und Busanalyzer zum Preis eines Oberklassewagens(*) mit in den Rechner schrauben und fertig :) Oder aber beim Hersteller einen Custom-Chipsatz als Einzelstück anfordern, der die nötigen Signale nochmal extra rausführt. *) Hab grad keinen Preis gefunden, was will z.B. LeCroy für so einen PCIe Tracer?
Εrnst B✶ schrieb: > Tastatur->USB In einem Laptop ? gibt es da einen Virtuellen USB Port ? Oder beziehst du dich da auf Desktop Rechner (Die ja keine Fn Taste haben) ?
@Stuntman Mike: Du holst Dir auch die Registeradresse des Ethernetcontrollers wenn Du auf eine Website zugreifen willst? @Silvia A.: Den Stuntman am Besten ignorieren, was er über Busse und Tastaturen schreibt ist bestenfalls theoretisch denkbar wenn man unbedingt einen Computer bauen will der wie eine Rube Goldberg Maschine funktioniert. Die kurze und knappe Antwort auf Deine Frage ist, dass die Fn-Taste keine "offizielle" Taste ist, sondern intern in der Tastatur verarbeitet wird. Wie die Tastatur im Detail konstruiert ist kann deutlich variieren und möglicherweise laufen Teile davon als Software auf dem Hauptprozessor. Logisch ist es aber auch dann ein Vorgang innerhalb des Gerätes "Tastatur". @Εrnst B✶: Hab die Preisliste auch nicht griffbereit, aber so was liegt typischerweise zwischen einem Audi A6 und einem Einfamilienhaus.
Guido Körber schrieb: > Wie die Tastatur im Detail konstruiert ist kann deutlich variieren > und möglicherweise laufen Teile davon als Software auf dem > Hauptprozessor. Wenn dem der Fall wäre, dann könnte man entsprechende Details in den Keyboard-Treibern der Opensource-Betriebssysteme wiederfinden (denn diese Systeme greifen ansonsten direkt auf die PS/2-Hardware- Emulation zu). Ich kann mich nicht daran erinnern, dort entsprechendes je gesehen zu haben.
Jörg Wunsch schrieb: > Wenn dem der Fall wäre, bräuchte jede Tastatur auch einen anderen Treiber. Die einzig logische Konsequenz ist, dass der Tastaturcontroller das Mapping intern macht und den entsprechenden Tastencode an das OS schickt.
Vlad Tepesch schrieb: > Die einzig logische Konsequenz ist, dass der Tastaturcontroller das > Mapping intern macht und den entsprechenden Tastencode an das OS > schickt. Eben. Wobei dieser Tastaturcontroller nicht der in den Chipsatz integrierte 8042 ist, sondern der, der die Tastaturmatrix auswertet. Ein abweichendes Hardwaredesign gibt es allerdings auch, das findet man in aktuellen Notebooks von Apple. Bei denen sind Tastatur und Trackpad ein USB-Kombigerät; einen 8042 im Chipsatz gibt es dort nicht (oder er führt ein Zombiedasein ohne Funktion).
Guido Körber schrieb: > @Εrnst B✶: Hab die Preisliste auch nicht griffbereit, aber so was liegt > typischerweise zwischen einem Audi A6 und einem Einfamilienhaus. http://www.home.agilent.com/agilent/product.jspx?nid=-34355.806947.00&cc=US&lc=eng
>Tastautur und Maus gehen da parallel zum externen PCI-Bus in die >Bridge rein, d. h. man kann auf dem externen PCI-Bus von deren >Aktivititäten nichts mehr mitmeißeln. Was ist das denn für eine lächerliche Begründung? Ob der Bus auf dem Mainboard zusammengeführt wird (wie es früher war) oder erst im Chip macht doch überhaupt gar keinen Unterschied. Der einzige Grund warum das heute extern getrennt ist, ist die kapazitive und induktive Leitungskopplung aufgrund der zunehmenden Geschwindigkeit. Und selbst wenn ich intern nicht direkt mitschneiden könnte (!), dann kann ich immer noch auf die Speicheradressen zugreifen, auf die vormals ein Gerät geschrieben hat. Vielleicht solltet ihr euch alle mal das Prinzip eines DMA-Controller vor Augen führen. Es gibt keine Speicherrestriktion zwischen den Geräten! Ich geb's auf. Keiner von euch hat das Prinzip eines Bussystem jemals verinnerlicht. (Vom PCI-Bus ganz zu schweigen.) Das gerade jedes Gerät auf die Resourcen eines anderen zugreifen kann (insbesonder des RAM) macht den den Datenverkehr so flexibel und ist unabdingbar. Es ist einfacher einer Bäckereifachverkäuferin zu erklären, was der Unterschied zwischen Amplituden- und Frequenzmodulation ist und warum letzteres die besssere Sprachqualität bietet. Absolut sinnlos, hier weiterzuschreiben. @Guido Körber Junge, ich kauf dir noch nicht einmal ab, dass du einen läppischen Tatstaurcontroller (nur den in der Tastatur) programmieren kannst. Aber Partei ergreifen, das kannste gut!
Stuntman Mike schrieb: > Es ist einfacher einer Bäckereifachverkäuferin zu erklären, was der > Unterschied zwischen Amplituden- und Frequenzmodulation ist und warum > letzteres die besssere Sprachqualität bietet. Natürlich ist das einfacher, du Witzfigur! Da die nichts davon versteht, glaub sie deinen Unsinn einfach. Hier hast du aber Leute vor dir, die du mit fachlich Korrekten Aussagen überzeugen müsstest. Und daran scheiterst du wohl ;-)
Stuntman Mike schrieb: > Ich geb's auf. Keiner von euch hat das Prinzip eines Bussystem jemals > verinnerlicht. Nein. Du hast nicht begriffen, worum es hier geht, und ein bizarres Geflecht aus Nebenschauplätzen aufgemacht, die allesamt nichts mit dem Thema in diesem Thread zu tun haben. Hier sind sowohl Leute unterwegs, die schon sehr lange wissen, was Bussysteme sind und was mit ihnen möglich sind, als auch Leute, die ziemlich genau wissen, wie die PC-Architektur aufgebaut ist. Du magst prinzipiell auch wissen, wie Busse funktionieren, das will ich nicht abstreiten, aber was Du definitiv überhaupt nicht verstanden hast, ist die Fragestellung. Auch nach mehrfachen Hinweisen nicht, weiterhin wirfst Du abstruseste Informationsnebelkerzen. Niemanden (außer Dir) hat es interessiert, ob es irgendwie möglich ist, am dafür vorgesehenen Hard- und Softwaredesign vorbei an Informationen der Tastatur zu gelangen. Warum hast Du nicht auch noch einen Vortrag über die HF-Abstrahlungen aktueller PC-Technik verfasst, über die auch eine Rekonstruktion der Vorgänge in der Tastatur möglich ist? Wäre das selbst Dir zu abwegig gewesen?
Stuntman Mike schrieb: > Und selbst wenn ich intern nicht direkt mitschneiden könnte (!), dann > kann ich immer noch auf die Speicheradressen zugreifen, auf die vormals > ein Gerät geschrieben hat. Vielleicht solltet ihr euch alle mal das > Prinzip eines DMA-Controller vor Augen führen. Was hat das alles mit der Tastatur zu tun? Oder glaubst du etwa, die schreibt per DMA direkt in den Speicher?
@Stuntman Mike: Da wir beim Bezweifeln von Kompetenzen sind, ich denke Dein (vorgebliches) USB Design wird wohl von der unterirdischen Sorte sein. Deine Beiträge lesen sich so, als wenn Dir nicht klar ist, dass ein USB Gerät nicht im Adressraum des Computers ist, sondern sich ähnlich einem Netzwerkgerät ausserhalb davon befindet und nur indirekt adressierbar ist. Wie schon mehrfach bemerkt wurde haben Deine Einlassungen für die eigentliche Frage keinerlei Wert. Es ist völlig unerheblich, ob man auf irgend einem Weg die Daten der Tastatur mithören kann, die Frage war nur wie die Fn-Taste funktioniert. Die meisten der von Dir behaupteten Funktionalitäten existieren so einfach nicht in einem normalen Computer. Die Grafikkarte wird genau so wenig die Daten der Tastatur "mithören" wie in der Festplatte Eisenspäne auf die Oberfläche gestreut werden um die Daten dann mittels Kamera auszulesen. Und der Verweis auf DMA etc. ist völlig Banane in diesem Zusammenhang. Die Tastaturdaten lassen sich vom USB Controller nicht mehrfach abholen, sondern gehen an den zuständigen Treiber. Meistens werden die per DMA in den lokalen Buffer des Treibers kopiert, danach sind die genau da und nirgendwo anders mehr und da es sich um einen LOKALEN Buffer handelt ist ein Zugriff auf diesen von einer anderen Entität in einem halbwegs sauberen Betriebssystem auch nicht mehr gegeben. Auf jeden Fall sind Deine Beiträge in diesem Kontext bestenfalls so hilfreich, als wenn Du einen Vortrag über die Herstellung von Halbleitern begonnen hättest. @Jörg Wunsch: Ja, die Variante ist eher unüblich, wir haben so was aber schon für Kunden gemacht, die sehr komplexe Tastenkombinationen haben wollten, bei denen es unsinnig gewesen wäre die in den Controller zu programmieren, insbesondere da die Anforderungen nicht von Anfang an definitiv stabil waren. Dabei meldet sich dann die Tastatur nicht als Tastatur, sondern als Generic oder Vendor Specific HID an und wird mit einem eigenen Treiber oder Background-App versorgt, logisch erscheint die dann dem System gegenüber wieder als Tastatur.
Guido Körber schrieb: > Dabei meldet sich dann die Tastatur nicht als > Tastatur, sondern als Generic oder Vendor Specific HID an und wird mit > einem eigenen Treiber oder Background-App versorgt Klar, mit so einer Variante geht das natürlich. Wenn man den Treiber in der Hand hat, kann man damit immer allerlei Spielchen treiben. ;-)
Angehängte Dateien:
-
pci-e.jpg
66 KB -
pci.features.jpg
170 KB
>Da wir beim Bezweifeln von Kompetenzen sind, ich denke >Dein (vorgebliches) USB Design wird wohl von der unterirdischen Sorte >sein. Also ich habe die Specs für Pci-express und Pci und die gibt es nur für teuer zahlende Clubmitglieder. Hast du sie etwa auch? 700 PDF Seiten und die Tatsache, dass der Pci-Controller für jedes angeschlossene Gerät eigene Statusregister und Speicher mitbringt gehen weit, sehr weit über dein Verständis hinaus.
Zur Kompetenz gehört nicht nur der Zugriff auf Dokumente, sondern auch das Begreifen von Zusammenhängen. Wie die Diskussion hier deutlich gezeigt hast, hast Du auf dem zweiten Gebiet noch sehr ausbaufähiges Potential.
Stuntman Mike schrieb: > Also ich habe die Specs für Pci-express und Pci und die gibt es nur für > teuer zahlende Clubmitglieder Virtueller Schwanzvergleich ?
Oh, das wird ja immer besser. Du warst bestimmt auch jahrelang an der Uni, nur schade, dass Du nie rein gegangen bist... Aus dem adoleszenten Gehabe würde ich mal schätzen, dass ich schon lange mit Bussystemen zu tun hatte als Du noch versucht hast die Funktion von Legosteinen zu begreifen. Mit PCI habe ich auch schon mal ein Design gemacht, ist aber ein paar Tage her, da war der gerade neu.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.