KeyboardLED (Update: ohne DLL)

[MarcoWarm]

um nicht weiter den Thread von Daniel G zuzumüllen will ich die Unit mal hier "anpreisen".

KeyboardLED ermöglicht es die LEDs des Keyboards zum leuchten zu bringen (ach... wer hätte das gedacht :stupid:) und das ganz ohne das virtuelle "Drücken" von NumLock & Co.

Den Download gibts bei TUO.

@Airblader: jetzt gibts auch gleich ne eingebaute Funktion zum zurücksetzen der LEDs

[Treffnix]

:gruebel: "inpoutput.dll" oder so wir nicht gefunden

[Airblader]

@Vorposter

Aus einem der Demos musst du die Datei nach Windows\system32 kopieren ;)

@MarcoWarm
Super :)
Werd gleich mal schauen :mrgreen:

Edit:
Zurücksetzen funktioniert einwandfrei.
Hättet ihr aber dazusagen können, dass dieses kleine, unscheinbare 'T' dazugekommen ist :mrgreen:

[chaosben]

Oh mann ... was hab ich da für einen Kollegen .... so eine Nuss! :mrgreen:
Er wirds beheben ... er tippt .... und tippt ... und guckt mich böse an ... und tippt weiter ... ich glaub das wird dieses Jahr nichts mehr ;) ... und tippt ... und schimpft ....und nu ist die gefixte Version da!

[himitsu]

Hängt die DLL mal mit an den ersten Beitrag an,
oder macht 'ne Zip für die Demo (Demo-EXE + inpoutput.dll).

Und die DLL muß nicht unbedingt in das Systemverzeichnis. (ist bei einem Demoprogramm auch total bescheuert)
Es sollte auch reichen (wenn ihr ordentlich programmiert habt), wenn sich die DLL im selben Verzeichnis wie die EXE befindet.

[edit]
menno wieder zu langsam ._.

[JWeis]

cool das teil
nur beim beenden wirds ncht zurückgesetzt wen mans vergisst. ds ist n' bischen blöd aber macht nix!
trotzdem :thumb:

[Airblader]

@Jweis

Die Zurückstellung kann (!) ja auch nicht gewollt sein. Ein einfacher Funktionsaufruf im onDestroy tuts bei mir im Testprogramm ;)

air

[MarcoWarm]

Zitat:

Zitat von himitsu

Und die DLL muß nicht unbedingt in das Systemverzeichnis. (ist bei einem Demoprogramm auch total bescheuert)
Es sollte auch reichen (wenn ihr ordentlich programmiert habt), wenn sich die DLL im selben Verzeichnis wie die EXE befindet.

er bezog sich da nur auf das Readme in der Release-Zip. Da hab ich geschrieben, daß man die DLL z.B. ins System32 Verzeichnis kopieren kann (wohlgemerkt: kann). Dann muss man das Ding nicht bei jedem Projekt, daß man schreibt dazukopieren. Und natürlich geht es auch im Programmverzeichnis oder im Windows-Verzeichnis und was ihr noch so alles in %PATH% stehen habt ;)

@JWeis: Das ist nur ne Demo (quick and dirty) das ist auf keinen Fall dazu gedacht zu irgendwas "nützlichem" zu dienen, außer der Werbung ;)

Zitat:

Zitat von Airblader

Hättet ihr aber dazusagen können, dass dieses kleine, unscheinbare 'T' dazugekommen ist

das wäre zuuuuu peinlich gewesen *lach*

[Helmi]

hallo,

ich hab diese Exe mal gestartet und getestet, aber mehr als dass sich das Programm aufhängt passiert bei mir nicht!


Ach ja - ich hab ne USB-Tastatur

[Daniel G]

Dann poste ich meine Frage besser hier:

"Gibt es die vorkompillierte DCU auch für Delphi 5? Eine *.pas ist ja leider nicht dabei..."

[MarcoWarm]

Zitat:

Zitat von Helmi

Ach ja - ich hab ne USB-Tastatur

