Mouse Location Always Zero

[Octacone]

I used this tutorial for my mouse driver: http://forum.osdev.org/viewtopic.php?t=10247
When I use my debug tool to see if the mouse has moved, I always get zero for both x and y.
I've been debugging for past two days and can not find what the issue is. :/
What could be a problem.

[sebihepp]

Do you have working interrupts?

I think the irq_install could be a common mistake, because it uses 12 as IRQ. In PMode there are Exceptions from 0x0 to 0x1F, so you need to remap the PIC. An the 12 is therefore not the 12. Exception, but the twelvth line of the PIC. Perhaps that's your mistake?

[Octacone]

Do you have working interrupts?

I think the irq_install could be a common mistake, because it uses 12 as IRQ. In PMode there are Exceptions from 0x0 to 0x1F, so you need to remap the PIC. An the 12 is therefore not the 12. Exception, but the twelvth line of the PIC. Perhaps that's your mistake?

Yeah I think my interrupts are working fine.
I have a function that remaps IRQs.

[Combuster]

Having code doesn't mean it works . The fact that you're not even telling us if you're getting interrupt 44 strongly suggests it doesn't.

Hint: If you have to write "I think" you usually did something wrong you could have already fixed.

[Octacone]

Having code doesn't mean it works . The fact that you're not even telling us if you're getting interrupt 44 strongly suggests it doesn't.

Hint: If you have to write "I think" you usually did something wrong you could have already fixed.

How am I supposed to tell if I am getting interrupt 44 when I don't have a way of seeing that.

[neon]

Well, make a way to see it then. You really should have debugging services implemented prior to going into graphics. Its better to implement a protocol now rather then later on when it becomes much more harder. Options include, but are not limited to (1) display something on the screen, anything; (2) serial output; (3) stay in text mode and print the mouse status and interrupt information. In the long term, serial output is the way to go. Never assume your code works - verify that it actually works.

You mentioned using a debugging tool, so what prevents you from using it to check this?

With that said, sebihepp is right - looking over the code, it can't be simply copied and pasted. Depending on your architecture and where your PIC maps physical irq 12 to, your code will be slightly different. IIRC the way most tutorials map the PIC would map physical irq 12 to logical irq 44 but again, its all up to what you did in your code.

[Octacone]

Well, make a way to see it then. You really should have debugging services implemented prior to going into graphics. Its better to implement a protocol now rather then later on when it becomes much more harder. Options include, but are not limited to (1) display something on the screen, anything; (2) serial output; (3) stay in text mode and print the mouse status and interrupt information. In the long term, serial output is the way to go. Never assume your code works - verify that it actually works.

You mentioned using a debugging tool, so what prevents you from using it to check this?

With that said, sebihepp is right - looking over the code, it can't be simply copied and pasted. Depending on your architecture and where your PIC maps physical irq 12 to, your code will be slightly different. IIRC the way most tutorials map the PIC would map physical irq 12 to logical irq 44 but again, its all up to what you did in your code.

Yeah, I made a simple debugger that talks to QEMU's serial console. I can output text and see the output while my OS is running.

[iansjack]

So you know how to check if the interrupt is firing.

[Octacone]

So you know how to check if the interrupt is firing.

Maybe, I only have my IDT ready, no external interrupts inside assembly.
Also when I initialize my keyboard I can type and see the text, but when I move my mouse characters appear on the screen like I typed them.

[Octacone]

I "remade" my interrupts, now I am getting infinite restart loop. I can see my GUI for a second and then it restarts again and again.

[BrightLight]

I "remade" my interrupts, now I am getting infinite restart loop. I can see my GUI for a second and then it restarts again and again.

That doesn't say much. Run it in Bochs and show us the log messages,

[Octacone]

I "remade" my interrupts, now I am getting infinite restart loop. I can see my GUI for a second and then it restarts again and again.

That doesn't say much. Run it in Bochs and show us the log messages,

That is a very very good idea. Bosch has one really nice debugger.

[Octacone]

Bochs output:

Code: Select all

 using log file bochsout.log
Next at t=0
(0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
<bochs:1> c
(0).[240243672] [0x0000000000000003] 0008:0000000100000003 (unk. ctxt): lock push ebx             ; f053
Next at t=240243673
(0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0

When I use QEMU I get infinite restart loop and when I use Bochs it works just fine.

[Combuster]

when I use Bochs it works just fine.

Bochs works just fine, yes, but not your code. It still restarts the CPU on bochs, on the account of executing garbage memory.

[Octacone]

when I use Bochs it works just fine.

Bochs works just fine, yes, but not your code. It still restarts the CPU on bochs, on the account of executing garbage memory.

Ummm... What could be the problem then.