From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2
Description of problem:
See URL for description and patch.
Note that this affects ALL Compaq Presario R3000-series units, not just the particular AMD64 unit described on that page.
I'm not sure at all that the patch provided above is the correct way to go...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. i8042 is detected in MUX mode
3. ALPS touchpad is not detected
4. Sometimes a while later it will suddenly start working, along with a kernel message about "detected ImPS/2 on i8042.mux2" or something along those lines (will update bug when it happens again)
Actual Results: ALPS touchpad does not get detected properly through i8042 MUX on Presario R3000 laptops.
Expected Results: Should be detected at least as plain ImPS/2 device...
adding i8042.nomux to boot arguments appears to fix problem
There are multiple pages (googleable, that's how I found them) that describe R3000 touchpad problems. I _believe_ there's something wrong with the initial state of the 8042 mux, or the initial state of the touchpad.
I'd say about 75% of the time that the touchpad starts working spontaneously, it's after I've attached a USB mouse and started X.
More testing, confirmed with some other OSes that understand muxing...
The i8042 is configured into mux mode by the bios - which is kinda stupid since
there isn't even an external ps/2 port on these notebooks.
On both the kbd and mouse ports, the built-in (only!) devices are physically
wired to the last mux port instead of the first. (Possibly a hardware design
As far as I can tell, the problem is that the 8042 enumeration code at boot time
can't properly talk to the 8042 on this motherboard.
In linux-18.104.22.168/drivers/input/serio/i8042.c, line 578, we have a
printk(KERN_INFO,... which would give a bit of useful info during boot - if I
knew how to see INFO level messages during the boot sequence. There's the
"earlyprintk=vga" parameter, but that doesn't _seem_ to do the trick.
Suggestions on how to capture KERN_INFO messages during boot?
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.