www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/02/26/22:33:39

Xref: news2.mv.net comp.os.msdos.djgpp:1463
From: jtsilla AT ccs DOT neu DOT edu (James Tsillas)
Newsgroups: comp.os.msdos.djgpp
Subject: Please help me chain keyboard ISR
Date: 26 Feb 1996 03:26:33 GMT
Organization: Northeastern University
Lines: 94
Distribution: world
Message-ID: <JTSILLA.96Feb25222633@atlas.ccs.neu.edu>
NNTP-Posting-Host: atlas.ccs.neu.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Well, my girlfriend is about to kill me because I've spent most of this
Sunday trying to get this to work.

I'm trying to build a driver where I can snoop keyboard interrupts for
the scancode to service a program running in protected mode.

So far, the closest I've gotten is to install my handler like so:

   lockisrmem();

   _go32_dpmi_get_protected_mode_interrupt_vector(KEYDRV_INT, &pm_oldint);

   pm_int.pm_offset = (int)keyint;
   pm_int.pm_selector = _my_cs();

   if (_go32_dpmi_chain_protected_mode_interrupt_vector(KEYDRV_INT, &pm_int)) {
      printf("error: Keyboard: Install: chain pmode interrupt vector..\n");
      exit(1);
   }  

where lockisrmem() is:

   _go32_dpmi_lock_code((void(*)())keyint,
			(unsigned long)lockisrmem - (unsigned long)keyint);

The procedure keyint() is now getting called with each key press and
release. I've checked this using counters and it seems to work (ISRs are
sure tough to debug, especially when they involve the keyboard).

Question: is this the best way to do this? I guess I don't really
understand how interrupts are reflected in protected mode. Are the real
mode handlers bypassed? It seems that the chain is working since the
keyboard still functions with normal system calls.

The next step is to try and actually scan the code but not confuse the
harware which must still be accessed by the normal keyboard ISR. It
would be nice if the OS provided a callback mechanism in the keyboard
driver to help me in this but here's what I got so far:

   // Read the raw scan code
   k_temp = inportb(KEYDRV_BUFFER);

#if 0
   // Reset the control port
   k_ctl = inportb(KEYDRV_CONTROL) | 0x82;
   outportb(KEYDRV_CONTROL, k_ctl);
   k_ctl &= 0x7f;
   outportb(KEYDRV_CONTROL, k_ctl);

   // Reenable interrupts
   outportb(KEYDRV_PIC, 0x20);
#endif

This is traight out of LaMothe's Black Art of 3D Game Programming. I've
translated it to C. Now, I figure that the parts I've ifdef'ed out would
need to be left to the real driver. But sadly this still doesn't work. I
never get the right scan code in k_temp. It always gives 0. Ofcourse I
can't really tell this is true since I can't set a breakpoint in there,
but I scan the variable in a loop and even though I am tripping through
the handler, k_temp never get's scanned in.

What am I doing wrong?

BTW, someone suggested I also need to set the real-mode ISR as well. Is
this really true? It seems that the real-mode ISR should never get
called here, no? I tried setting this and managed to always lock my PC,
even while in the debugger (which wasn't so fun).

In his book, LaMothe implies that this is possible (pg 229) but never
demonstrates a working example. And in any case he is running under
straight DOS in real-mode (Andre, when are you gonna move up to DJGPP,
dude?)

Please help me with any suggestions you may have.

-Jim.






--
  
 ____***___
 \..*...*./
  \.*..../
   \*...*  * Jim Tsillas - Senior Software Engineer     *
    \**/   * Cascade Communications Corp.               *
     \/    * 5 Carlisle Road, Westford MA 01886         *
   CASCADE
	

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019