Scrolling doesn't work AFTER mouse is disconnected and reconnected

[hagaram]

Hi, first of all, that you very much for this project!

I've ran into an issue, that when the mouse is re-connected after it disconnects itself (which is a known issue it seems) and /opt/magic-mouse-fix/magic-mouse-2-add.sh is supposed to kick in, it didn't work as expected. Mouse got reconnected, but scrolling didn't work,. What worked was executing rmmod and modprobe of magic mouse module. I haven't yet found out why the original script didn't do what it is supposed to, but the modified script below seems to work so far.

I'm writing this for anyone with simillar issue as mine

System Info OS: Arch Linux Kernel: x86_64 Linux 5.9.11-arch2-1

#!/bin/sh

FILE=/tmp/magicmouse-driveload

reload() {
    if [ ! -f "$FILE" ]; then
        touch $FILE

    rmmod hid_magicmouse
        sleep 2
    modprobe hid_magicmouse
        sleep 2
        rm -f "$FILE"
    fi
}

reload &

[akozyreva]

Hi @hagaram ! I implemented your fix on Manjaro GNOME. I'd like to say, that mouse works quite better now, but after ~8 hours disconnect happens and scrolling stops working. Did you have the same issue?

[JoshMock]

@hagaram I'm having the same issue on Arch. Kernel is x86_64 5.10.10-arch1-1.

I've just been running effectively the same thing manually every time I reconnect my mouse. Your solution's a little cleaner. Are you automatically running it via systemd on wake or just manually when needed?

[RicardoEPRodrigues]

Hello!

Unfortunately, I do not use Arch. In my last commit, I made some changes to make better use of modprobe. Can you please try it out?

If you want to change parameters you can now go to /etc/modprobe.d/hid-magicmouse.conf.

[akozyreva]

Hi @RicardoEPRodrigues . I installed your update. It's better, than it was before, but connect is lost after ~ 8 hours and scrolling is not working after re-connection. Is it possible to somehow return scrolling and not to restart computer (because when I run install.sh, changes apply only after restart, that means I do it almost every day)?

[RicardoEPRodrigues]

I have not found a solution to the restarting being mandatory. For now, I need to restart the computer each time I update the drive.

Have you tried running the load script sudo scripts/magic-mouse-2-add.sh after connecting the mouse and see if the scroll works?

[akozyreva]

@RicardoEPRodrigues yes, it takes effect, thanks! But you have no issues with disappear of scrolling, haven't you?

[RicardoEPRodrigues]

I can't really say as I don't use the mouse that regularly. So perhaps I have the issue, I just don't know of it.

[hagaram]

@akozyreva Hi, sorry for the late response, I need to look into it more as I yet have to find proper permanent fix for scrolling issue. Unfortunately I have really little time on my hands.

I'm still running into the same issue, scrolling still gets lost...

My (and I must say shitty workaround) is to have mouse-reset.Desktop shortcut pinned in panel/taskbar (whatever you call it). If I lose connection, mouse gets reconnected and scrolling isn't working - I just click the icon/shortcut.

In the Exec part of Desktop file I have sudo rmmod hid_magicmouse; sudo modprobe hid_magicmouse. I allowed my user to run these commands with sudo without inserting password in sudoers.

My connection gets lost once or twice a day, so it is bearable.

