not unique keyboard scancodes

[zgintasz]

Hi,

I'm developing my OS, it's in very early stage. I'm creating keyboard driver, but I noticed some bugs. This is how I get scancode and use scancode:

Code: Select all

scancode = inportb(0x60);

if (scancode & 0x80)
{
}
else
{
	cprintf("%i", scancode);
}

I noticed, that some keyboard keys has the same scancode, for example num pad 7 has the same scancode as home key, num pad 8 has the same as arrow up and etc... How to fix it ?

Thanks.

[online]

This document may help you a bit I think:
http://www.win.tue.nl/~aeb/linux/kbd/sc ... html#ss1.2

[zgintasz]

This document may help you a bit I think:
http://www.win.tue.nl/~aeb/linux/kbd/sc ... html#ss1.2

Thanks, but which exactly section should I read ? Maybe can you show solution by the code?

[Brendan]

Hi,

This is how I get scancode and use scancode:

If you don't use an IRQ and don't check bit 0 of the PS/2 controller's status register; then there's no way for you to know if the value you're reading from IO port 0x60 is a new value (that you haven't read yet) or an old value (that you've already read one or more times before).

It's probably best to read the wiki page about the PS/2 controller (especially the part about receiving bytes from devices).

I noticed, that some keyboard keys has the same scancode, for example num pad 7 has the same scancode as home key, num pad 8 has the same as arrow up and etc... How to fix it ?

This sounds like a different problem though. It sounds like you're using "scancode set 1" (which was designed for 84 key keyboards) and you need "scancode set 2". For this problem, you'd want to read the part about translation in the wiki page about the PS/2 controller.



Cheers,

Brendan

[zgintasz]

Thanks, I'm using IRQ, the big part is based on Bran's Kernel Development tutorial. I'll took at it, thanks.
EDIT: how can I use/enable scan code set 2? I can't find information.

[egos]

This sounds like a different problem though. It sounds like you're using "scancode set 1" (which was designed for 84 key keyboards) and you need "scancode set 2". For this problem, you'd want to read the part about translation in the wiki page about the PS/2 controller.

Prefixes 0xE0, 0xE1 work in set 1 (including translation) as well as in set 2.

EDIT: how can I use/enable scan code set 2? I can't find information.

Use keyboard command 0xF0 to set scan code set. Use controller command 0x60 to clean translation bit (to disable translation).

[SparrowOS]

So, scan codes are usually 00-7F or they are E0 followed by 00-7F.

What I do is if it is an E0 scan code, I make the scan code 80-FF.

My applications, just have to worry about a one byte scan code, not multibyte.

[jnc100]

Your problem (as alluded to by others) is that you ignore the e0 scancode. The line 'if (scancode & 0x80) { }' will ignore the e0 code as 0xe0 & 0x80 evaluates to true, thus the only code of a two byte scancode you read will be the second byte.

Regards,
John.

[SparrowOS]

Code: Select all

U8 GetChar()
{
  U8 b=InPort(0x60);
  if (b==0xE0)
    return 0x80+(InPort(0x60)&0x7F);
  else
    return b&0x7F;
}

[Brendan]

Hi,

That's broken.

Code: Select all

U8 GetChar()
{
  U8 b=InPort(0x60);
  if (b==0xE0)
    return 0x80+(InPort(0x60)&0x7F);   // Return 0x60, because the keyboard didn't have time to send the
                                       //     next byte and "(0x80 + 0xE0) & 0xFF = 0x60"
  else
    return b&0x7F;
}

Alternatively it could return a byte from the mouse! Yay.


Cheers,

Brendan

[SparrowOS]

Code: Select all

U16 GetChar()
{
  U8 b0=InPort(0x60),b1=0x80;
  if (b0==0xE0) {
    b0=InPort(0x60);
    b1=0x80;
  }
  if (b0&0x80)
    return 0x100+b1+(b0&0x7f);
  else
    return b1+(b0&0x7F);
}

Yeah, keyboard and mouse get mixed-up if you don't use interrupts.

If you do, I think you need to read just one byte from 0x60 per interrupt for keyboard.

On one machine, my mouse interrupt doesn't fire, so I poll about 50 times a second. It doesn't get mixed-up because keyboard IRQ does fire.

When you write your debugger, you want to poll keyboard, not use interrupts.

[zgintasz]

Your problem (as alluded to by others) is that you ignore the e0 scancode. The line 'if (scancode & 0x80) { }' will ignore the e0 code as 0xe0 & 0x80 evaluates to true, thus the only code of a two byte scancode you read will be the second byte.

Regards,
John.

I don't think so, it just checks if the key was released(right?).
By the way, I cut that part of code just to test if it works and put it in the main function:

Code: Select all

int fail_safe=200000;
	while ((inportb(0x64)&2)!=0 && fail_safe>0) fail_safe--;
    outportb (0x60, 0xf0);

	fail_safe=200000;
	while ((inportb(0x64)&2)!=0 && fail_safe>0) fail_safe--;
    outportb (0x60, 2);

It doesn't work, I still get the same scancodes.

Code: Select all

U8 GetChar()
{
  U8 b=InPort(0x60);
  if (b==0xE0)
    return 0x80+(InPort(0x60)&0x7F);
  else
    return b&0x7F;
}

then some keys(e.g. insert, home, page up, delete, end, page down, arrays) aren't recognised.

_______________________________________
IGNORE EVERYTHING TEMPORARY . I've got another problem, I think I should fix it first. So, here is an example:
if I put this function in keyboard.c file:

Code: Select all

uint8 GetChar()
{
  uint8 b=inportb(0x60);
  if (b==0xE0)
    return 0x80+(inportb(0x60)&0x7F);
  else
    return b&0x7F;
}

then I get error from GRUB, it says "Invalid or unsupported executable format". Compiler doesn't show anything bad.
if I put this function in main file - I don't get error. Why(it's not because of only that function) ?