hmpf.... blöd. Keine Ahnung. Ich meine die Methode, zur LED-Ansteuerung basiert auf Interrupts. Und eigentlich ist sowas unter XP ja offiziell nicht gestattet. (deswegen der Umweg über inpout32.dll)
wahrscheinlich sollte man beim coden try except drumbasteln, um die USB Probleme abzufangen. Vielleicht find ich noch ne andere Lösung aber jetzt spiel ich erstmal n bissl mit meinem Sohn... guts nächtle

[chaosben]

Zitat:

Zitat von Daniel G

"Gibt es die vorkompillierte DCU auch für Delphi 5? Eine *.pas ist ja leider nicht dabei..."

Bis jetzt noch nicht ... aber ich werd morgen mal nachsehen ob ich ein D5 an Land ziehen kann.

Was die USB-Tastatur angeht hab ich das grad bei mir zu Hause ausprobiert mit einer USB-Tasta. die mit einem Adapter an PS2 steckt ... und da gehts ... wir werden morgen mal sehen ob es bei "echtem" USB-Anschluss ein Problem gibt.

[Aenogym]

funktioniert super :thumb:
gibt's die unit für delphi auch schon für die öffentlichkeit? würd da gern auch mal was mit machen :)

aenogym

[Airblader]

Hier übrigens mal ein "ausführlicheres" Testprogramm meinerseits ;)
Kann zwar "nur" 3 verschiedene Sachen, 2 davon aber noch nach Links o. Rechts,
Timer ist einstellbar und man kann es inaktiv schalten :)

*Download* (ZIP, 227KB gepackt)

air
P.S.: Die DLL habe ich sicherheitshalber mit reingelegt

[FriFra]

Es ist natürlich etwas "blöd", wenn man mit einem Programm an den LEDs herum manipuliert, dass sich die Tastatur dann auch entspr. anders verhällt. Will man z.B. die Netzwerklast über diese LEDs anzeigen lassen, dann sollte man nicht gerade etwas schreiben wollen :???: :lol:

[Airblader]

Die Veränderung der LEDs mit dieser Unit löst - zumindest bei mir - keine Änderung aus, da
ja nicht der Tastendruckt simuliert wird sondern die LED angesprochen wird ;)

air

[chaosben]

Zitat:

Zitat von FriFra

Es ist natürlich etwas "blöd", wenn man mit einem Programm an den LEDs herum manipuliert, dass sich die Tastatur dann auch entspr. anders verhällt. Will man z.B. die Netzwerklast über diese LEDs anzeigen lassen, dann sollte man nicht gerade etwas schreiben wollen :???: :lol:

Ich geh mal davon aus, das du nicht die ganze Diskussion mitbekommen hast. Ist ja auch nicht schlimm. :) Aber die hier angebotene Unit erlaubt das ändern der Leds ohne das virtuelle Aktivieren der zugehörigen Tasten.

//edit: ich schwöre das da kein roter Kasten war! :)

[FriFra]

Zitat:

Zitat von chaosben

Ich geh mal davon aus, das du nicht die ganze Diskussion mitbekommen hast. Ist ja auch nicht schlimm. :) Aber die hier angebotene Unit erlaubt das ändern der Leds ohne das virtuelle Aktivieren der zugehörigen Tasten.

//edit: ich schwöre das da kein roter Kasten war! :)

Ich hab die Diskussion mitbekommen. Die Aussage stimmt aber nicht! Ich sitze hier an einem Vaio und da bemerkt man es sofort, wenn Num-Lock aktiv ist :???: ... dann ist ein vernünftiges Schreiben eben nicht mehr möglich! Caps-Lock hat tatsächlich keine Auswirkung, aber Num-Lock schon... Probier es doch mal selbst... Klar merkt man das bei einer Tastatur mit separatum Num-Block nicht so ohne weiteres, aber ich gehe davon aus, dass es da nicht anders ist :gruebel:

[Airblader]

Selbst wenn NUM bei mir nicht aktiv ist kann ich mit dem NUM-Block noch vervorragend schreiben ;)

air

[100nF]

hi,

ich habe das programm auch mal an meinem laptop getestet, funktioniert wunderbar.
ich denke dass es noch gut ist wenn man weiss dass es auch an laptops funktioniert, drum schreib ich jetzt mal...