They are the same commands the script (https://github.com/RicardoEPRodrigues/magicmouse-hid/issues/7#issue-762186360) should run and runs, but something isn't working as it should.

[RicardoEPRodrigues]

@hagaram I am running Ubuntu with kernel 5.8, so I guess it might be an issue related to changes made in kernel 5.9, although I can not say.

You might want to take a look at the UDEV rule that is calling the script. Try to see if it is being called or not (I don't remember exactly how you do it thou).

I made some recent changes to the code, so it might help to uninstall the previous versions and try it out from the latest release, but I don't think the problem will be solved.

[RicardoEPRodrigues]

Some reports seem to suggest this is, in fact, a kernel problem: https://bbs.archlinux.org/viewtopic.php?id=259954

Can you confirm you have the same or similar issues?

[JoshMock]

Since Arch uses rolling upgrades, I'm now on 5.10. I also pulled the latest changes from this repo and reinstalled them around the same time. One or both of those seems to have patched this up for me. Not a very scientific data point, but at least things seem better now. :slightly_smiling_face:

[hagaram]

I've updated to kernel 5.11.1, applied changes from this repo - so we will see. Meanwhile I'll monitor udev rules.

[RicardoEPRodrigues]

Thank you both for your time. Let me know how it goes and let's hope it was a Kernel bug. 😊

[hagaram]

Today, I had more disconnects than avg (+2), which might be completely unrelated to changes you made, or changes made in the kernel.

BUT the good news is, that it seems, than scroll works correctly after disconnect-reconnect. I would't close this issue just yet, as I would give it few more days of testing - I use the mouse daily.

If you are interested I can provide udev logs, maybe it will come in handy in the future.

[RicardoEPRodrigues]

Great news. If you can share a pastebin link for the logs it would be nice, just to see what we are working with.

Also, supposedly the install script disables something in Bluetooth that should fix the disconnecting issue. Perhaps the current solution doesn't work on Arch, but you should google it.

https://github.com/RicardoEPRodrigues/magicmouse-hid/blob/206d565924732b7d4bd358d8794d006ed40f672d/install.sh#L33-L37

[hagaram]

I've had esco mode already disabled prior to any changes and updates as per your documentation, so disconnects are perhaps caused by something else in my case - don't worry about it :)

In the logs you will find several reconnect events: https://pastebin.com/JkgYVu6u

I'll read through the logs myself, as I may find some clues there.

[johnchen902]

My current uname -r is 5.11.8-arch1-1. If the module is loaded after the mouse connects, it receives events of size 14, 22, 30, etc. However, if the module is loaded before the mouse connect, it receives events of size 8.

---

Add this line to magicmouse_raw_event:

printk(KERN_INFO "magicmouse_raw_event size=%d data[0]=%d\n", size, (int) data[0]);

If the module is loaded after the mouse connects:

magicmouse_raw_event size=22 data[0]=18
magicmouse_raw_event size=14 data[0]=18

If the module is loaded before the mouse connects:

magicmouse_raw_event size=8 data[0]=18

[johnchen902]

If the module is loaded before the mouse connects, it appears that hid_hw_raw_request did return -EIO.

[johnchen902]

It's HIDP_HSHK_ERR_INVALID_REPORT_ID. Since the mouse did not switch into multitouch mode, we can't put a blind eye on it.

[johnchen902]

Adding msleep(500) seems to resolve the problem. I don't know if this is a device quirk or a driver bug, though.

static int hid_magicmuose2_enable_multitouch(struct hid_device *hdev)
{
    u8 data[] = { 0xF1, 0x02, 0x01 };
    return hid_hw_raw_request(hdev, data[0], data, sizeof(data),
            HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
}

static int hid_magicmouse2_probe(struct hid_device *hdev,
                 const struct hid_device_id *id)
{
    // ...
    ret = hid_magicmuose2_enable_multitouch(hdev);
    if (ret < 0) {
        msleep(500);  // device quirk?

        ret = hid_magicmuose2_enable_multitouch(hdev);
        if (ret < 0)
            return ret;
    }
    // ...
}

[RicardoEPRodrigues]

I think it isn't code-breaking. Can you do a Pull Request and I'll test it out?

[johnchen902]

Stuff's here: https://github.com/johnchen902/linux/commit/cb700d058a4c627f18c936cddff30f73e4f666ef

I'm too lazy to rebase it onto your tree.

[RicardoEPRodrigues]

@johnchen902 I applied your changes to this codebase. Thank you for your work! 👍

Additionally, I added a new feature - disable scrolling while moving the mouse. All of these features should go into libinput, but I don't have the time and knowledge to do so.