Raw Input: Maus-Anzahl und Info über HIDs

[Schrompf]

Hallo Leute,

ich habe vor kurzem erst festgestellt, dass DirectInput seit irgendeiner ewig alten Version alle Mäuse und Tastaturen eines Rechners zusammenfasst. Zum Kotzen, ganz ehrlich. Das "Direct" im Namen können sie sich eigentlich sparen. Nunja, der aktuelle Weg für alle Art von PC-Spielen scheint also zu sein, RawInput zu benutzen. Also schreibe ich gerade OIS auf RawInput um.

Dazu als erstes: wenn ich die Devices des Systems durchgehe, finde ich da zwei Mäuse, obwohl ich nur eine angesteckt habe. Die eine hat angeblich 60Hz Abtastrate und nur zwei Tasten, die andere mit einer sehr viel höheren ID dann die erwarteten drei Tasten und gar keine Abtastrate mehr. Hat jemand von Euch schonmal Erfahrungen mit RawInput gesammelt und kann mir sagen, wie ich damit umgehe? Ich müsste ja herausfinden, welche davon die richtige ist. Ist das evtl. der PS2-Port? Wenn ja, wie kriege ich raus, ob da wirklich ne Maus dranhängt? Bei zwei angesteckten Mäusen seh ich dann drei Mäuse in der Liste.

Das gleiche Spiel übrigens auch mit Tastaturen: da seh ich auch zwei, mit identischen Product/Vendor-IDs, nur dass die eine halt 264 Tasten hat.

Und als zweites: Welche Möglichkeiten gibt es, weitere Infos über die Generischen HIDs zu bekommen? Der XInput-Hack prüft ein paar MagicBytes im Device-Namen, aber ich weiß nicht mal, ob er damit alle Joysticks/GamePads erkennt oder nur die XBox Controller. Wie kann ich sicher herausfinden, von welcher Art das Gerät ist und was es so für Tasten/Sticks/Achsen hat?

Danke schonmal!

bye, Thomas

[Schrompf]

Ich mach bald meinen eigenen Jammer-Thread auf. Das Eingabe-Problem erweist sich als Fass ohne Boden. Für GamePads muss ich dann doch wieder DirectInput oder XInput nutzen, oder ich klappe den HID-Driver direkt ab... er hier verrät, wie es geht. DirectInput könnte mir zwar die Namen der Controls geben, legt aber manche davon zusammen. XInput funktioniert sehr direkt und angenehm, geht aber nur wirklich nur für die XBox-Controller. Und ob am PS2-Port nun was angeschlossen ist oder nicht, kriege ich immernoch nicht raus.

Nun stellt sich aber auch heraus, dass da irgendwelche Sachen im Speicher verschoben sind. RawInput gibt mir ein Eingabeereignis in zwei verschachtelten unions, die in Kurzform so aussehen:

Code: Alles auswählen

struct Ereignis
{
  struct Header header;
  union data
  {
    MouseData mouse;
    KeyboardData keyboard;
    SonstigesData sonstiges;
  }
};

und ein ganz schlichtes

Code: Alles auswählen

const auto& maus = event.data.mouse;

gibt mir eine Referenz, die 8 Byte vor dem liegt, was im Speicher tatsächlich die Mausdaten empfängt. Was zur Hölle passiert hier? Und was für ein inkompetenter Haufen Deppen kriegt es nicht hin, ein definiertes Speicherlayout für seine Daten festzulegen, wenn er den Zugriff darauf nur über die obligatorischen KopierMirDenMistAberSagNichtWasDrinIst-Methoden möglich ist. Ich könnt mich aufregen.

[Schrompf]

Und: das verdammte Drecks-RawInput ist wieder an die alten Windows-Messages gekoppelt. Man bekommt pro Read()-Aufruf nicht etwa alle seit dem letzten Aufruf aufgelaufene Events, sondern Windows PeekMessage()/GetMessage konsumieren die Dinger auch. HAAAAAASSSSSSSSSSS. Was das wieder der Software-Architektur für Schaden zufügt...

[Jonathan]

Das klingt wirklich deprimierend.
http://en.wikipedia.org/wiki/DirectInpu ... _vs_XInput