ach ja, es funktionieren beide, das von MarcoWarm und das von Airblader.
@Airblader
mein laptop wurde schon zur tragbaren Disco :mrgreen:

gruss
urbanbruhin

[Aenogym]

danke, unbekannte :D
:coder:

aenogym

[FriFra]

Also ich sitze hier an einem Vaio und da funktioniert es definitiv NICHT, da bei aktivem Num-Lock "uiopjklöm." = "456*123-0," ergibt... Ihr könnt es glauben oder nicht, es IST so :?

Das schrebe ch etzt mt atvem KeyED
Es werden defnitv Zechen versccth

[Airblader]

An meinem KeyLED kanns jedenfalls nicht liegen, da

1.) Es ja schließlich nur die Unit verwendet ;)
2.) Sonst ja funktioniert *fg*

Auch mal was mit aktivem KeyLED und Intervall 10ms:

Dies ist ein Testtext und wie man sieht passiert rein garnichts seltsames oder ungewöhnliches :)
Und noch was mit NumPad:
56+57*28+45
Ist auch ganz normal ;)

air
Edit:
Wenn KeyLED übrigens ein paar Leuten gefällt mach ich mich gerne auch an zusätzliche Muster und um es in den Tray zu minimieren etc... ;)
Momentan ist es aber Spielerei, weil mir partout kein sinnvoller verwendungszweck dafür einfällt *fg*

[FriFra]

Zitat:

Zitat von Airblader

An meinem KeyLED kanns jedenfalls nicht liegen, da

1.) Es ja schließlich nur die Unit verwendet ;)
2.) Sonst ja funktioniert *fg*

Und woran soll es sonst liegen, dass wenn Dein Programm läuft meine Tastatur spinnt? Komisch, komisch... sobald ich die Blinkerei abstelle funktionieren genau die Tasten, welche bei Num-Lock die Funktion wechseln wieder normal :gruebel: :wall:

[Airblader]

Ich meine damit dass der Fehler in der Unit liegt und nicht im Quelltext von mir :)

air

[chaosben]

Zitat:

Zitat von FriFra

Das schrebe ch etzt mt atvem KeyED
Es werden defnitv Zechen versccth

Ok FriFra ... du hast es so gewollt. Jetzt bist du das Versuchskaninchen. ;)
Mal eine Frage: warum steht da ein "i" im "defnitv" wenn es (das "i") anscheinend nicht gehen sollte?
Und nochwas: Probier mal bitte die Demo vom MarcoWarm. Ich will Airblader nichts unterstellen aber ... man weiß ja nie. :)

//edit:
Ok, Nachtrag: Das Verschwinden von Zeichen konnte ich jetzt mit dem Prog von Airblader und einem Intervall von etwa 10ms nachempfinden. Das ist aber in der Natur der Sache begründet, die Marco noch ein wenig erläutern will.

[FriFra]

Zitat:

Zitat von chaosben

Mal eine Frage: warum steht da ein "i" im "defnitv" wenn es (das "i") anscheinend nicht gehen sollte?
Und nochwas: Probier mal bitte die Demo vom MarcoWarm. Ich will Airblader nichts unterstellen aber ... man weiß ja nie. :)

Das "i" hatte wohl "Glück", dass es durchgekommen ist. Es war dieses Lauflicht aktiv, da gibt es schonmal den einen oder anderen Moment, wo das "i" auch mal geht ;)
Auch mit der anderen Demo tritt dieser Effekt ein...

[MarcoWarm]

Ihr habt es ja nich anders gewollt ;)
Jetzt müsst ihr nen technischen Vortrag ertragen (nich erschrecken vor dem bissl asm)

Wat macht eijentlich SetKeyboardLED?
Da stell'n mer uns ma janz dumm und sagen....

nen LED Status kann man beim Keyboard setzen, indem man einen zwei Byte-Code-Kommando an den Tastaturport sendet. (Bitte merken darauf komm ich nochmal zurück)

Also was passiert nu?

1. ne Schleife wartet, bis der Tastaturpuffer leer ist.

