USB: no movement after suspend-resume cycle

[dos1]

(it probably should get reported to kernel's bugzilla too at this point, but let's do it here first)

When Magic Trackpad 2 is connected via USB, it stops responding after a suspend/resume cycle. Only left button clicking works. I suspect that the multitouch capability needs to be enabled again at this point, but currently the driver does nothing on resume.

[makslevental]

i get similar behavior: wired (usb) works on login screen and then once i login (my desktop manager shows up) i get only left and right click (no motion).

[wolftune]

Maybe relevant: I've found temporary solution for similar case myself at https://www.reddit.com/r/Ubuntu/comments/ahgbdg/apple_magic_trackpad_2_configuration_on_kubuntu/ in terms of the movement problems being related to the pressure settings. I have to use that process to get xinput set-prop to the right details. But since using the Magic Trackpad, suspend and resume can even crash my whole machine and otherwise the settings I want are not persisting correctly.

Note: I'm on KDE Neon with hwe kernel 4.18 + dkms of this driver

I should experiment with bluetooth too, but I've had issues there; overall much less reliable than USB during actual use.

Update: I tried kernel 5.1.15 and still had the no-movement-after-resume problem. I was able to get it back by simply doing on-off on the trackpad switch.

Perhaps the answer involves getting the latest libinput as well (I removed synaptics and found that libinput overall does better). See these recent patches for libinput: https://gitlab.freedesktop.org/libinput/libinput/merge_requests/214

[dos1]

These patches are mine and are unrelated ;)

With out-of-date stack you can get "movement problems" related to libinput's interpretation of pressure values, but that's not what's reported here - after a suspend/resume cycle the values stop coming from the kernel altogether when connected via USB.

[wolftune]

@dos1 thanks for clarifying, that's disappointing because I have the same problem you reported here and was hoping maybe those patches would help. So, I guess not. This suspend-resume problem remains outstanding.

[mistertwo]

Picked up a MT2 recently, and am running into the same issue over USB. I've tried sending a USBDEVFS_RESET ioctl call to the device to see what would happen (I've seen it as a way to reset USB devices without the physical disconnect/reconnect), and instead of bringing the device back, I'm able to recreate the non-moving cursor without setting the computer to sleep and waking it back up.

Checked to see if there was anything funky in the /dev/bus/usb/* directory for the trackpad, but nothing stood out before or after sending USBDEVFS_RESET, or after doing a physical disconnect and reconnect to bring it back.

Once I find some time, I'll do a bit more digging and see if I can find out what's going on (or not) after the reset.

[dos1]

Just a thought: I believe it's more likely that it's a matter of what the device itself sends to the computer rather than some internal state of the driver. Driver is configuring the trackpad on init to enable various features, like multitouch reporting, so this would be my main suspect there.

[mistertwo]

I've dug around a bit last night on ways to trigger the init call within X/xinput, but didn't come up with much. If you (or anyone else reading) happens to have something on how to do that, let me know.

I did notice that mtrack was throwing some stuff into the Xorg log to declare when the device was initialized, turned on, off, etc.

Do you happen to have anything that would point me in a proper direction to see what X may or may not be doing upon wake? I'm wondering if triggering a disconnect/init within X may help.

[dos1]

Do you have any particular reason to suspect X there? I'd have to recheck to be sure, but as far as I remember the events were ceasing to flow at the kernel level already - I'd definitely start by digging in the kernel driver there.

[mistertwo]

I don't have a reason to suspect X at the moment. I was poking to see if there's another way to restart the connection without physically reconnecting via USB.

So after going for a dig in hid_magicmouse (controls the trackpad as well), it looks like there's a probe function that gets called when the device is plugged in, but there's no suspend or resume calls, which from what I've read so far should mean that those aren't being called at all, and we're leaving the trackpad alone upon suspend.

After scanning the code a bit more, I've noticed that there's a place where there's some MT2 specific processing being done here: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-magicmouse.c#L399

We know the mouse clicks work, so maybe there's something that's not lining up with the calls to input_mt_sync_frame just above the call to input_report_key. I'll check back up on this once I've had some rest.

[mwyborski]

@mistertwo and @dos1 I haven't checked the suspend/resume. But you are right, that during initialization there is sent a USB message to the MT2, which puts it into multi-touch mode. Without multi-touch mode only one touch is recognized and e.g. 2-finger for right-click won't work. So this is problably the issue and the initialization should be called after resume. Also there is no problem, if by circumstances the switch to multi-finger-mode is called several times, so i think the fix should be easy. But right now i don't have the time to dig into this.

[mwyborski]

I might give it a shot sometime in november, but if someone of you want to patch it please go for it. Just tell me, so that we are not doing the same work.

[wolftune]

To clarify my reproduction of this: upon resume, my MT2 can click and can move the cursor when I use significant pressure (sort of like a click+drag). But normal cursor movement doesn't go. I simply toggle the physical on/off switch and everything then gets set correctly. So, I'm just in the habit of doing that toggle as a part of the resume routine.

It would be nice to have it fixed though.

[mistertwo]

@robotrovsky I'll give this a shot tonight, and let y'all know how things go.

[mwyborski]

@mistertwo great! I think this was the switch to multi-touch:

	else if (id->product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
		if (id->vendor == BT_VENDOR_ID_APPLE)
			report = hid_register_report(hdev, HID_INPUT_REPORT,
				TRACKPAD2_BT_REPORT_ID, 0);
		else /* USB_VENDOR_ID_APPLE */
			report = hid_register_report(hdev, HID_INPUT_REPORT,
				TRACKPAD2_USB_REPORT_ID, 0);
	} else { /* USB_DEVICE_ID_APPLE_MAGICTRACKPAD */

[mistertwo]

Alright, gave this a shot. I've got a lot to learn... :)

Anyways, basics. Wrote a couple of functions that should trigger on suspend and resume:

static int magicmouse_hdev_resume(struct hid_device *hdev)

{
        hid_err(hdev, "magicmouse coming up.\n");
//      hid_err(hdev, "magicmouse id:\n");
//      if (hdev->product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
//              hid_err(hdev, "we have a device match!!!");
//      }
        printk(KERN_CRIT "magicmouse coming up.");
        return 0;
}

static int magicmouse_hdev_suspend(struct hid_device *hdev, struct pm_message bbq)
{
        hid_err(hdev, "magicmouse going down.\n");
        printk(KERN_CRIT "magicmouse going down.");
        if (hdev->product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
                hid_err(hdev, "we have a device match!!!");
        }

        return 0;
}


static struct hid_driver magicmouse_driver = {
        .name = "magicmouse",
        .id_table = magic_mice,
        .probe = magicmouse_probe,
        .raw_event = magicmouse_raw_event,
        .input_mapping = magicmouse_input_mapping,
        .input_configured = magicmouse_input_configured,
        .resume = magicmouse_hdev_resume,
        .suspend = magicmouse_hdev_suspend,
};

At this moment, the suspend function is being called without hassle. Oddly enough, it shows up when resume should be called (after waking the machine) in dmesg. I get nothing at all from the resume function in dmesg.

With regards to the if test in the suspend function, it's not going to be there in the end, as there would be no reason to check on this during suspend. Since that is the call that's "working" at the moment, I'll move forward on that while sorting out suspend not working or appearing to be called. If anyone has any insight on what I'm not doing right there, let me know.