Das gute ist, ich habe seit neulich ein XBox Gamepad, ich musste es kaufen, weil der dritte Prince of Persia Teil mit Maus einfach unspielbar war (die 2 davor gingen super, wer programmiert nur so einen Dreck?). Also so ein Gamepad ist schon witzig, aber oft finde ich Maus + Tastatur einfach besser.
Ich vermisse auch die Zeiten, als man einen Joystick noch sinnvoll einsetzen konnte. Damals bei Earth Siege 2 hatte man damit wirklich fast das Gefühl im Cockpit zu sitzen, mit einem Gamepad hat man das überhaupt nicht mehr. Ich würde ja auch heute mir gerne noch einen Joystick kaufen, aber es scheint kein einziges Spiel zu geben, wo sich das lohnen würde. Dumme Konsolenportierungen.

Also sieht es jetzt so aus, dass in Zukunft am PC nur noch das XBox Gamepad funktioniert, und Lenkräder/Joysticks nur noch für extrem seltene Exotenspiele zu gebrauchen sind? Und das alles, wegen Microsofts kundenfeindlicher Politik und der Tatsache das heute jedes Spiel innerhalb von 2 Wochen portiert und rausgehauen wird, anstatt es auf die Möglichkeiten der einzelnen Plattformen anzupassen?

Naja, ich bin ja gespannt, wie deine Geschichte ausgeht. Aber besonders toll wohl nicht, wie es scheint. Was benutzt du eigentlich momentan für Maus/Tastatur?

[Schrompf]

Für Maus/Tastatur benutze ich jetzt RawInput, was abgesehen von obigen Meckereien inzwischen ganz gut klappt. Gut, der InputMapper hintendran hat auch noch seine Bugs im Bezug auf mehrere Mäuse, aber die kriege ich noch raus. GamePads und Joysticks liegen aktuell brach, aber die kriege ich über RawInput auch noch hin. Oder ich führe doch DirectInput parallel wieder ein, da gibt es nämlich auch so freundliche Helferlein wie z.B. die lokalisierten Namen für alle Tasten.

Wenn's am Ende alles mal läuft, wäre es glatt eine Idee, es in die (abgestorbene) OIS-Entwicklung zurückzufüttern. Ich würde damit allerdings auch die Pflege-Verantwortung übernehmen. Und das schaffe ich aktuell nichtmal sinnvoll für Assimp, noch mehr Verantwortung hilft da nicht.

[BeRsErKeR]

Vielleicht hilft dir dieser Artikel weiter.

[Schrompf]

So, von der Reise zurück. Und nun geht's mit dem selben Fleiße wieder an die selbe Scheiße.

Danke für den Link, den hab ich zwei Beiträge höher auch schon gepostet. Ich muss mal schauen, wie ich die notwendigen Includes und Linkerlibs zusammenbekomme, ohne auf jedem Build-Rechner das Treiber-SDK vorauszusetzen.

[dot]

Wenn du tatsächlich Joysticks supporten willst, dann würd ich an deiner Stelle wohl DirectInput benutzen, denk ich. Es gab da auch eine Joystick API in der "normalen" WinAPI, aber ka ob die was taugt...

[Schrompf]

Nein, DirectInput fällt wohl aus, weil es von XBox-Controllern die beiden Schulter-Buttons zusammenlegt. Die sind nämlich analoge Buttons. Und da Microsoft damals Angst hatte, dass Spiele nicht mit Eingabeachsen klarkommen, die von 0 bis Plus anstatt von Minus bis Plus gehen, haben sie die beiden Buttons als zwei Richtungen der selben Achse gemappt. Mit dem Ergebnis, dass das Drücken beider Buttons gleichzeitig nicht vom Loslassen beider Buttons gleichzeitig unterscheidbar ist.

Ich weiß nicht, wie oft ich diesen Stein schon den Berg hochgerollt habe... er rollt halt immer wieder auf der anderen Seite runter. Und ich höre jetzt nicht mehr auf, bis ich nicht DIE ULTIMATIVE INPUT-API gebaut habe. So.

[BeRsErKeR]

Und ich höre jetzt nicht mehr auf, bis ich nicht DIE ULTIMATIVE INPUT-API gebaut habe. So.

Na das ist doch mal eine Ansage. Wenn du fertig bist, würd ich die dann auch gern nutzen. ;)

[Thoran]

Nein, DirectInput fällt wohl aus, weil es von XBox-Controllern die beiden Schulter-Buttons zusammenlegt.

Nur so interessehalber, evt. hast du es auch erwähnt, oder kannst es nicht sagen, aber willst du auch für XBOX entwickeln?

Thoran

