Messages in this thread | | | Date | Sat, 29 Jan 2005 21:59:21 +0200 | From | Jaco Kroon <> | Subject | Re: i8042 access timings |
| |
Vojtech Pavlik wrote: >>>What I believe is happening is that we're talking to SMM emulation of >>>the i8042, which doesn't have a clue about these commands, while the >>>underlying real hardware implementation does. And because of that they >>>disagree on what should happen when the command is issued, and since the >>>SMM emulation lazily synchronizes with the real HW, we only get the data >>>back with the next command.
This makes sense in a weird kind of way.
>>>I still don't have an explanation why both 'usb-handoff' and 'acpi=off' >>>help, I'd expect only the first to, but it might be related to the SCI >>>interrupt routing which isn't done when 'acpi=off'. Just a wild guess.
SCI interrupt routing? I have tried with pci=routeirq and that hasn't helped either. IRQ balancing perhaps?
> I don't like the interrupt message, I'll check why it's enabled so > early. It may have a good reason to, as well. Other than that, it looks > very much OK.
That was with usb-handoff. It also resulted in the black screen of bios-death upon reboot though :).
>>So as with acpi=off, we get a correct return. Now that usb is >>mentioned, I think either myself or Sebastian has mentioned that the >>keyboard does not work unless USB1.1 support is compiled in. Another >>clue possibly? > > > Compiling USB 1.1 support does the very same thing as specifying > usb-handoff on the command like - tells the BIOS to keep its hands off > the USB _and_ PS/2 controllers.
I'm missing something, I have USB1.1 compiled in, then why does the touchpad not work if it does the very same thing as usb-handoff?
>>Another question - would it be usefull at all to see what happens if the >>AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST >>rely on the fact that AUX_LOOP must first fail/timeout somehow? > No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail > similarly when BIOS is active.
That is correct. It fails with timeout. This for me confirms the fact that it is responding one command too late. aka, we send a command, it times out, we send another, it sends the result of the first.
Right, any new (or variations of existing ones) theories that I can try out to make this touchpad work correctly? I can simply hack out the test for the touchpad but that doesn't solve the problem for others.
Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ [unhandled content-type:application/x-pkcs7-signature] | |