[w32api] Verzenden toetsaanslag naar toetsenbord

[MisterE]

Allereerst het probleem. Ik heb nu een KVM switch die ik schakel via SCROLLLOCK => SCROLLLOCK => %pcnumber%

Ik wou proberen te schakelen via software.

De vraag is of dit mogelijk is. Het kastje vangt natuurlijk rechtstreeks de toetsen af.
Ik vond het volgende op het internet:
Simulating keystrokes from code - http://delphi.about.com/od/adptips2004/a/bltip0604_4.htm
Dit werkt, maar die commando's zend ie natuurlijk naar windows.

Nou moeten volgens mij ook commando's naar het toetsenbord zelf te sturen zijn. Ik weet namelijk dat er plugins zijn voor winamp waarbij je leds (scrolllock, capslock) als vu-meter gebruikt worden. Dit lijkt me dus dat het OS die verzend naar het toetsenbord.

Kan iemand me vertellen of dat klopt, hoe ik zo'n commando kan verzenden.
De vraag is daarna weer of de KVM swich het ook ziet dan....

[Kuhlie]

Voor mijn gevoel kan dit niet. Het scroll-lock-lampje staat volledig los van de scroll-lock-knop ('bewijs': als je windows goed hangt werkt je scroll-lock aan/uit zetten ook niet meer ;-) ). Verder lijkt me 'toetsen verzenden' gewoon 1-richtingsverkeer. Helaas dus, waarschijnlijk.

Overigens: PS/2 gok ik? Je vermeldt dit niet.

[ Voor 23% gewijzigd door Kuhlie op 15-04-2006 02:42 ]

[MisterE]

Kuhlie schreef op zaterdag 15 april 2006 @ 02:41:
Voor mijn gevoel kan dit niet. Het scroll-lock-lampje staat volledig los van de scroll-lock-knop ('bewijs': als je windows goed hangt werkt je scroll-lock aan/uit zetten ook niet meer ;-) ). Verder lijkt me 'toetsen verzenden' gewoon 1-richtingsverkeer. Helaas dus, waarschijnlijk.

Overigens: PS/2 gok ik? Je vermeldt dit niet.

Jup, een ps/2 versie.
Maar hoe verklaar je "1 richtingsverkeer" als zo'n plugin de lampjes van je toetsenbord aanzetten? Ergens heb ik de stille hoop dat het toch kan

[Gonadan]

Volgens mij zijn de toetsen inderdaadn 1-richtings-verkeer maar de ledjes ook.
Die doen niet meer dan de status van die 'eigenschap' in je computer aangeven.
Neem bijvoorbeeld de num-lock je kan in de bios aangeven of die moet branden of niet.

Maar dit eenrichtingsverkeer heeft natuurlijk geen kont te maken met wat jij wilt.
Ik weet alleen niet of het mogelijk is om een PS/2 poort aan te sturen.

[MisterE]

heb ondertussen een componentje gevonden voor delphi:
http://www.winsoft.sk/download/keyled.zip

Ik ga weer ff verder spelen

Dat componentn lijkt me toch code die niet in je keyboard terecht komt.
Als ik op: http://www.shellcode.com....oA/Chapter_20/CH20-2.html kijk dan hebben ze het over poort 60 en 64

[ Voor 43% gewijzigd door MisterE op 15-04-2006 10:22 ]

[Verwijderd]

Het toetsenbord is geen eenrichtingsverkeer, er zit gewoon een controller in die te programmeren is. Onder DOS kon je de LEDjes eenvoudig aan- en uitzetten door rechtsreeks naar de hardware poorten te schrijven (in en out opcodes). Helaas heb je onder Windows geen directe toegang tot de hardware en zul je het op een andere manier moeten doen (een driver schrijven of op andere wijze het OS dit laten uitvoeren).

[Verwijderd]

De keyboard controller is erg beperkt en er valt weinig aan te programmeren.

Verkeer van toetsenbord -> PC:
- make/release van toetsen
- diagnostisch verkeer

Verkeer PC -> toetsenbord
- instellen herhalingssnelheid / -vertraging
- instellen LEDjes
- diagnostisch verkeer (b.v. keyboard reset).