[dot]

Nein, DirectInput fällt wohl aus, weil es von XBox-Controllern die beiden Schulter-Buttons zusammenlegt.

Naja, für den XBox Controller gibts natürlich XInput. Ich hab nicht besonders viel Erfahrung mit dem ganzen Input Kram. Und mir ist klar dass du gerne nur eine API verwenden würdest. Aber ich fürchte der ordentliche Weg führt wohl über 3 APIs (RAW Input, XInput, DirectInput)...Wobei ich mir die Frage stellen würde, ob Joystick Support für mein Spiel überhaupt was bringt und ich mich nicht einfach mal auf Maus, Keyboard und XBox Controller beschränken kann...

[Schrompf]

"Nur eine API" ist ja nur ein Wunsch von mir. Inzwischen wär ich zu allem bereit, um verlässliche Ergebnisse zu bekommen. Aber das Ding ist halt, dass ich bisher bei jeder Lösung irgendwelche Probleme gefunden habe, die ich als ShowStopper betrachte.

Windows Input-Message:
- nur eine Maus/Tastatur
- begrenzte Auflösung der Eingabewerte
+ dafür schon mit Mausbeschleunigung und anderen Nutzer-Einstellungen vorverarbeitet

DirectInput:
- nur eine Maus/Tastatur
- XBox-Controller mit teilweise verkrüppelten Buttons
+ kann alle Pads und Joysticks verarbeiten
+ kann auch die Systemnamen von Tasten liefern, was für Lokalisierung, Control Remapping und die GUI dazu sehr praktisch ist
+ theoretisch Force Feedback-Unterstützung

XInput:
- kann nur XBox-Controller. Auch beliebige andere Pads werden ignoriert, sonstige HIDs eh
- Erkennung dieser Controller nur über Magic Strings in der Device Description - it's bound to break
+ sehr einfache und geradlinige Werteabfrage
+ Force Feedback-Unterstützung

RawInput:
- es werden Geister-Geräte gemeldet
- die API ist armselig und die Doku wie von einem besoffenen Praktikanten geschrieben
- Alignment-Probleme! Weil das Umkopieren von 40 Byte an eine vorgegebene Adresse ja auch ein unlösbares Problem der Informatik ist...
- nur Maus & Tastatur werden native unterstützt, alle anderen HIDs werden als unkommentierter Haufen Bytes abgeladen
+ kann mehrere Mäuse und Tastaturen unterscheiden
+ Force Feedback nur über direkte USB-HID-Interface-Nutzung

Meine Meinung zu diesem Gestrüpp: I don't want to be a programmer anymore.

[Jonathan]

Hm, und wie sieht es mit OIS oder ähnlichem aus? Das benutzt in der Windows Version auch einfach DInput und hat die selben Beschränkungen?

[Schrompf]

Ich habe bisher OIS benutzt, zusammen mit einem Wrapper von Tilman (Sternmull) damals, der Control Remapping und einige Bequemlichkeits-Features bringt. Hat mir auch lange Jahre gute Dienste geleistet, Danke dafür nochmals! Allerdings fing mit Splatter dann meine Odyssee an - zuerst die Erkenntnis, dass ich dann *doch* analoge Achsen auf Buttons mappen muss und umgekehrt, dann die Feststellung der zusammengelegten Achsen auf XBox-Controllern, dann diverse OIS-Bugs bei der Benutzung mehrerer GamePads, dann die Integration des XInput-Patches in OIS, dann die Feststellung, dass ich damit wirklich *nur* XBox-Controller lesen kann, dann die Feststellung, dass DirectInput alle Mäuse und Tastaturen zusammenlegt, dann die Feststellung, dass die aktuelle Microsoft-Empfehlung "RawInput" eine reichlich grobe Grütze mit absurder Doku ist, dann die Feststellung, dass ich damit wieder an Windows Messages gebunden bin, dann die Feststellung, dass Controller damit gar nicht sinnvoll unterstützt werden.

Jetzt ziele ich auf eine Misch-Implementation von RawInput und DirectInput, muss dazu allerdings ein bisschen um die doch reichlich dummen OIS-Strukturen herumbauen... irgendwer damals dachte, er müsste ein paar mehr OO-Patterns im Code haben, weswegen man bei OIS jetzt mit 1 bis x Factories zu tun hat, die nach Vendor-String entscheiden, ob sie ein Device erzeugen können oder nicht. Viele Hundert Zeilen Bullshit für "Gib mir die nächste noch freie Maus".