[egos]

So, scan codes are usually 00-7F or they are E0 followed by 00-7F.

??? Extra prefixes can follow before basic codes to change key meaning. You should use additional translation tables in this case.

What I do is if it is an E0 scan code, I make the scan code 80-FF.

??? No, you confuse 0xE0 with 0xF0 prefix. Moreover in set 1 and set 2 with enabled translation the "break" scan codes are produced by hardware.

My applications, just have to worry about a one byte scan code, not multibyte.

My applications use virtual key codes and accompanied key flags (led status, left/right "shift" status). Now are defined about 140 codes including some specific codes for european (one additional code: UK backslash) and japanese (five additional codes: Kana and so on) keyboards. Only keyboard driver works with multibyte predbuffer. Virtual key codes are 32-bit. They are transfering through console event queue as part of event packages.

then I get error from GRUB, it says "Invalid or unsupported executable format".

Do you use Multiboot header in your executable module? If so, check for its location within the first 8 Kbytes.

[SparrowOS]

So, scan codes are usually 00-7F or they are E0 followed by 00-7F.

??? Extra prefixes can follow before basic codes to change key meaning. You should use additional translation tables in this case.

What I do is if it is an E0 scan code, I make the scan code 80-FF.

??? No, you confuse 0xE0 with 0xF0 prefix. Moreover in set 1 and set 2 with enabled translation the "break" scan codes are produced by hardware.

My applications, just have to worry about a one byte scan code, not multibyte.

My applications use virtual key codes and accompanied key flags (led status, left/right "shift" status). Now are defined about 140 codes including some specific codes for european (one additional code: UK backslash) and japanese (five additional codes: Kana and so on) keyboards. Only keyboard driver works with multibyte predbuffer. Virtual key codes are 32-bit. They are transfering through console event queue as part of event packages.

then I get error from GRUB, it says "Invalid or unsupported executable format".

Do you use Multiboot header in your executable module? If so, check for its location within the first 8 Kbytes.

Maybe in China it's F0. In America it's definitely E0.

[Brendan]

Hi,

So, scan codes are usually 00-7F or they are E0 followed by 00-7F.

??? Extra prefixes can follow before basic codes to change key meaning. You should use additional translation tables in this case.

What I do is if it is an E0 scan code, I make the scan code 80-FF.

??? No, you confuse 0xE0 with 0xF0 prefix. Moreover in set 1 and set 2 with enabled translation the "break" scan codes are produced by hardware.

Maybe in China it's F0. In America it's definitely E0.

For scancode set 1, 0xE0 is the first byte of a multi-byte scan code, and the highest bit of the last byte indicates if the key was released. E.g. "0xE0, 0x48 = cursor up key pressed" and "0xE0, 0xC8 = cursor up key released".

For scancode set 2, 0xE0 is the first byte of a multi-byte scan code; and 0xF0 means the key was released. E.g. "0xE0, 0x75 = cursor up key pressed" and "0xE0, 0xF0, 0x75 = cursor up key released".


Cheers,

Brendan