KeyboardLED (Update: ohne DLL)

[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