linux-kernel - Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091012090224.GB7403@core.coreip.homeip.net>
Date:	Mon, 12 Oct 2009 02:02:24 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	"Carlos R. Mafra" <crmafra2@...il.com>
Cc:	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	linux-input@...r.kernel.org
Subject: Re: [bisected regression] Touchpad "paste" stops working after
	suspend to RAM

On Sun, Oct 11, 2009 at 09:31:00PM +0200, Carlos R. Mafra wrote:
> On Sun 11.Oct'09 at 11:01:34 -0700, Dmitry Torokhov wrote:
> > Hi Carols,
> > 
> > On Sun, Oct 11, 2009 at 06:21:55PM +0200, Carlos R. Mafra wrote:
> > > Using the latest 2.6.32-rc3+ kernel, the "paste" operation via the 
> > > touchpad of my Vaio laptop does not work after suspend to RAM.
> > > 
> > > It works flawlessly before s2ram; I select the text with the touchpad
> > > and tap quickly its right corner to paste the selected text.
> > > After a plain 'echo mem > /sys/power/state' the "paste" does not work.
> > > 
> > > I bisected it to commit ffd0db97196c1057f09c2ab42dd5b30e94e511d9 ("Input: 
> > > add generic suspend and resume for input devices").
> > > 
> > > I haven't tested if reverting it from mainline fixes the issue, but 
> > > from the patch description I guess that bisection landed correctly
> > > on the culprit.
> > > 
> > 
> > Please verify that this is the real offending commit by reverting it - I
> > am surprised that it would give any trouble since it is supposed to
> > restore LED state and repeat rate and therefore should only be affecting
> > keyboards.
> 
> Reverting it fixes the issue, I've just tested it now.
> 
> [ I had to edit the resulting drivers/input/input.c because it did not 
>   revert cleanly. ]

Carols, I see in the dmesg you supplied earlier ALPS was redetected
successfully, so I guess the problem is that your synclient quirk did
not run after resume. The best way to handle it would be adding a HAL
rule, something like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
        <device>
                <match key="input.x11_driver" contains="synaptics">
                        <merge key="input.x11_options.SHMConfig" type="string">On</merge>
                </match>
        </device>
</deviceinfo>

You'd need to add add the corner tapping command.

Still, I am curious to know why we can't simply reinitialize ALPS from
the get go, could you please send me a dmesg of resume done with
i8042.debug? Thanks!

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/