Code:

in     al,64h          ;
and    al,00000010b    ; den Keyboard inputbuffer prüfen
jz     makeLED         ; wenn der Leer ist ... loslegen

2. jetzt schicken wir ganz schnell ein $ED an $60

Code:

mov    al,0edh         ; Keyboard LED output Kommando $ED
out    60h,al          ; an die Adresse $60 schreiben

3. Prüfen, ob der Befehl von der Tastatur angenommen wurde

4. jetzt machen wir alle 3 LEDs an

Code:

mov    al,00000111b    ; Keyboard LED output Kommando 111
out    60h,al          ; an die Adresse $60 schreiben

ok, ok, ok... zwischendrin fehlen n paar Befehle aber das soll ja jetzt auch bloß als Anschauungsmaterial dienen.
Dem aufmerksamen Leser ist sicher aufgefallen, daß hier das Risiko besteht, daß zwischen dem Senden von $ED und 00000111 die Tastatur (also der Mensch durch drücken einer Taste) eine "Taste" in den Buffer schreibt, die dann als LED Kommando gewertet würde. Unter DOS und Win9x kann man das unterbinden indem man den Interrupt exklusiv für sich reserviert (asm -> cli) und nachher die Interruptkontrolle wieder freigibt (asm -> sti). Aber leider macht uns XP da nen Strich durch die Rechnung, da sowas nur möglich ist, wenn die Anwendung im Kernelmodus läuft.

Bitte Beachten

• Das Risiko kann dadurch minimiert werden, daß Intervall zum setzen der LEDs zu verlängern (daß die Tastatur auch mal ne Chance bekommt)
• ältere XT-Controller unterstützen dieses Vorgehen nicht
• sehr neue Controller können auch spinnen
• das Readme der Unit enthält ne Disclaimer-Section!!!

zur Beruhigung aller... chaosben ist immer noch dabei das irgendwie anders zu lösen (good luck man :thumb:)

[Aenogym]

auf jeden fall sehr nett das ganze.
ich sitz grade an nem programm, dass dieses geblinke auch halbwegs sinnvoll einsetzen kann (nein, kein traffic-monitor^^)

wenns fertig ist, stell ich's natürlich in die freeware-sparte. dauert aber nochn wenig, da ich nebenbei auch noch viele andere dinge zu tun habe ;)

aenogym

[chaosben]

Bin schon gespannt.

Zitat:

Zitat von Aenogym

wenns fertig ist, stell ich's natürlich in die freeware-sparte. dauert aber nochn wenig, da ich nebenbei auch noch viele andere dinge zu tun habe ;)

Es geht den Menschen wie den Leuten. :)

[Daniel G]

Wann bekomme ich denn meine D5-DCU ? :duck: :duck:

[chaosben]

Ach Daniel ... du machst mir Sorgen ... :)
Ich konnte bisher kein D5 an Land ziehen und wir wollten es eigentlich als ClosedSource behandeln. Ich hab grad den Marco gefragt und wir sind uns einig geworden, das du den Source unter der Bedingung bekommst, das er weiter "cliosed" bleibt. Wenn du einverstanden bist, kannt du ihn Montag haben. Dann kommen wir wieder ran.

[Daniel G]

Zitat:

Zitat von chaosben

Ach Daniel ... du machst mir Sorgen ... :)

Komisch... Das sagt mein Tutor auch immer. :stupid:

Zitat:

Zitat von chaosben

Ich konnte bisher kein D5 an Land ziehen und wir wollten es eigentlich als ClosedSource behandeln. Ich hab grad den Marco gefragt und wir sind uns einig geworden, das du den Source unter der Bedingung bekommst, das er weiter "cliosed" bleibt. Wenn du einverstanden bist, kannt du ihn Montag haben. Dann kommen wir wieder ran.

=> Siehe PN

[MarcoWarm]

Danke an Daniel G....

jetzt gibts KeyboardLED auch als Delphi 5 Unit unter oben genanntem Link

[negaH]

Zitat:

zwei Byte-Code-Kommando an den Tastaturinterrupt sendet

