OSDev.org

I have enabled the mouse in every possible way. I have remapped the PICs to 0x30 for master and 0x38 for slave. I'm in protected mode. The keyboard and mouse is unmasked - Everything else is masked. (0xfd for port 0x21 and 0xef for port 0xa1). I have a mouse and keyboard handler. I also have a "everything else" handler, just incase.
The keyboard works. When I move the mouse, no interrupt comes in and the keyboard stops working. I tried debugging it with Bochs. Before I move the mouse and I push a key, the following is debugged:
00012824000d[KBD ] gen_scancode(): BX_KEY_T pressed
00012824000d[KBD ] gen_scancode(): writing translated 14
00012824000d[KBD ] kbd_enQ(0x14)
00012824000d[KBD ] kbd_enQ: putting scancode 0x14 in internal buffer
00012824000d[KBD ] activating timer...
00012824000d[KBD ] service_keyboard: key in internal buffer waiting
00012824500d[IOAP ] set_irq_level(): INTIN1: level=1
00012824500d[IOAP ] IOAPIC: servicing
00012824500d[IOAP ] service_ioapic(): INTIN0 is masked
00012824500d[IOAP ] service_ioapic(): INTIN1 is masked
00012824500d[IOAP ] service_ioapic(): INTIN6 is masked
00012824500d[PIC ] IRQ line 1 now high
00012824500d[PIC ] signalling IRQ(1)
00012824500d[CPU0 ] interrupt(): vector = 49, INT = 0, EXT = 1
00012824500d[CPU0 ] int_trap_gate286(): INTERRUPT TO SAME PRIVILEGE

When I move the mouse, I get the following:
00030898000d[KBD ] [mouse] Dx=-1 Dy=0 Dz=0
00030898000d[KBD ] mouse_enQ(18)
00030898000d[KBD ] mouse_enQ(ff)
00030898000d[KBD ] mouse_enQ(00)
00030898000d[KBD ] service_keyboard: key(from mouse) in internal buffer waiting
00030898500d[IOAP ] set_irq_level(): INTIN12: level=1
00030898500d[IOAP ] IOAPIC: servicing
00030898500d[IOAP ] service_ioapic(): INTIN0 is masked
00030898500d[IOAP ] service_ioapic(): INTIN1 is masked
00030898500d[IOAP ] service_ioapic(): INTIN6 is masked
00030898500d[IOAP ] service_ioapic(): INTIN12 is masked
00030898500d[PIC ] IRQ line 12 now high
00030898500d[PIC ] slave: signalling IRQ(12)
00030898500d[PIC ] IRQ line 2 now high

As you can see, the CPU0 information is missing.

The second time a signal comes from the mouse, this is the only thing debugged:
00031096000d[KBD ] [mouse] Dx=-2 Dy=0 Dz=0

After the mouse is moved and I push a key, the following is debugged:
00036604000d[KBD ] gen_scancode(): BX_KEY_T pressed
00036604000d[KBD ] gen_scancode(): writing translated 14
00036604000d[KBD ] kbd_enQ(0x14)
00036604000d[KBD ] kbd_enQ: putting scancode 0x14 in internal buffer

What have I done wrong that is causing my mouse to not be able to cause an interrupt? Everything seems to be enabled and unmasked..

is irq2 unmasked?
the second pic raises irq2 to alert the main pic that it has something to tell the processor, but the main pic ignores the second pic because its signal is masked.

Wait.. that's strange.. If that is so, wouldn't the device of IRQ2 start trying to interrupt?

On PCs, the IRQ2 line is used to cascade a slave PIC to the master PIC. I don't know if a device configured for IRQ2 would have its interrupt request end up at 2 or 9 as I've read conflicting documents. Anyway I think only old ISA devices can be configured for IRQ2.
IIRC one of my old laptops didn't cascade its PIC-compatible lookalikes but still operated as if they were. Or something like that, the machine is busted these days.

ComputerPsi wrote: Wait.. that's strange.. If that is so, wouldn't the device of IRQ2 start trying to interrupt?

During PIC programming, you'll have to tell each pic on which irq's slaves are connected by setting the corresponding bits. If the slave wants to interrupt the processor it raises its int line, which is connected to IRQ2 on the master PIC, consequently the master will then try interrupt the processor (which is what the term cascading is used for).
When the processor asks for the vector the master checks the slaves connected register, and if the corresponding bit is set then the master signals the slave that his audience is granted, and the slave sends the interrupt number. If the slave bit is cleared, the master itself will send the interrupt number.

on old computers, there was only the master, and irq2 was thus available for other devices. On modern computers where the need for more irq's increased, they added the slave. (those are _old_ boxes, so unless there are 80386 boards with one pic, expect both - I only have 486 and up so i dont know exactly what happens before that)

It's not obvious though what happens when irq2 is raised outside the slave and the slave has no interrupts to report, but the master must be able to "hear" the slave in order to allow his request to be forwarded to the processor. Hence irq2 should be unmasked by default, which i think is the solution to your problem.

the slave PIC was added on either the XT or AT (i think AT) -- the XT still used the 8088 CPU, and the AT used a 80286 -- so all 386 computers (which are usually based on the AT) should have a slave PIC tied to IRQ2