Page 1 of 1
Keyboard
Posted: Tue Oct 17, 2006 9:29 am
by 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.
Posted: Tue Oct 17, 2006 12:22 pm
by 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
Posted: Tue Oct 17, 2006 12:38 pm
by 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
)
Posted: Tue Oct 17, 2006 12:47 pm
by 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.
Posted: Tue Oct 17, 2006 2:10 pm
by theubu
Just FYI I put in some locking primitives and the same result I wonder if the keyboard controller itself needs to be adjusted...
Posted: Tue Oct 17, 2006 5:08 pm
by Brendan
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: 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
Posted: Wed Oct 18, 2006 8:15 am
by gaf
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: Select all
while(!(Port::ReadByte(0x64) &output_buffer)); // output_buffer = 1
uchar scancode = Port::ReadByte(0x60);
cheers,
gaf