Diese Aussage ist falsch. Man sendet über den Tastatur-PORT direkt die Daten an den Keyboard Controller. Mit Interrupts hat dies reingarnichts zu tuen.

Man sollte auch vorher den aktuellen Status der LEDs abfragen und diesen zwischenspeichern. In meiner Direkt-Port-Access Unit sieht dies so aus:

Delphi-Quellcode:

procedure TPort.SetKeyboardLED(LED: Byte; State: TLEDState);

  function LEDState: System.Byte;
  begin
    Result := 0;
    if GetCurrentThreadID <> MainThreadID then
      AttachThreadInput(GetCurrentThreadID, MainThreadID, True);
    if GetKeyState(vk_Scroll) and 1 <> 0 then Result := Result or klScroll;
    if GetKeyState(vk_NumLock) and 1 <> 0 then Result := Result or klNum;
    if GetKeyState(vk_Capital) and 1 <> 0 then Result := Result or klCaps;
    if GetCurrentThreadID <> MainThreadID then
      AttachThreadInput(GetCurrentThreadID, MainThreadID, False);
  end;

begin
  if FKbdLED and $80 = 0 then FKbdLED := FKbdLED or $80 or LEDState;
  case State of
    lsReset : FKbdLED := FKbdLED and not LED or LEDState;
    lsOn    : FKbdLED := FKbdLED or LED;
    lsOff   : FKbdLED := FKbdLED and not LED;
  end;
  if FKBdLEDTime <> 0 then
    while FKbdLEDTime >= GetTickCount do ;
  PortB[$60] := $ED;
  FKbdLEDTime := HDDelay;
  while FKbdLEDTime > 0 do Dec(FKbdLEDTime);
  PortB[$60] := FKbdLED and klAll;
  FKbdLEDTime := GetTickCount + 1;
end;

Man könnte so auch die Laufwerks LEDs leuchten lassen

Delphi-Quellcode:

procedure TPort.SetDriveLED(Drive: Byte; State: TLEDState);
begin
  Drive := Drive and 3;
  if State = lsOn then Drive := Drive or (not Drive shl 4);
  PortB[$03F2] := Drive;
end;

Beachten sollte man aber das man auf einem Protected Mode OS normalerweise keinen Zugriff auf die Ports hat, nur Kernelmode Treiber sollten dies können. Um nun denoch aus Ring 3 heraus Zugriff auf die Ports zu bekommen wird dieser Schutz deaktiviert und meistens alle Ports für alle Anwendungen freigegeben, zb. mit GiveIO.sys oä.
Dies hat aber nun zur Folge das dies 1. nur unter WinNT/Win2k etc funktioniert und 2. das eine Anwendung die auf Grund irgendwelcher Fehler in den Port Bereich irgendwelche Daten schreibt dafür sorgt das Hardware oder Daten zerstört werden können.

Ich würde sowas nicht benutzen wollen.

Gruß Hagen

[runger]

Hallo,

Zitat:

PortB[$03F2] := Drive;

funktioniert unter Win2k und WinXP sowieso nicht.

Zugriffe auf Ports für dort zu einer Exception.


(Sorry aber ich hatte den Beitrag von negaH nicht gelesen)
Rainer

[MarcoWarm]

Zitat:

Zitat von negaH

Mit Interrupts hat dies reingarnichts zu tuen.

Ok... mein Satz war ein wenig unglücklich formuliert (ist korrigiert worden) danke.
Aber daß das mit Interrupts nix zu tun hat, ist nicht ganz korrekt... Es ist nur dumm, daß man unter XP die Interrupts nicht sperren darf (cli etc.)

Zitat:

Zitat von negaH

Man sollte auch vorher den aktuellen Status der LEDs abfragen und diesen zwischenspeichern

du prüfst nicht den aktuellen LED-Status, sondern welche Tasten gedrückt wurden. Das ist ein großer Unterschied. Das sagt nämlich nur aus, welche LEDs leuchten sollten!!! (Übrigens machen wir das auch)

Zitat:

Zitat von negaH

Delphi-Quellcode:

