Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: > On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > > Hi, > > > > This one is a winner. with regards to your follow up. I wouldn't > > want to reset something unless we have cause to. This code > > seems to be doing the right thing e.g. I see "unable to query > > synaptics hardware" followed by it's (re)discovery on return > > from S3. > > > > When it's fully supported by the Synaptics driver, the initial > > reconnect will succeed and we'll never get to this additional > > failsafe code which is essentially a catch all for the bleeding > > edge. > > > > I am confused here... what protocol does the kernel select upon fresh > boot? Peter's dmesg: [ 7.428561] Unable to query Synaptics hardware. It's plain PS/2 or IMPS/2 because this bleeding edge device fails somewehre in synaptics_query_hardware(). Most likely the test on priv->identity. [ 8.239494] input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input12 This is the normal KERN_INFO printk of input_register_device() which does not mean that it's using the synaptics driver. "PS/2 Synaptics TouchPad" is just the name of the device. in conclusion: If a Synaptics touchpad can't be initialized (synaptics_init) and falls back to PS/2, it doesn't get a psmouse_reset() after resuming from suspend as it would get with a synaptics driver. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
