OSDev.org

bewing wrote:Um. You don't send click or position things anywhere.

You receive the mouse packets, and the mouse tells you what clicks or movement happened in the bits in the packets. Then you store this information for your GUI to use.
Please see the Mouse Input article on the wiki for packet information.

I "sent keys to the keyboard"...

JamesM wrote:Hi,

I "sent keys to the keyboard"...

Your statement actually defies the logic in the keyboard controller. It recieves commands, and sends data. Not the other way around.

private void sendKey(short keyPressCode)
        {
            short keyReleaseCode =(short)(0x80 + keyPressCode);
            short status;

            //Wait Input Buffer empty 
            do { status = inp(0x64); } while ((status & 2) != 0);
            outp(0x60, 0xF4); //Enable keyboard

            // Wait until i8042 can receive the command.
            do { status = inp(0x64); } while ((status & 2) != 0);
            outp(0x64, 0xD2); // Send write request
            // Wait until i8042 can receive data.
            do { status = inp(0x64); } while ((status & 2) != 0);
            outp(0x60, keyPressCode); // Write keypress code
            
            // Wait until i8042 has received the keypress code
            do { status = inp(0x64); } while ((status & 2) != 0);
            outp(0x64, 0xD2);// Send write request
            // Wait until i8042 can receive data.
            do { status = inp(0x64); } while ((status & 2) != 0);
            outp(0x60, keyReleaseCode); //write keyrelease code
            // Wait until i8042 has received the keyrelease code
            do { status = inp(0x64); } while ((status & 2) != 0);
         }

Combuster wrote:I've looked up the commands in the documentation, and you are *not* sending anything to the keyboard, nor the mouse. You just tell the PS2 controller to append bytes at the end of the buffer for one specific device.

Also note that doing it this way is prone to race conditions - for keyboards you can get stuck keys, and you can completely mess up packet alignment for mice.

Edit: I don't like the fact that you asked the same question in two threads. In fact, you hijacked one.

Port 64 - Keyboard / Mouse Command..........................WO
This port is used to send commands to the keyboard / mouse controller. The command codes recognized by the VT8237R are listed in the table below.
Table 7. Keyboard Controller Command Codes
Code Keyboard Command Code Description
C8h Unblock Mouse Output (use before D1 to change active mode)
C9h Reblock Mouse Output (protection mechanism for D1)
D1h Write Output Port (data byte following is written to keyboard output port as if it came from keyboard)
D2h Write Keyboard Output Buffer & clear status bit-5 (write following byte to keyboard)
D3h Write Mouse Output Buffer & set status bit-5 (write following byte to mouse; put value in mouse input buffer so it appears to have come from the mouse)
D4h Write Mouse (write following byte to mouse)

CmpXchg wrote: But probably we can't assume it'd work on any machine. So, wouldn't it be more prudent just to invoke your driver routines (as if the kayboard code has just been received), so it will be imposiible to tell was it a real keystroke or just a fake click?

CmpXchg wrote: Combuster has the point: you can mess up the whole packet sequence, so take special care about this. Write your IRQ12 handler cleverly. When a packet arrives, do we get 4 interrupt calls, or can we read all 4 bytes from one call?

Nitro wrote:The only access to the driver provided by microsoft is thru the win32 api.
The reason why i don't want to use it, it's because a fake click/key press CAN be detected, if those routines are hooked by another program.

Nitro wrote:Unfortunatly on windows NT based systems, only drivers can access the interrupts, so that is a card out of the deck.. unless i decide to code a virtual mouse driver, wich i'm trying to avoid.

Nitro wrote:-wait until buffer is empty
-lock mouse
-write packet sequence for clicking/moving.
-unlock mouse