Keyboard

theubu · **Posted:** Tue Oct 17, 2006 9:29 am

Hello,

I'm having a weird issue and I'm looking for some suggestions on the possible cause.

The issue is as follows, Running my OS through a slow medium such as Bochs or an older computer the keyboard functions fine. When I boot my OS on a much faster machine such as my laptop which is a 2Ghz AMD Turion64 keys miss and duplicate.

Also here is a little additional information. The os is a monolithic based kernel with a timer int running at 200Hz. This int also runs the scheduler.

I have a few theories but right now I'm looking to see how others feel.

gaf · **Posted:** Tue Oct 17, 2006 12:22 pm

Quote:

..keys miss and duplicate...

It could be that your driver is getting out of synchronisation: If another key is pressed before the last has been read in, a scancode gets lost and both interrupts print the second key.

Maybe it's just a problem with the keyboard waiting loop ?

Quote:

The os is a monolithic based kernel with a timer int running at 200Hz. This int also runs the scheduler.

In my opinion 20-50 Hz would be a much more reasonable frequency for the average desktop system..

regards,
gaf

JAAman · **Posted:** Tue Oct 17, 2006 12:38 pm

Quote:

It could be that your driver is getting out of synchronisation: If another key is pressed before the last has been read in, a scancode gets lost and both interrupts print the second key.

i thought about that, but it would make more sence if the trouble was with slower systems, but his trouble is with faster ones

Quote:

Maybe it's just a problem with the keyboard waiting loop ?

that sounds more reasonable, though i dont recall what is required here

ot:

Quote:

In my opinion 20-50 Hz would be a much more reasonable frequency for the average desktop system..

i have always prefered 1k or more myself (possibly slower on 386s though

)

theubu · **Posted:** Tue Oct 17, 2006 12:47 pm

The driver doesn't have a wait loop it's interrupt driven.

The driver can be seen at http://www.ubixos.com/src/atkbd.c

Reading this made me think that possibly because of the increased speed the polling for reading the keyboard buffer is what's creating the problem.

theubu · **Posted:** Tue Oct 17, 2006 2:10 pm

Just FYI I put in some locking primitives and the same result I wonder if the keyboard controller itself needs to be adjusted...

Brendan · **Posted:** Tue Oct 17, 2006 5:08 pm

Hi,

theubu wrote:

Just FYI I put in some locking primitives and the same result I wonder if the keyboard controller itself needs to be adjusted...

Try replacing this:

Code:

void keyboardHandler() {
  int key = 0x0;

  key = atkbd_scan();

With:

Code:

void keyboardHandler() {
  int key = 0x0;

  key = inportByte(0x60);

I vaguely remember something about XT keyboards needing a pulse (pulling the data line low) as an acknowledgement that each byte was received. For PS2 and later keyboards this isn't necessary, and probably does more harm than good.

Bit 7 of I/O port 0x61 is used for other purposes now, and depends on which chipset is used. I looked it up in Intel's 865 chipset datasheets to find this bit is documented as "read only - must be set to zero on writes", and I/O port 0x61 is called the "NMI Status and Control Register".

Cheers,

Brendan

gaf · **Posted:** Wed Oct 18, 2006 8:15 am

theubu wrote:

The driver doesn't have a wait loop it's interrupt driven.

Am I the only one who thinks that some waiting is required before the scancode can be read-in ?

Code:

while(!(Port::ReadByte(0x64) &output_buffer)); // output_buffer = 1
uchar scancode = Port::ReadByte(0x60);

cheers,
gaf

OSDev.org

Keyboard

Who is online