On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > 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. Ah, I missed that. Peter, could you boot with i8042.debug so we could see where exactly Synaptics detection fails? > > [ 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. Yes, you are right. Maybe we should just reset psmouse unconditionally in psmouse_reconnect() before actually doing any protocol reconnect/reprobe. That should help in cases when users not enable Synaptics support; also it is probably unlikely that mouse that was there gets unplugged after resume. -- Dmitry -- 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
