The introduction of a call to synaptics_resolution() in kernel 2.6.31 results in Synaptics touchpad on HP Pavilion 9500 series laptop to no longer work. This regression was introduced with commit ec20a022aa24fc63d3ab59584cb1e5aa9a21d46c Commenting out the call to the synaptics_resolution() function restores functionality: static int synaptics_query_hardware(struct psmouse *psmouse) { if (synaptics_identify(psmouse)) return -1; if (synaptics_model_id(psmouse)) return -1; if (synaptics_capability(psmouse)) return -1; /* if (synaptics_resolution(psmouse)) return -1; */ return 0; }
I wonder does the touchpad respond to resolution query with invalid/unexpected data? Can you try adding debug printouts to synaptics_resolution() in drivers/input/mouse/synaptics.c? Something like following: /* * Read touchpad resolution * Resolution is left zero if touchpad does not support the query */ static int synaptics_resolution(struct psmouse *psmouse) { struct synaptics_data *priv = psmouse->private; unsigned char res[3]; if (SYN_ID_MAJOR(priv->identity) < 4) return 0; if (synaptics_send_cmd(psmouse, SYN_QUE_RESOLUTION, res)) return 0; if ((res[0] != 0) && (res[1] & 0x80) && (res[2] != 0)) { priv->x_res = res[0]; /* x resolution in units/mm */ priv->y_res = res[2]; /* y resolution in units/mm */ } /* debug: print resolution query reply from the device */ printk(KERN_INFO "synaptics: %x %x %x\n", res[0], res[1], res[2]); /* debug: reset pad resolution to 0 (i.e. not detected) as workaround */ priv->x_res = 0; priv->y_res = 0; return 0; } Please send the output and also the identity/capabilities line that says something like "Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04713/0x200000"
This is proving to be slightly more complicated than I expected. When I build the kernel with psmouse compiled as a module, I can not reproduce the problem, even with the original code that queries the touchpad resolution. When psmouse support is built into the kernel, the outcome seems a bit random. Sometimes the Synaptics touchpad will be detected and work OK, at other times the kernel will not detect the touchpad. Having the synaptics_resolution() call commented out just decreases the likelihood of failure, but it can still fail. This leads me to believe that this may be some sort of a race condition. Possibly relevant lines from dmesg output: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input5 Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04713/0x200000 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input8 Excerpt from a working kernel .config: # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1440 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=900 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=y # CONFIG_GAMEPORT is not set Changing CONFIG_MOUSE_PS2=m to CONFIG_MOUSE_PS2=y will cause the problem to be reproduced in a majority of reboots. When the problem occurs, I get the following dmesg output: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input5 i.e.: There is no sign of the Synaptics device at all.
Ok, the problem is then most probably out of my area of knowledge. Searchin the linux-input list I found this http://thread.gmane.org/gmane.linux.kernel.input/8344. Could that be related?
Created attachment 205983 [details, diff] Small retarded debugging patch A bit of an uneducated overkill but could you apply the attached patch to a 2.6.31 kernel and post your dmesg after your synaptics fail? Basically, I added debug messages to the 'dangerous' functions/macros of synaptics_resolution() all over the driver/input/mouse/synaptics.c file. If we are lucky enough and one of the two functions of synaptics_resolution() bugs, we should, at least, see which one is the defective one. Thanks!
Created attachment 205984 [details, diff] Small retarded debugging patch which actually makes sense Previous patch had some minor errors, this one should actually apply.
Like Peteru said in comment #2 the bug randomly occurs even if synaptics_resolution() is commented out and also that there is no sign of Synaptics *at all* in this case. If we reached that far as detecting the touchpad and calling synaptics_query_hardware() (which calls synaptic_resolution) there should be "Synaptics Touchpad, model: nnn..." or at least one of the errors "Unable to query Synaptics hardware" or "Unable to initialize Synaptics hardware". I believe that no sign of Synaptics in log means synaptics_resolution() was not called i.e. touchpad was not even detected.
(In reply to comment #6) > Like Peteru said in comment #2 the bug randomly occurs even if > synaptics_resolution() is commented out and also that there is no sign of > Synaptics *at all* in this case. > > If we reached that far as detecting the touchpad and calling > synaptics_query_hardware() (which calls synaptic_resolution) there should be > "Synaptics Touchpad, model: nnn..." or at least one of the errors "Unable to > query Synaptics hardware" or "Unable to initialize Synaptics hardware". > > I believe that no sign of Synaptics in log means synaptics_resolution() was not > called i.e. touchpad was not even detected. > (In reply to comment #6) > Like Peteru said in comment #2 the bug randomly occurs even if > synaptics_resolution() is commented out and also that there is no sign of > Synaptics *at all* in this case. > > If we reached that far as detecting the touchpad and calling > synaptics_query_hardware() (which calls synaptic_resolution) there should be > "Synaptics Touchpad, model: nnn..." or at least one of the errors "Unable to > query Synaptics hardware" or "Unable to initialize Synaptics hardware". > > I believe that no sign of Synaptics in log means synaptics_resolution() was not > called i.e. touchpad was not even detected. > My logic was that since synaptics_resolution() makes it more likely for the break to happen, SYN_ID_MAJOR or synaptics_send_cmd() are buggy and there is a chance that they fulfill a race condition or something and wreak havoc. The thing is that I didn't check the order in which the functions are called (or their names for that matter), that's why it was an uneducated patch, so I fucked up like you correctly pointed out. (There is always a chance that the breakage happens at the "Synaptics Touchpad, model..." printk line where it calls SYN_ID_MAJOR (which seems like an ultra trivial macro to me, but you never know)) I also thought of adding a debug printk to device/input/mouse/psmouse-base.c right before it detects and calls synaptics_init() but I didn't want to create an over-overkill patch and I left it out (which I kinda regret right now). Anyway, I won't create any other patches before digging into the code a bit more, for now. Peteru, I'd also like a full copy of your dmesg when your touchpad gets detected and another one when your touchpad doesn't get detected. Tero, if you have any ideas feel free to share them :)
Created attachment 206147 [details] dmesg - unpatched kernel - Synaptics is NOT detected. This is the dmesg output seen with unpatched kernel source. Mouse support is compiled into the kernel and the Synaptics touchpad is not detected.
Created attachment 206149 [details] dmesg - synpatch applied - Synaptics is detected. This is the dmesg output seen with synpatch from comment #5 applied. Mouse support is compiled into the kernel and the Synaptics touchpad is detected. Presumably there is enough of a change in the timing / sequencing of events to make the touchpad work. A few (possibly inconsequential) observations: * When touchpad is detected, the CPU frequency/BogoMIPS calculation detects the CPU as being slightly faster than when touchpad is not detected. * When touchpad is detected, USB ehci initialisation and SATA HDD partition detection happens earlier than when touchpad is not detected. * When touchpad is detected, dmesg output contains "serio: i8042 AUX port at 0x60,0x64 irq 12", however this line is absent when the touchpad is not detected.
Created attachment 206150 [details] dmesg - synpatch applied - Synaptics is NOT detected. This is the dmesg output seen with synpatch from comment #5 applied. Mouse support is compiled into the kernel and the Synaptics touchpad is NOT detected. This is exactly the same system configuration as in comment #9, just one reboot later.
Created attachment 206153 [details] Synaptics detected, includes i8042.debug This is dmesg output obtained with i8042.debug turned on - in this case the Synaptics touchpad was detected.
Created attachment 206155 [details] Synaptics NOT detected, includes i8042.debug This is dmesg output obtained with i8042.debug turned on - in this case the Synaptics touchpad was NOT detected.
Comparing the dmesg output from comment #11 and comment #12 leads me to suspect that the initialisation of ehci_hcd and/or sda and sdb may cause enough of a delay to cause a i8042 timeout, which in turn may result in the AUX port not being detected. Does that sound plausible?
As I mentioned this is unfortunately something I'm not familiar with but others seem to be having similar problems, have you checked this patch http://patchwork.kernel.org/patch/41353/. It went into 2.6.32-rc0.
I have used the linux-input mailing list to seek help and exchanged some messages with Dmitry Torokhov. To summarise: 1. Workaround with kernels before 2.6.32 is to add i8042.noloop to the kernel command line in your GRUB configuration. This will disable the aux irq delivery test. 2. Kernel 2.6.32 will disable aux irq delivery test on all laptops and portables (as long as they have sane PNP data). Waiting for sys-kernel/gentoo-sources-2.6.32 to be released to verify effectiveness of the fix.
That's good news. Have you tried the workaround or a git-sources to see if the fix made it to the development tree?
Let us know if a patch comes out of your collaboration with Dmitry Torokhov and we'll look to include it with gentoo-sources.
Preliminary tests with git-sources-2.6.32-rc6 indicate that this has been fixed in the kernel itself, so there probably won't be need for a patch in the final kernel 2.6.32 release. I'll retest once gentoo-sources-2.6.32 makes an appearance.
This has been verified as fixed in gentoo-sources-2.6.32 and later kernel releases.
