OSDev.org

Hi everybody!

I'm having a problem with my keyboard driver affecting how my PIT is functioning and causes it so that the timer only runs when there is text being written to the screen or input being taken from the keyboard, i have debugged and traced the problem to the following method:
I know its not commented at all but the above determines if a shift key is being pressed and sets the shift variable accordingly and also gets the raw scancode from the keyboard for the key being pressed with or without shift.
I know with some certainty that it is this method causing the problem, so you'll just have to trust me on that.

My current guess is that somehow, this runs on a loop and that it only breaks out of that loop when a key is pressed,
I'm pretty new to OS development and not that great with C at the moment so it may be a very basic error I have missed.

I need some advice on what exactly may be causing this problem and how it could be fixed, any help with fixing this is appreciated, thanks.

Webbsta wrote:My current guess is that somehow, this runs on a loop

You didn't tell us exactly when your code is called. Of course it 'runs in a loop', you have a "while (1)" on top of there. My guess is that you call this function without a key being pressed, and just sit waiting for ever until a key is pressed, while not having interrupts enabled.


JAL

Well it is called on the keyboard interrupt handler, so its only getting a key when its available. Yes it loops but that is part of the design of it and shouldn't cause it to hang.

Webbsta wrote:Well it is called on the keyboard interrupt handler, so its only getting a key when its available. Yes it loops but that is part of the design of it and shouldn't cause it to hang.

Your design is flawed. It is very easy to see what goes wrong. Please just debug it in Bochs or the like, and you'll see. (Hint: check the workings of 'continue'.)


JAL

Why have the loop at all, if there's a return statement at the bottom? And yes, the 'continue' statements in your if and else blocks cause control to jump back to the start of the loop, skipping the return statement; that's why it's not returning.

I now see exactly why but I still cannot find a better way of doing it or fixing the current way, I originally used this for getting keys without interrupts so that is why it worked before but is now broken because of the different type of usage. If you could point me to a way of fixing or replacing this then please do.

Pretty simple - just remove the loop. Assuming you have interrupts set up right, that function will be called *only* when there is a keypress to handle.

And if you take out the loop, be sure that you remove those continue statements as well.

I have tried pretty much everything before and removing the loop is no exception, I am now receiving two of the same keys being printed to the screen, however, the method is still only ever called once per interrupt but even though two characters are being printed to the screen. Not sure where to look next with this bit.

According to the documentation (Wiki, and the internet), what key events cause interrupts?

pcmattman wrote:According to the documentation (Wiki, and the internet), what key events cause interrupts?

It's a quiz! The new way to train newbees :))


JAL

Ohh! Oh! I know! Pick me! Memememe!!

Uhhh, ISR-- oh wait, never mind... </sarcasm>

Heh, sorry guys, it just seems so obvious now, I should have gotten to know more about what interrupts are triggered when a key is pressed, thanks for the help.

Webbsta wrote:Heh, sorry guys, it just seems so obvious now, I should have gotten to know more about what interrupts are triggered when a key is pressed, thanks for the help.

It takes a man to admit ones fault. Or something :). Congrats for finding out.


JAL