[BeRsErKeR]

Also soweit ich gesehen habe wird wirklich meist eine Kombination aus 2-3 der genannten APIs genutzt. DirectInput für Gamepads + Joysticks, RawInput für Maus + Tastatur und XInput für XBox-Controller. Vielleicht gibt es da ja schon weiterführende APIs/Wrapper, die man nutzen kann.

[Schrompf]

OIS ist angeblich eine weiterführende API.... andere APIs habe ich nicht gefunden und auch ehrlich gesagt nicht sonderlich intensiv gesucht. Die meisten Input-APIs kommen nur in Verbindung mit einer Game Engine.

Neue Erkenntnisse von der Input-Front: Maus und Tastatur gehen jetzt prima. Wenn ich eine zweite Tastatur per PS2 anschließe, taucht die *zusätzlich* in der Enumeration auf. Die Geister-Tastatur, die ich da sehe, stammt also irgendwo anders her. Ich habe sie jetzt einfach aussortiert, was Dank der Meldung von "264 Tasten" recht einfach ist. Die Geistermaus ist leider nicht so einfach auszusortieren - die meldet genauso zwei Tasten wie die testweise am PS2-Port angesteckte Maus. Nach welchem Kriterium kann ich also diese Geistermaus aussortieren?

GamePads gehen jetzt wieder über DirectInput, ich habe die entsprechenden Code-Teile aus dem SVN zurückgeholt. Nur die XInput-Erkennung ist etwas geradegezogen und erkennt und unterscheidet jetzt zuverlässig 0 bis 4 XBox-Controller. Die orginale OIS-Erkennung hatte da noch einen Bug und hat alle Pads zusammengelegt... manchmal frage ich mich, ob die Leute ihren Code auch mal testen.

[edit] Zu früh gefreut. Wenn man die PS2-Maus wieder absteckt, bleibt der Eintrag aber in der RawInput-Deviceliste, bis man neubootet. Jetzt habe ich also zwei Geistermäuse anstatt einer. Ich fühl mich bei der Input-Geschichte ein wenig in die Steinzeit der Spieleprogrammierung zurückversetzt - damals war noch akzeptabel, dass System-APIs auch mal Scheiße zurückliefern.

[Jonathan]

Hm, aber ist das nicht so, dass PS2 einfach nicht Plug'n'Play ist? Ich meine mich zu erinnern, früher mal eine Maus mit Wackelkontakt gehabt zu haben, die war dann plötzlich eingefroren, ging nach einem Neustart aber wieder problemlos. Und mal ehrlich, wer benutzt heute noch PS2?

[BeRsErKeR]

Ja PS/2 ist nicht Plug'n'Play-fähig. Ist also normal, dass die erst nach nem Reboot verschwindet. Genausowenig kann man die hinzufügen, während der PC läuft. Und ich kann Jonathan nur Recht geben: die Zeiten in denen PS/2-Mäuse genutzt wurden, sind längst vorbei. Ich weiß gar nicht ob neurere PCs noch PS/2-Anschlüsse haben, Laptops jedenfalls nicht und eine USB-Maus kostet ja auch nicht die Welt.

Zu den Geistermäusen/-tastaturen: Hast du vielleicht irgendeine Software drauf, die sowas emuliert? Vielleicht sowas wie die Eingabehilfe von Windows oder die Bildschirmtastatur, die eventuell auch als Device mit gelistet wird. Ist nur eine Vermutung. Gibt es sonst keine Unterscheidungsmöglichkeiten? Statuswerte/Flags/usw? Kenn mich mit RawInput leider nicht aus.

[Schrompf]

PS2 ist anscheinend teilweise Plug&Play-Fähig... wenn ich was anstecke, wird das erkannt und löst (teilweise) die Standard-Windows-Treiberreaktion aus. Zumindest die Tastatur war so. Bei der Maus haben mir dann zig Millionen Interupts pro Sekunde das System hakelig gemacht, bis ich neugebootet hatte. Aber diese "Plug&Play"-Reaktion kann natürlich auch einfach nur die Reaktion auf ein Signal der Tastatur sein... wer weiß.

Wenn man USB-Geräte an- und absteckt, bekommt man saubere RawInput-Nachrichten. Damit umzugehen dürfte einfacher werden.

[BeRsErKeR]

