Hallo Forum, ich habe hier eine spezielle Anfrage: Ist es möglich, eine USB-HID-(Zusatz-)tastatur zeitweise zu deaktivieren? Ich stelle mir das so vor, dass ein pfiffiger Zugriff auf ein Gerätehandle oder der Eingriff in die Registry das Gerät zeitweise aktiviert oder deaktiviert. Hinweise: - Betriebssystem ist Windows XP - USB VID und PID des Geräts sind bekannt Der Hintergrund ist der, dass das spezielle zu deaktivierende Gerät Zeichen sendet, die aber nur zur Eingabe gelangen sollen, wenn auch das entsprechende Fenster ausgewählt ist. Danke schon mal im Voraus!
Hast Du mal probiert, ob ein Deaktivieren/Aktivieren im Gerätemanager den gewünschten Erfolg bringt? Wenn das funktioniert, musst Du "nur" noch herausfinden, wie das programmatisch zu erledigen geht, und das bei jeder Focusänderung Deiner Anwendung durchführen.
Hm, ja, das ist interessant: Manche Gerät kann man im Geräte-Manager
aktivieren/deaktivieren, andere nicht. Meine Maus schon, Tastaturen
scheinbar nicht :-(
Es gibt da eine Kommandozeilenversion vom Gerätemanager (devcon.exe),
bei der das aber auch nicht funktioniert. Immerhin gibt es devcon im
Quelltext(!), Stichwort Setup-API. Warum man aber eine Tastatur nicht
deaktivieren kann bleibt im Dunkeln. Vielleicht eine fehlende Funktion
im USB-Stack ("SetConfiguration")? Keine Ahnung.
Das Kommandozeilentool von Microsoft für sowas heist sc.exe und ist eigentlich bei jedem Windows dabei. Und die richtige API dafür ist die Services-API (http://msdn.microsoft.com/en-us/library/ms685974.aspx).
Wie deaktivierst Du mit SC eine (von mehreren) Geräteinstanzen?
Von MS gibts das Tool devcon, damit lassen sich gezielt Geräte aktivieren/deaktivieren. Das in Kombination zum Beispiel mit EventGhost sollte dein Problem lösen. Dass das nur mit Admin-Rechten geht, sollte klar sein.
Ist die Tastatur ein Eigenbau oder muss das auch mit Standardtastaturen funktionieren? Wozu überhaupt? Gruß
Eddy Current schrieb: > Genau, aber ich kriege > > Beitrag "Re: HID-Tastatur programmgesteuert deaktivieren" > > nicht gelöst ;-) Oh sorry, überlesen....
guest schrieb: > Ist die Tastatur ein Eigenbau oder muss das auch mit Standardtastaturen > funktionieren? Es ist ein Eigenbau, verhält sich aber wie eine USB-Tastatur. > Wozu überhaupt? Das fragliche Gerät ist keine Tastatur, sondern ein Lesegerät ähnlich Barcodes, mit dem Informationen von Datenträgern direkt in Textdokumente gelesen werden. Jetzt ist gefordert, dass dieses Lesegerät deaktiviert werden kann, damit es im Alltag nicht "dazwischen funkt".
Was wäre davon zu halten, wenn das Gerät dahingehend modifiziert wird, daß es nicht die Scancodes normaler Tastaturen ausgibt, damit es nicht "dazwischenfunken" kann? Es gibt ja nun auch andere HID-Anwendungen, bei denen HID nur als Mittel zum Zweck genutzt wird, um keinen Devicetreiber entwickeln zu müssen, bei denen aber das HID-Gerät nicht einer vorhandenen Tastatur oder Maus dazwischenfunkt - das scheint mir sinnvoller zu sein als ein Aktivieren/Deaktivieren des zugehörigen Gerätetreibers.
Dem Gerät eine Funktion zu spendieren, daß es mal Sendepause macht ist keine Option? Grüße Nicolas
Rufus t. Firefly schrieb: > Was wäre davon zu halten, wenn das Gerät dahingehend modifiziert wird, > daß es nicht die Scancodes normaler Tastaturen ausgibt, damit es nicht > "dazwischenfunken" kann? Der Gag einer Tastaturemulation ist, dass bestehende Anwendungen ohne Modifikation genutzt werden können. Und genau dies ist der Fall. Nicolas S. schrieb: > Dem Gerät eine Funktion zu spendieren, daß es mal Sendepause macht ist > keine Option? Doch. Beispielsweise wurde die Firmware für Testzwecke so verändert, dass das Gerät nur bei aktivem Scrolllock sendet. Das wurde aber als "zu umständlich" oder "schwer vermittelbar" eingestuft. Daher geht es hier darum zu prüfen, ob ein Deaktivieren des Geräts möglich ist. Wenn das einfach ginge ("drei Zeilen Quelltext"), wäre es ein brauchbarer Ansatz.
Eddy Current schrieb: > Der Gag einer Tastaturemulation ist, dass bestehende Anwendungen ohne > Modifikation genutzt werden können. Und genau dies ist der Fall. Hier ja wohl nicht, wenn das Gerät andere Anwendungen stören kann und deswegen deaktiviert werden muss.
Rufus t. Firefly schrieb: > Hier ja wohl nicht, wenn das Gerät andere Anwendungen stören kann und > deswegen deaktiviert werden muss. Das Gerät soll seine Daten halt nicht in anderweitig verfasste Dokumente posaunen. Die Zielapplikation, die die Nutzdaten verarbeiten soll, kann aber ebenfalls ein nicht veränderbares Programm sein. Scancodefriemeln ist damit praktisch ausgeschlossen.
Da beißt sich die Ratte aber in den Schwanz; wenn die Zielapplikation nicht veränderlich ist, kann man ihr auch nicht beibringen, den Gerätetreiber zu aktivieren/deaktivieren. Ich halte das für einen Designfehler.
Ja, ich bin auch der Meinung, dass das hinten und vorne nicht zusammen paßt. Ich stelle mir momentan halt ein kleines Tool vor, mit dem man das Gerät stilllegen kann. Plan D ist dann ein Roboterarm, der den Stöpsel zieht...
Na wenn das ein Eigenbau ist, dann spendiere Deinem HID-Keyboard noch eine Steuerleitung - also eine weitere HID-Schnittstelle. Was Du brauchst sind zwei freie Endpunkte. Das Ganze ergibt dann ein USB-Verbundgerät (Composite). Deine Anwendung musst Du dann natürlich anpassen bzw. Du schreibst einfach ein kleines Programm mit ner GUI und einem Button für An/Aus oder irgendwas in der Art. Gruß Ralf
Ja, das wäre evtl. möglich. Es muss nur sichergestellt sein, dass ein Computer nicht am zweiten "Gerät" kollabiert. Wir hatten noch die Idee, per Feature-Request einen Report and das Gerät zu senden, aber wenn XP die Tastatur mal unter Beschlag hat, kriegt man kein Handle mehr auf dieses USB-Gerät. Wäre schön, wenn ich mich täuschen würde...
Ich entwickle grad eine Anwendung die auch Barcodescanner benutzt. Allerdings kein Eigenbau. Die werden defaultmäßig auch als Tastatur erkannt. Ist aber schlecht. Sobald der Benutzer irgendetwas einscannt, bekomme ich in meiner Anwendung den ganzen Mist rein. Allerdings lassen diese Barcodescanner sich umstellen und arbeiten dann als virtueller comport. Diesen öffne ich und verarbeite die Daten nur dann, wenn ich sie benötige. Vieleicht kannst du dein Gerät auch nur als ComPort bereitstellen und ein kleines Programm schickt mit sendKey die Daten an deine Anwendung, wenn du sie brauchst. kannst ja das aktive fensterhandle auslesen und wenn das richtige fenster aktiv ist, dann schickst du an dieses Fenster die eingelesenen Daten. mfg Thomas
Comport können unsere Geräte auch. In diesem Fall scheitert das an der
unzureichenden Flexibilität des Kunden ("mimimi, wir wollen aber nur
eine Konfiguration haben!" - und das ist die Keyboardgeschichte), der
Comport-Ansatz wäre aber eine brauchbare Lösung.
Problem gelöst: Ein kleines Tool sendet nun einen Feature Report an das USB Gerät, womit das Senden von Zeichen unterbunden werden kann.
Ein selbst Geschriebenes. Der Trick ist, dass man Feature Reports auch an vom Betriebssystem benutzte Geräte schicken kann, indem man bei CreateFile weder Lese- noch Schreibbedarf (!) anmeldet. Darauf muss man auch mal kommen, aber die Tiefen des Internet sind halt unerschöpflich. Zusätzlich mußte auch die Firmware verändert werden, bzw. der Feature Report im HID Descriptor "angemeldet" werden.
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.