De controller forceren zodat er op commando een scancode (b.v. scroll-lock dus) teruggestuurd wordt lijkt me erg sterk.
(lees: die functionaliteit zit gewoon niet in de controller. Als je er het fijne van wil weten, moet je even Ralph Brown's interrupt list deel D doornemen bij IO poorten 0x60-0x64)

[eamelink]

Ik denk dat je meer kans maakt met één of ander tussenstukje dat je tussen je toetsenbord en je KVM switch hangt, en dat je op een seriële of USB poort aansluit, dat toetsaanslagen kan simuleren en verzenden over de lijn

[farlane]

Je kunt in windows een global keyboard hook maken, misschien kun je daar wat mee? Je moet wel een of andere manier hebben om die kvm switch aan te spreken.

[ Voor 32% gewijzigd door farlane op 18-04-2006 08:44 ]

[Icelus]

Met de SendInput functie zou dit moeten kunnen

[Tomatoman]

De centrale vraag is of je vanuit de pc een toetsaanslag kunt sturen naar het toetsenbord, net zoals je vanuit de pc het lampje bij de NumLock toets kunt laten branden. Het antwoord kun je zien in het plaatje hieronder.



Zoals je ziet stuurt het toetsenbord scan codes van de ingedrukte toetsen naar de keyboard driver. Windowsfuncties zoals keybd_event, GetAsyncKeyState en SetKeyboardState communiceren nooit direct met het toetsenbord, maar communiceren met de keyboard driver. En de keyboard driver kent alleen eenrichtingsverkeer van keyboard naar software.

Nu is er een uitzondering, namelijk die paar toetsen met een lampje erboven (Num lock, Caps lock, Scroll lock). Volgens de documentatie van Windows kun je die lampjes laten branden met bijvoorbeeld de keybd_event functie. Er is dus toch tweerichtingsverkeer mogelijk, zij het slechts voor de lampjes bij deze drie toetsen. De keyboard driver onthoudt simpelweg de toestand van de betreffende toets. Num lock aan betekent niets meer dan dat de keyboard driver heeft onthouden dat die toets 'aan' is en dat de keyboard driver het overeenkomstige lampje heeft aangezet. Drukt de gebruiker daarna op Num lock, dan onthoudt de keyboard driver dat Num lock 'uit' is en geeft het toetsenbord het commando om het lampje uit te doen.

Dat dit ook daadwerkelijk zo zit, weet ik uit de praktijk. Op mijn werk hang ik altijd een extern toetsenbord aan mijn laptop. Zodra Windows opstart gaat het Scroll lock lampje branden. Mijn laptop reageert echter alsof Scroll lock uit is. Als ik Scroll lock eenmaal indruk, blijft het lampje branden en reageert Windows daadwerkelijk alsof Scroll lock aan is. Nogmaals drukken op Scroll lock werkt zoals verwacht: lampje uit, Windows reageert alsof Scroll lock uit is. Blijkbaar zit er een bugje in de keyboard driver voor dat specifieke toetsenbord, waardoor direct als Windows start het lampje en de toets niet in overeenstemming zijn met elkaar (toets 'uit', lampje aan). Zodra ik op het toetsenbord op Scroll lock druk, gaat in de keyboard driver het vlaggetje voor Scroll lock 'aan' omhoog en doet de driver het Scroll lock lampje aan. Het lampje wordt dus door de keyboard driver gestuurd, niet door de toets.

Wat is nu de conclusie voor de topicstarter? De KVM-switch hangt tussen het toetsenbord en de keyboard driver. Er is dan ook alleen verkeer van toetsaanslagen van het toetsenbord naar de keyboard driver en van het aan- en uitzetten van lampjes de andere kant op. Het is dus NIET mogelijk om het toetsenbord een commando te sturen dat hij een bepaalde toetsaanslag (via de KVM-switch) naar de keyboard driver moet sturen. Aansturen van de KVM-switch door een toetsaanslag te simuleren is dus fysiek onmogelijk. En dat is ongeacht het besturingssysteem, want het is een hardwarematige beperking van toetsenboarden. Vanuit de keyboard driver een toetsaanslag richting het toetsenboard sturen is ook niet mogelijk. En als het wel mogelijk zou zijn, zou de KVM-switch er waarschijnlijk niet eens op reageren, want hij verwacht alleen signalen vanaf het toetsenbord, niet vanaf de andere kant. Sorry, het is niet anders

[ Voor 6% gewijzigd door Tomatoman op 18-04-2006 15:07 ]

[farlane]

Ben het niet helemaal met je eens.

Het protocol dat een keyboard gebruikt is compleet bidirectioneel, daar is niets aparts aan; een keyboard kent (veel?) meer dan alleen de set led commando's.

Het zou kunnen dat de kvm switch ook op de andere poort luistert, het is immers een simpele wisselschakelaar en hoeft in principe geen verschil te maken tussen wat hij hoort op de in of uitgang van zijn keyboard poort. ( Je aanname klinkt echter geloofwaardig )

Daarnaast moet je keyboard driver het versturen van commando's wel ondersteunen, de vraag is echter of het gedocumenteerd is, en of je zomaar zelf willekeurige commando's mag versturen.

Als het al kan wordt het wel hackwerk Zou wel leuk zijn om zelf een kastje te bouwen die je commando's kunt geven die ze weer doorgeeft aan je kvm switch

Zie ook
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-12.html
http://www.beyondlogic.org/keyboard/keybrd.htm

[Tomatoman]

farlane schreef op woensdag 19 april 2006 @ 12:57:
Ben het niet helemaal met je eens.

Het protocol dat een keyboard gebruikt is compleet bidirectioneel, daar is niets aparts aan; een keyboard kent (veel?) meer dan alleen de set led commando's.

Het zou kunnen dat de kvm switch ook op de andere poort luistert, het is immers een simpele wisselschakelaar en hoeft in principe geen verschil te maken tussen wat hij hoort op de in of uitgang van zijn keyboard poort. ( Je aanname klinkt echter geloofwaardig )

Je verwijst naar een interessante webpagina, die kende ik niet. Er staan inderdaad meer commando's om vanaf de controller naar het toetsenbord te sturen, maar ik zie daar nergens bij staan dat het is toegestaan om commando's die toetsaanslagen representeren naar het toetsenbord te sturen. Waarschijnlijk worden dergelijke commando's door de meeste toetsenborden gewoon genegeerd (en doen ze ook geen kwaad). Dat zou betekenen dat het een kwestie van proberen is; misschien reageert de KVM-switch daadwerkelijk.

Daarnaast moet je keyboard driver het versturen van commando's wel ondersteunen, de vraag is echter of het gedocumenteerd is, en of je zomaar zelf willekeurige commando's mag versturen.

De enige manier die ik kan verzinnen om hier achter te komen is SendInput uitproberen met de toetsencombinatie om van pc te wisselen en dan kijken of de KVM-switch reageert. Het wordt dan echter wel een driverspecifieke oplossing, want het zou kunnen dat de ene driver output naar het toetsenbord valideert op geldigheid en de andere niet.

[farlane]

[aannames]
Die SendInput ziet eruit alsof hij tussen de 'input kant' en 'output kant' van de keyboard driver ingrijpt, dus nadat de driver eventuele keyboard frames heeft gedecodeerd en in zijn/een queue gezet heeft die vervolgens wordt gebruikt om verdere akties op te ondernemen:

dus zoiets:
numlock knop scancode --> keyb driver --> queue --> .... --> numlock status led commando

Mij lijkt het aannemelijker dat je een DeviceIoControl call zoekt die de keyboard driver een commando laat versturen naar het keyboard. ( Of een GiveIo achtige constructie die je zelf bouwt )

[/aannames]

Ff lopen zoeken maar je komt al snel in driver development dingen terecht die je moet doorploeteren. Hoop dat de ts tijd over heeft

[ Voor 14% gewijzigd door farlane op 19-04-2006 14:30 ]

[Tomatoman]

farlane schreef op woensdag 19 april 2006 @ 14:24:
[aannames]

Helemaal mee eens

[Hackykid]

Even voor al die mensen die beweren dat het niet mogenlijk is om toetsaanslagen te emuleren, het is mij toch zeker ooit gelukt.

Is al wel een tijdje geleden, maarja. Het werkte toen wel.
Was nog in een dos-omgeving dus ik denk niet dat daar een driver tussenzat, maar dat het gewoon gebruik maken was van de functies van de keyboard controller.

In ieder geval, ik had dus een dos TSR die toetsen kon "faken", en wel zo goed dat het windows 98 voor de gek hield. (TSR werdt geladen voordat windows 98 werdt opgestart)

Deze techniek zal nu echter niet meer werken, aangezien windows tegenwoordig niet meer dos-based is. Maar het is zeker niet "bij voorbaat onmogenlijk" zoals sommige mensen hier beweren, als je OS er de goede functies voor zou hebben of als je op een of andere manier direct bij de keyboard controller zou kunnen, zou het mogenlijk zijn.

Als er iemand interesse zou hebben kan ik het stukje (assembly) code wat het faken van de toetsen deed nog kunnen terugzoeken.

[farlane]

Je begrijpt het verkeerd denk ik. Er moeten geen toetsaanslagen geemuleerd worden voor het OS, maar voor de KVM switch.

[Hackykid]

hmm, mijn punt over windows was eigenlijk dat mijn methode toen vanuit een dos tsr (die niks weet of kan weten van windows of windows drivers ed) toch windows voor de gek kon houden. Dus dat die methode zich in ieder geval op een lager niveau bevindt als windows.

Aan de andere kant heb je toch wel en beetje gelijk en heb ik misschien iets te snel gereageerd.

Hmm, ik zal een testen of mijn methode ook werkt als er geen toetsenbord is aangesloten, indien dat zo is zal het dan dus niet werken om hiermee zo'n KVM switch voor te gek te houden, of snap ik het nog steeds niet?

edit: net getest, en het werkt dus ook als het toetsenbord niet is aangesloten, dus er gaat niks naar/van het toetsenbord, niet geschikt om een KVM switch voor de gek te houden denk ik dan.

edit: voor de volledigheid, net even opgezocht, en dit is de functie die mijn methode gebruikte:

Command 0xd2: Write keyboard output buffer

(MCA) Write the keyboard controllers output buffer with the byte next written to port 0x60, and act as if this was keyboard data. (In particular, raise IRQ1 when bit 0 of the Command byte says so.)

(van http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-8.html)
maar dit gebeurt dus op het niveau van de keyboard controller, en niet het keyboard zelf

[ Voor 41% gewijzigd door Hackykid op 19-04-2006 18:46 ]