....
  if FKBdLEDTime <> 0 then
    while FKbdLEDTime >= GetTickCount do ;
  PortB[$60] := $ED;
  FKbdLEDTime := HDDelay;
  while FKbdLEDTime > 0 do Dec(FKbdLEDTime);
  PortB[$60] := FKbdLED and klAll;
  FKbdLEDTime := GetTickCount + 1;
...

wie ich sehe, führst du keinerlei Prüfungen durch, ob der Port die Daten akzeptiert hat.... Das sollte man schon tun. Dann schließt man auch aus, daß man die Daten ausversehen an einen falschen Port schreibt. Der Keyboardcontroller gibt nämlich ein acknowledged Signal für die gesendeten Daten zurück (bitte vor dem schimpfen die Theorie büffeln)

Zitat:

Zitat von negaH

as eine Anwendung die auf Grund irgendwelcher Fehler in den Port Bereich irgendwelche Daten schreibt dafür sorgt das Hardware oder Daten zerstört werden können.

Daher der Disclaimer

Zitat:

Zitat von negaH

Ich würde sowas nicht benutzen wollen.

Das musst du ja zum Glück auch nicht

[negaH]

Delphi-Quellcode:

PortB[$03F2] := Drive;

Doch funktioniert unter Win95 bis WinXP. Aber nur weil dieses PortB[], PortW[], PortL[] meine Entwicklungen sind. Ich bezog mich also nicht auf das alte PASCAL Port[] sondern auf meine direkt Port Access Unit.

Zitat:

Aber daß das mit Interrupts nix zu tun hat, ist nicht ganz korrekt... Es ist nur dumm, daß man unter XP die Interrupts nicht sperren darf (cli etc.)

Doch man darf aber eben nur in einem Kernelmode Treiber, bzw. nur mit den entsprechenden Privilegien. Diese könnte man auch für eine Ring 3 Application einrichten.

Der Zugriff auf den Keyboard Port hat insofern mit Interrupts nur damit zu tun das man diese eventuell mit CLI/STI sperren sollte, mehr aber auch nicht.

Zitat:

wie ich sehe, führst du keinerlei Prüfungen durch, ob der Port die Daten akzeptiert hat.... Das sollte man schon tun. Dann schließt man auch aus, daß man die Daten ausversehen an einen falschen Port schreibt.

Besser wäre es schon, aber soviel wie ich weis gibt es keinen PC der keinen 8253 kompatibeln PIO hat. Ergo kann man sich 99.9% sicher sein das $60 einer der Keyboardports ist. Aus Sicht des Timings wäre das Abfragen des Acknowledges aber schon richtiger. In meinem Code benutze ich halt eine Waitloop.

Mal ne andere Frage: Funktioniert dein Code auch unter Win95 uä. ?

Gruß Hagen

[MarcoWarm]

Zitat:

Zitat von negaH

Doch man darf aber eben nur in einem Kernelmode Treiber, bzw. nur mit den entsprechenden Privilegien. Diese könnte man auch für eine Ring 3 Application einrichten.

es ging ja auch um eine Unit, die jeder einsetzen kann... und nich jeder kann und will o.g. Sache tun.

Zitat:

Zitat von negaH

Der Zugriff auf den Keyboard Port hat insofern mit Interrupts nur damit zu tun das man diese eventuell mit CLI/STI sperren sollte, mehr aber auch nicht.

also doch... ok ... ich werd nich mehr drauf rum reiten

Zitat:

Zitat von negaH

Ergo kann man sich 99.9% sicher sein das $60 einer der Keyboardports ist.

die Erfahrung hat gezeigt, daß einige Controller sich doch ein wenig affig haben (vor allem bei einigen Notebooks, USB und älteren XT Controllern)

Zitat:

Zitat von negaH

Mal ne andere Frage: Funktioniert dein Code auch unter Win95 uä. ?

zumindest unter Win98 ja... Kühne Behauptung: also auch unter Win95

[negaH]

Zitat:

Zitat von MarcoWarm

zumindest unter Win98 ja... Kühne Behauptung: also auch unter Win95

welchen Trick setzt du ein ? CallGate oder VXD Treiber ?

Gruß Hagen