Bug 15071 - IBM/Lenovo Trackpoint speed, sensitivity reset after suspend
IBM/Lenovo Trackpoint speed, sensitivity reset after suspend
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Input Devices
All Linux
: P1 low
Assigned To: Dmitry Torokhov
:
Depends on:
Blocks: 7216 14230
  Show dependency treegraph
 
Reported: 2010-01-16 16:19 UTC by Marten Vance
Modified: 2010-02-14 23:46 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.32
Tree: Mainline
Regression: Yes


Attachments
dmesg over suspend/resume cycle with i8042.debug=Y (62.39 KB, text/plain)
2010-01-24 23:17 UTC, Marten Vance
Details
dmesg over suspend/resume cycle with i8042.debug=Y, 2.6.32-6 (75.90 KB, text/plain)
2010-01-31 18:00 UTC, Marten Vance
Details
dmesg over suspend/resume cycle with i8042.debug=Y, 2.6.33-rc6 (56.79 KB, text/plain)
2010-02-02 20:32 UTC, Marten Vance
Details
Ignore mouse data until reconnect is done. (1.21 KB, patch)
2010-02-03 06:00 UTC, Dmitry Torokhov
Details | Diff

Description Marten Vance 2010-01-16 16:19:35 UTC
Hi,

I encountered a slight regression from 2.6.31 to 2.6.32 concerning the settings for speed and sensitivity of my Lenovo x61t trackpoint after a suspend/resume-cycle: They're reset to 97 and 128, respectively.

This applies only if the settings are written into sysfs (/sys/devices/platform/i8042/serio1/{speed,sensitivity}).

If there are udev-rules present to set the values they remain unchanged (or are re-set automatically after resume?).