Die Schnittstelle ist nicht für Hot Plugging, also Stecken im laufenden Betrieb, vorgesehen, weder das Protokoll noch die Steckverbinder erlauben das.[2] In vielen Fällen funktioniert es zwar (eher bei Tastaturen als bei Mäusen), theoretisch könnten aber Computer oder Tastatur beziehungsweise Maus dabei zerstört werden – zumindest aber einfach nicht erkannt. Gerne hängte sich früher auch das Betriebssystem, beim Einstecken einer PS/2-Maus, auf.

(Quelle: http://de.wikipedia.org/wiki/PS/2-Schnittstelle)

[Stephan Theisgen]

^^ und das sollte man nicht unterschätzen. Ich habe früher so schon einen PS2-Anschluß eines Computers für immer gekillt. Einfach nur ne Tastatur bei laufendem Betrieb ausgetauscht... Tja sowas war früher halt nicht möglich. Da hieß es runterfahren und neustarten, wenn man mal ne andere Tastatur anschließen wollte.

[BeRsErKeR]

Genau deshalb sollte man heutzutage kein PS/2 mehr nutzen, es sei denn man ist durch alte Hardware dazu gezwungen. Viele Hersteller verzichten gänzlich auf PS/2-Anschlüsse, sie also in einer Input-API zu unterstützen ist also auch nicht unbedingt zeitgemäß.

[Schrompf]

Gut, ich brauche mir über PS2-Geräte also keine wirklichen Gedanken zu machen. Wenn der Nutzer ein PS2-Gerät benutzt, kann es nach dem Anstecken bis zum Reboot eh nicht benutzt werden und nach dem Reboot taucht es ganz banal in der Device-Liste auf.

Bei den "Geister"-Mäuse und -Tastaturen gibt es auch Neuigkeiten: ich vermute anhand des Namen-Strings "RDP_MOU" bzw. "RDP_KBD", dass die Produkte einer RemoteDesktop-Anwendung sind. Anhand dieses Namens kann ich sie jetzt auch rausfiltern. Ich habe jetzt ein bisschen Angst, was es da draußen sonst noch alles für Konstrukte gibt, auf die ich jetzt noch nicht vorbereitet bin. Abgesehen davon geht es aber langsam vorwärts - z.B. versorgt mich jetzt ein Dummy-Keyboard von DirectInput wieder mit lokalisierten Tastennamen. Ob das gleiche Spiel auch für Joysticks und Pads klappt, werde ich noch herausfinden.

[dot]

Abgesehen davon geht es aber langsam vorwärts - z.B. versorgt mich jetzt ein Dummy-Keyboard von DirectInput wieder mit lokalisierten Tastennamen.

Vielleicht hilft dir das und das?

[Schrompf]

Danke. Ich habe mich danach blödgegoogelt. Die zweite Funktion sieht echt nützlich aus, da brauche ich kein Dummy-Keyboard mehr.

[Schrompf]

Zu früh gefreut. GetKeyNameText() versagt bei Buchstaben und Zahlen und kann LStrg nicht von RStrg unterscheiden, obwohl es getrennte ScanCodes sind. Zurück zum Dummy-Keyboard von DirectInput.

[dot]

Was is mit Bit 25 im lParam

"Do not care" bit. The application calling this function sets this bit to indicate that the function should not distinguish between left and right CTRL and SHIFT keys, for example.

hilft das nicht?

[Schrompf]

Nein. Damit erzwinge ich das Verhalten, dass ich jetzt eh schon kriege, aber eigentlich gern vermeiden wollen würde: die Unterscheidung zwischen linker und rechter Strg wird ignoriert.

Es hat sich aber inzwischen auch herausgestellt, dass da noch irgendwelche KeyCodes schräg liegen. Mit DirectInput bekomme ich z.B. wieder Tastennamen für alle Tasten, aber die Cursortasten erscheinen als Ziffernblock-Zahlentasten oder als richtig wirre Keycodes unbekannter Herkunft, wenn man Numlock ausmacht. Eigentlich... ja eigentlich... eigentlich hab ich ja Besseres zu tun als solchen Details hinterher zu jagen.

[dot]

Merkwürdig. Es ist nur so, dass DirectInput für Keyboard und Mouse intern afaik nichts anderes tut als Raw Input zu benutzen. Natürlich kann's sein, dass es für den ganzen Enumeration Kram dann doch irgendwie direkt mit den Treibern redet...

Internally, DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly.