Comment 137 for bug 1949394

    Well, I have made a mistake in the patch:
            //reset the mouse
            output[0] = 0xff;
            i8042_command(output, 0x12ff);

    Should be:
            i8042_command(output, 0x12d4); - we are sending data to mouse

    The command should really be a nop:
    "Pulse output line low for 6 ms. Bits 0 to 3 are used as a mask (0 = pulse line, 1 = don't pulse line) and correspond to 4 different output lines.

    Note: Bit 0 corresponds to the "reset" line. The other output lines don't have a standard/defined purpose. "
    we set all line bits for 1 (don't pulse line) so this should really be a NOP. Additionally, no response should be given.

    Mysteriously, the device responded with:

    [ 1.789711] i8042: [537] ff -> i8042 (command)
    [ 1.789773] i8042: [537] ff -> i8042 (parameter)
    [ 1.895570] i8042: [537] fa <- i8042 (return)
    [ 1.898595] i8042: [537] aa <- i8042 (return)

    We should try to emulate Windows as much as possible. We should have someone with a legal Windows on a qemu (sorry, Srihari, Your does not qualify) run it and check how it accesses the keyboard controller - in which particular sequence and try to do it in the exact some way.
    This should fix this and other similar bugs.

Now we will have to narrow down what really fixed the issue.