which row is numpad (+) and (Enter) on?

[austanss]

I know it sounds like a simple question, but the numpad + and ENTER keys are on two different rows.

I'm trying to structure a keyboard packet with the coordinates of the keys on the keyboard.

Which row should I set those two keys to?

Numpad + is on row 2&3 (starting from zero) and numpad ENTER is on row 4&5.

[iansjack]

I'm trying to structure a keyboard packet with the coordinates of the keys on the keyboard.

I'm a bit confused as to the purpose of what you are doing here. Assuming you mean the physical row of the keyboard that a key is on, what interest is that? And bear in mind that different keyboards have different sized keys and even different key layouts.

[austanss]

I'm trying to structure a keyboard packet with the coordinates of the keys on the keyboard.

I'm a bit confused as to the purpose of what you are doing here. Assuming you mean the physical row of the keyboard that a key is on, what interest is that? And bear in mind that different keyboards have different sized keys and even different key layouts.

I'm trying to know the row/column of the key pressed/released on a US QWERTY keyboard.

[iansjack]

But why? Surely the scan code is the important thing.

[austanss]

But why? Surely the scan code is the important thing.

You bring a fair point. I could manufacture my key codes... differently.

[pvc]

I was kind of confused about this thread as well.

If you want to use your own key codes, then the answer to your original question is: It doesn't matter. You could assign some completely random numbers to your keys and it would be just fine, as long as you stick with it and use the same number everywhere. I, for example, like to use virtual key codes from Windows.

[austanss]

This is what I settled on for my keycodes:

Code: Select all

    struct keyboard_packet kbpacket;
    uint16_t scan_code = io::inb(0x60);
     // if we get E0 from PS/2, read another byte and append it
    if (scan_code == 0xE0)
    {
        scan_code <<= 8;
        scan_code |= io::inb(0x60);
    }
     // If we have an extended scancode
    if ((scan_code >> 8) == 0xE0)
    {
        // Discard the E0 byte
        scan_code &= 0x00FF;
       // Subtract 0x10 from the scancode, as that is where the E0 scancodes start
        scan_code -= 0x10;
       // 0x90 (max E0 "press" scancode) subtracted by 0x10, if less than 0x80 then it was a press 
        if (scan_code < 0x80)
        {    
            kbpacket.release_or_press = 1;
        }
     // If greater than 0x80 it was a release
        else
        {
     // signal the release and subtract 0x80 to get its press scancode
            kbpacket.release_or_press = 0;
            scan_code -= 0x80;
        }
     // Append 0x80 to scan code to put it an a "E0 scancode space"
        scan_code += 0x80;
     // kbpacket.key_code is 8 bits
        kbpacket.key_code = (scan_code & 0x00FF);
    }
   // If not an E0 byte, do a similar process without putting the scancode in the E0 space
    else
    {
        if (scan_code < 0x80)
        {    
            kbpacket.release_or_press = 1;
            kbpacket.key_code = scan_code;
        }
        else
        {
            kbpacket.release_or_press = 0;
            kbpacket.key_code = scan_code - 0x80;
        }
    }

[Octocontrabass]

This is what I settled on for my keycodes:

Well, this definitely won't work on some computers. You need to wait for the next IRQ before reading the next byte from port 0x60. Otherwise, you may end up reading garbage, or the same byte again, or a byte belonging to the other device attached to the PS/2 controller.

Even if it does work, it may cause a spurious IRQ.

(And what will you do for USB keyboards? Those don't use the same scan codes as PS/2 keyboards.)

[austanss]

This is what I settled on for my keycodes:

Well, this definitely won't work on some computers. You need to wait for the next IRQ before reading the next byte from port 0x60. Otherwise, you may end up reading garbage, or the same byte again, or a byte belonging to the other device attached to the PS/2 controller.

Even if it does work, it may cause a spurious IRQ.

(And what will you do for USB keyboards? Those don't use the same scan codes as PS/2 keyboards.)

Assuming USB keyboard won't run on IRQ1, USB keyboards will have a different handler yet same keyboard event system, with same keyboard packet structure.