Scrolling non-functional after suspend/resume on a USB keyboard

[lentinj]

@rcj4747 says: I had problems with you kernel patch. After a suspend/resume cycle the scrolling did not work until I disconnected and re-connected the USB keyboard. Have you seen/heard of this happening with the patches?

[lentinj]

That seems plausible, I don't think this is something I've tested. The Bluetooth keyboard reconnects completely afresh after suspend/resume, and this is what I use ~99% of the time. What sort of suspend is this? To-RAM or Hibernate?

Does running the following fix things up:

tp-compact-keyboard --native-mouse-enable

[rcj4747]

That did not resolve the problem. Also, to find the device I did have to change the HID_NAME to:
HID_NAME="Lenovo ThinkPad Compact USB Keyboard with TrackPoint"

[lentinj]

@rcj4747 sorry, that was stupid of me. The USB keyboard needs the commands sent via. an ioctl, so that bash script can't do it. I do have a hacked-up C utility I don't think I've shared yet, will commit that this evening which should hopefully make life more bearable.

Does ls -1 /sys/bus/hid/devices/000*\:17EF\:*/fn_lock still find anything whilst scrolling isn't available? (i.e. is the hid-lenovo driver still bound)?

[rcj4747]

Yes, the fn_lock file is there in both cases (prior to suspend with scroll working and after suspend/resume with scroll non-functional).

[lentinj]

Try https://github.com/lentinj/tp-compact-keyboard/tree/master/tp-compact-usb-keyboard --- it should help you work around this for now.

But the kernel patch to fix this properly should be easy, would you be willing to test patches?

[rcj4747]

I ran against the correct device but scrolling did not work.

$ ls /sys/bus/hid/devices/0003\:17EF\:6047.000*/fn_lock
/sys/bus/hid/devices/0003:17EF:6047.000A/fn_lock

$ ls /sys/bus/hid/devices/0003\:17EF\:6047.000A/
country            hidraw/            power/             subsystem/         
driver/            input/             report_descriptor  uevent             
fn_lock            modalias           sensitivity        

$ ls /sys/bus/hid/devices/0003\:17EF\:6047.000A/hidraw/
hidraw2

$ sudo ./tp-compact-usb-keyboard /dev/hidraw2 
Sent command 01 03
Sent command 02 01
Sent command 05 01

[rcj4747]

Also, I can test kernel patches, I'm happy to compile a test kernel when we get to that point.

[lentinj]

Okay, can you try tp-compact-usb-keyboard again?

Regardless, I'm willing to bet that the following patch will fix things for you:

lentinj/linux@9c1c8ba

I'm not going to get around to testing this for the next few days, but if you can try yourself and report back that'd be really useful.

[rcj4747]

I tried suspend/resume fix with tp-compact-keyboard @ 0358baf and that worked. I'll test the kernel patch and leave a comment when I have that tested. Thank you.

[rcj4747]

@lentinj I tried the kernel patch on a 4.3 mainline kernel and with the keyboard plugged in during resume the system hangs hard; I don't even get to video. I'm not versed in pm debugging but if there's something you'd like me to do to debug I certainly can do it; I've done a fair bit of kernel development.

[lentinj]

Hrm, PM debugging seems to be quite a tricky business.

hid-rmi.c does pretty much the same to handle resume, so seems unlikely that the USB device isn't ready for the commands to be sent at this point (although there's no guarantees that this driver is bug-free). Just to be sure, suspend/resume works okay with the patch applied but the keyboard disconnected?

Clutching at straws now, but you could remove lenovo_resume and see if that helps. If I've read the USB suspend docs correctly it's not strictly required.

[rcj4747]

Removing lenovo_resume didn't alleviate the hang. I tried keeping lenovo_resume and removing lenovo_reset_resume and that eliminates the hang (yea!) but we're back to a trackpoint without scroll after resume.

[rcj4747]

Have a look at rcj4747/linux@f89eb059, this commit will eliminate the hang on resume and restore middle mouse scrolling. Stylistically I'm not sure it's 100%.

[lentinj]

Interesting! Problem is it won't restore fn-lock / sensitivity status, which could be just as annoying to some. Do the sensitivity / fn_lock /sys nodes still work after a resume?

I'm going to try and get suspend/resume working in QEMU so this is slightly easier to debug.

[arnuschky]

I have the same problem. Usb keyboard, middle mousebutton is gone after suspend. If I understand correctly it has been fixed in rcj4747/linux@f89eb05, or has this been integrated anywhere by now?

I guess the only way for me to test this is to pull the sources, patch them, and compile that module. Is that correct?

[rcj4747]

@arnuschky Review the comment from @lentinj on 4 Nov, 2015 which outlines what won't work with the patch of mine. With the code in the kernel today it would work to detach and re-attach the keyboard after resume. I found that to be an acceptable inconvenience as the keyboard has a very accessible mini-USB connection. Separately, and completely unrelated, I bought a new keyboard to improve ergonomics and I don't know what the state of support is today.

[arnuschky]

Thanks for your reply. Yes, the detach-reattach workaround is what I am doing as well. :)

I'll have a look at your patch; maybe I can fix the issues raised by @lentinj

[lentinj]

I never managed to reproduce this meself, neither in a VM or on my laptop (which presumably keeps USB devices powered over suspend).

