Keyboard

[theubu]

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]

..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 ?

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]

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

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

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


ot:

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]

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]

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

[Brendan]

Hi,

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: Select all

void keyboardHandler() {
  int key = 0x0;

  key = atkbd_scan();

With:

Code: Select all

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]

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: Select all

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

cheers,
gaf