After resume I can write the desired values back into sysfs successfully. So there seems to be nothing broken, only the values are lost. (See also http://bugzilla.kernel.org/show_bug.cgi?id=14970#c11)

This is on Archlinux with a default kernel only enhanced by including the patch from http://bugzilla.kernel.org/show_bug.cgi?id=14970 to re-enable the recognition of the trackpoint device. Suspending and resuming is carried out by pm-utils.


Thanks and cheers,
Marten
Comment 1 Marten Vance 2010-01-17 00:09:55 UTC
Sorry, I made a mistake: this also happens if udev-rules are present, i.e. always. 
`udevadm test /sys/devices/platform/i8042/serio1` re-sets the values successfully, too.

Marten
Comment 2 Dmitry Torokhov 2010-01-23 01:41:00 UTC
Does the same thing happens if you use 'echo "mem" > /sys/power/state' to
suspend? Can I please see dmesg over suspend with i8042.debug kernel option?
Comment 3 Marten Vance 2010-01-24 23:15:00 UTC
Yes, I see the same behavious with 'echo "mem" > /sys/power/state'.

I'm attaching a dmesg-snippet from a suspend/resume-cycle triggered by echo'ing mem into /sys/power/state.

Thanks again, Marten
Comment 4 Marten Vance 2010-01-24 23:17:50 UTC
Created attachment 24698 [details]
dmesg over suspend/resume cycle with i8042.debug=Y
Comment 5 Dmitry Torokhov 2010-01-26 22:05:16 UTC
I think this may have been fixed in the latest kernel. Could you please try 2.6.33-rc5 and let me know if settings persist. If they do not could I get another debug dmesg but from 2.6.32-rc5? Thank you.
Comment 6 Marten Vance 2010-01-31 17:54:16 UTC
I tested with 2.6.32-6 and see the same behaviour. dmesg is coming in a minute.

Thank you, Marten
Comment 7 Marten Vance 2010-01-31 18:00:11 UTC
Created attachment 24832 [details]
dmesg over suspend/resume cycle with i8042.debug=Y, 2.6.32-6
Comment 8 Dmitry Torokhov 2010-02-01 17:06:11 UTC
Marten, I am not sure what 2.6.32-6 is (it is a distro kernel?) but the code was changed after 2.6.33-rc4 so could you please test with 2.6.33-rc5 or 2.6.33-rc6. Yes, these are development kernels. Thank you.
Comment 9 Marten Vance 2010-02-02 20:30:32 UTC
Dmitry,

sorry, I did not read your request properly and had been testing with 2.6.32.6.

I tested now with a vanilla 2.6.33-rc6 (no patches) and unfortunately see still the same problem (dmesg coming up).

Is there anything else I can provide?

Thank you for all the work you do!

Marten
Comment 10 Marten Vance 2010-02-02 20:32:23 UTC
Created attachment 24882 [details]
dmesg over suspend/resume cycle with i8042.debug=Y, 2.6.33-rc6
Comment 11 Dmitry Torokhov 2010-02-03 06:00:03 UTC
Created attachment 24889 [details]
Ignore mouse data until reconnect is done.

Marten,

Could you please try this patch and let me know if it fixes your issue. It should apply cleanly to 2.6.33-rc6.

Thank you.
Comment 12 Vojtech Pavlik 2010-02-03 09:14:32 UTC
Note that the "0xaa 0x00" power-up response comes back from the device, the device will not respond to any commands, including the disable command, and they'll just keep timing out.
Comment 13 Vojtech Pavlik 2010-02-03 09:17:14 UTC
Um, I wanted to say "Note that UNTIL the "0xaa 0x00" ...". The reason being that the mouse is performing internal diagnostics, in the case of a touchpad it is calibrating itself, and in general booting. Only after it sends the "0xaa 0x00", it's ready to talk to the OS. The sad part is that we don't know whether it'll send that or not, as it might have been rather fast and could have sent the data while the BIOS was still in control, and then we would have discarded the data at i8042 re-init time.
Comment 14 Dmitry Torokhov 2010-02-03 18:08:37 UTC
(In reply to comment #13)
> Um, I wanted to say "Note that UNTIL the "0xaa 0x00" ...". The reason being
> that the mouse is performing internal diagnostics, in the case of a touchpad it
> is calibrating itself, and in general booting. Only after it sends the "0xaa
> 0x00", it's ready to talk to the OS. The sad part is that we don't know whether
> it'll send that or not, as it might have been rather fast and could have sent
> the data while the BIOS was still in control, and then we would have discarded
> the data at i8042 re-init time.

Yes, that is concern. However if we are unfortunate enough to step onto trackpoint POST the initial reconnect will fail and we will reschedule the full rescan bringing the device back, albeit with default settings.

If the patch works for Marten I think we should apply it and then see if we actually see these breakages. If there are any we could try issuing GET ID a couple of times at the beginning of reconnect routine to make sure device is ready to talk to us. What do you think?
Comment 15 Marten Vance 2010-02-04 08:22:48 UTC
Dmitry, this works! Thank you!

I used 2.6.33-rc6 with your patch and none other.

The last two comments I don't understand. Is there someting else I should test now?

Would you like to see the dmesg-snippet?
Comment 16 Dmitry Torokhov 2010-02-04 17:52:22 UTC
(In reply to comment #15)
> Dmitry, this works! Thank you!
> 
> I used 2.6.33-rc6 with your patch and none other.
> 
> The last two comments I don't understand. Is there someting else I should test
> now?

No, it was a discussion about more potential problems in this area. No action is needed at this time.

> 
> Would you like to see the dmesg-snippet?

No, I am good. May I add "Tested-by: Marten Vance <your e-mail>" to the commit text of the patch?

Thanks.
Comment 17 Marten Vance 2010-02-05 07:52:09 UTC
> May I add "Tested-by: Marten Vance <your e-mail>" to the commit text of the patch?

Is that important to you or the project or the workflow? To me it's not and I'd prefer not to, simply to protect my name and e-mail-address a little more.

Thank you for all the work!

Marten
Comment 18 Dmitry Torokhov 2010-02-05 09:27:33 UTC
No, I do not have to have it, I'll just put a reference to this bugzilla #. Some people are OK with their e-mail in logs, some are not so much, that's why I did ask.
Comment 19 Marten Vance 2010-02-05 22:21:30 UTC
Alright.

Will you mark this bug-report "resolved" or should I?

Thanks again and best wishes!

Marten
Comment 20 Dmitry Torokhov 2010-02-05 22:41:00 UTC
I will when the patch hits upstream (unless I forget ;) ). That you for your help with providing the data and testing different kernels/patches.
Comment 21 Rafael J. Wysocki 2010-02-07 23:02:59 UTC
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=24889
Comment 22 Rafael J. Wysocki 2010-02-14 23:46:32 UTC
Fixed by commit a9f0c381973097462d9688dc26fe66f4f020502e.

Note You need to log in before you can comment on or make changes to this bug.