HID-Tastatur programmgesteuert deaktivieren

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.

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.

Genau, aber ich kriege

Beitrag "Re: HID-Tastatur programmgesteuert deaktivieren"

nicht gelöst ;-)

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...

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.