Probably worth taking the conversation to [email protected] to see if anything is suggested (please CC me if you do, I don't subscribe).

[white-gecko]

I can confirm, that this issue exists. I have a USB Keboard and it is connected to the USB Port of the Dockingstation. But the occurrence of the phenomenon is not reliably happening every time. Sometimes I undock the laptop, so I can't say if it only happens after suspend, undock and redock or if it also happens on suspend and resume, while the laptop is docked. Am 29. November 2016 10:13:04 MEZ, schrieb Jamie Lentin <[email protected]>:

…

I never managed to reproduce this meself, neither in a VM or on my laptop (which presumably keeps USB devices powered over suspend). Probably worth taking the conversation to ***@***.***`` to see if anything is suggested (please CC me if you do, I don't subscribe). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #28 (comment)

-- Diese Nachricht wurde von meinem Mobiltelefon mit Linux Kernel und JVM Userland von K-9 Mail gesendet.

[lentinj]

Hrm, I didn't think of the dock. The dock for my X230 definitely keeps the USB ports powered whilst the laptop is suspended, then powers off on undock. I would have tried the keyboard on my X201s, but I imagine it's the same.

[white-gecko]

I think it shouldn't depend on, which laptop you are using, since it is the driver for the Thinkpad-USB-Keyboards.

[arnuschky]

I am seeing this also with the dock. Keyboard connected to Mini Dock 3, with a x230 as well. I think I can reproduce it every time I suspend while in the dock.

[anoxi]

I can still reproduce this on Ubuntu 17.04. / Kernel 4.10., any solution here?

[saveman71]

A software solution I've found is to reload the module usbhid.

sudo rmmod --force usbhid ; sleep 1; sudo modprobe usbhid

Maybe putting this in a udev rule linked to the resume could fix it (I know I did something similar for a sound problem (reloading kernel module on resume) on an Asus laptop).

Any of you guys have some more insight since?

[anoxi]

@saveman71: Thanks, this seems to work on Ubuntu 18.10..
I created the file /lib/systemd/system-sleep/tp-compact-keyboard, made it executable and added the following code, so it runs after resume:

#!bin/bash
if [ "${1}" == "post" ]; then
 rmmod --force usbhid; sleep 1; modprobe usbhid
fi

[saveman71]

Just be aware that this will "break" your keyboard after a kernel update, since it'll fail reloading the module :/ Maybe there is a way to "simulate" the unplugging/plugging of the kb?

[saveman71]

To anyone reading this, i found a way to softreset the usb port of the keyboard.

https://askubuntu.com/a/61165/275102

The first answer, with the C program (USBDEVFS_RESET ioctl method) didn't seem to work. However, the second answer (linked above) with the "authorized" method did work for me. I'm no expert so I didn't look up exactly the meaning, but it works.

sudo sh -c "echo 0 > /sys/bus/usb/devices/1-4.2/authorized" &&
sudo sh -c "echo 1 > /sys/bus/usb/devices/1-4.2/authorized"

Quoting the instructions to find you device path:

Yours obviously wouldn't be 1-4.6 but you can either pull that device path from your kernel log (dmesg) or you can use something like lsusb to get the vendor and product IDs and then use a quick command like this to list how the paths relate to different vendor/product ID pairs:

for X in /sys/bus/usb/devices/*; do
echo "$X"
cat "$X/idVendor" 2>/dev/null
cat "$X/idProduct" 2>/dev/null
echo
done

[white-gecko]

I just had the issue again. And tried your trick.

With the loop I found the device, I also added cat "$X/product" 2>/dev/null to get the human readable name, which is "ThinkPad Compact USB Keyboard with TrackPoint" in this case.

for X in /sys/bus/usb/devices/*; do
echo "$X"
cat "$X/idVendor" 2>/dev/null
cat "$X/idProduct" 2>/dev/null
cat "$X/product" 2>/dev/null
echo
done

However, I had:

/sys/bus/usb/devices/5-4
17ef
6047
ThinkPad Compact USB Keyboard with TrackPoint
/sys/bus/usb/devices/5-4:1.0
/sys/bus/usb/devices/5-4:1.1

and first did:

sudo sh -c "echo 0 > /sys/bus/usb/devices/5-4:1.0/authorized" &&
sudo sh -c "echo 1 > /sys/bus/usb/devices/5-4:1.0/authorized"

which made the keyboard not working anymore, so I had to proceed with the laptop keyboard.

The I did:

sudo sh -c "echo 0 > /sys/bus/usb/devices/5-4:1.1/authorized" &&
sudo sh -c "echo 1 > /sys/bus/usb/devices/5-4:1.1/authorized"

which made the trackpoint completely stop working.

Finally:

sudo sh -c "echo 0 > /sys/bus/usb/devices/5-4/authorized" &&
sudo sh -c "echo 1 > /sys/bus/usb/devices/5-4/authorized" 

broad everything back to live and even scrolling works now.

[lentinj]

I finally got around to finding hardware that reproduces this. There is a patch for the kernel to sort this out here if anyone wants to try:

lentinj/linux@f1c4e2d

However, I'm experiencing occasional timeouts when any property is set (e.g. turning on/off fn_lock). It's unrelated to the above, and could just be my ropey USB keyboard and/or cable. However, the above turns it from a benign problem to something that causes resume delays / failures.

If others are suffering from similar (setting fn_lock / sensitivity taking ages then resulting in a -110 error in dmesg) with USB keyboards that would be interesting to know.