apple magicmouse... libinput? evdev? how?

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

I have been a happy gen-1 magic mouse user for a couple years now. All of a sudden I am not.

I recently moved from a 2012 MBP to a 2018 Dell Precision 7730. My magic mouse had "just worked" with Xorg on the MBP, everything including left/right/middle "buttons," touch-horizontal and touch-vertical scrolling, the whole deal. So I took it with me to the Dell.

I am working with a fresh Gentoo install, and for some reason Xorg now wants to drive the magicmouse as though it were a stock 2-button mouse. Only left/right buttons work, no middle or touch-scrolling. I know I never had any unique config for the magicmouse on the MBP, so I don't know why it doesn't "just work" any longer. Googling suggests other recently have had similar issues, but many have at least manually (through xinput manipulation) been able to restore the expected behavior. I cannot.

This is a bummer. I have configured both libinput and evdev drivers in xorg.conf.d, and in each case I can see properties with xinput (evdev example below).

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

FWIW hid_magicmouse is definitely driving the device:

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

In researching libinput I noticed in the file /usr/share/libinput/50-system-apple.quirks

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

I'm interested in the discussion. Posting to subscribe.

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

It's nice to know that I'm not alone :)

I found this:

https://www.kernel.org/doc/Documentation/input/event-codes.txt

So now I know what EV_ABS is sort of. Still don't really know if it's relevant. I tried loading hid_magicmouse with that part commented out of the quirk file, and there was no difference in the driver/device behavior.

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

hid_magicmouse is reporting the params:

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

Rolling back to libinput 1.11.3 and 1.10.7 didn't change anything. So now I'm thinking kernel? I'll try an earlier kernel.

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

I've tried a few kernels. I don't know what's going on, but my BT magicmouse, which up until a couple weeks ago worked perfectly (left/right/middle clicks, v-scroll and h-scroll) on a MBP running 4.18.7, now will only drive like a stock 2-button mouse on my new Dell on that same kernel (or any other earlier or later kernel I try).

Bummer. Judging from Google this seems not to be an isolated incident... I'm wondering now if anyone is able to get their magic mouse to work properly. And if so what xorg, libinput and kernel is being used?

Can anyone get their gen-1 magicmouse to work properly?

rburcham · Apprentice Joined: 20 Mar 2003 Posts: 243

Still no joy, with latest everything. Kernel 4.19.1, libinput-1.12.3, xf86-input-libinput-0.28.1

After BT connecting the device, dmesg:

zmo · n00b Joined: 14 Jun 2019 Posts: 4

hi @rburcham

so you know I'm having the exact same issue, it happened to me as I recently updated my arch install from 5.0.3 to 5.1. I've tried many things but it had no effects. Did you successfully restore scroll and middle click to the mouse?

I'm doing my own research and updates on the other forums, but I thought I should share about it here as well:

https://bbs.archlinux.org/viewtopic.php?pid=1850232#p1850232

Cheers

mobian · n00b Joined: 17 Dec 2004 Posts: 72

@rburcham, @zmo,

Did either of you figure this out? I just hit the same issue and haven't been able to find a resolution...

Thanks.

zmo · n00b Joined: 14 Jun 2019 Posts: 4

Sadly, nope.

With the last update, it did solve the bluetooth disconnection issue, but I still haven't got my middle button and scroll back.

zmo · n00b Joined: 14 Jun 2019 Posts: 4

As a little update, updated to 5.2.4 kernel, and the regression is still there.

I have done some further testing, I tried switching back and forth between libinput and evdev, and setting different options to see if it changed anything and no luck at all.

I tried to listen directly to the

zmo · n00b Joined: 14 Jun 2019 Posts: 4

I have made a report there, and looks like the OP did one as well:

https://github.com/robotrovsky/Linux-Magic-Trackpad-2-Driver/issues/44

it's possible that the merge with Linux Magic Trackpad 2 Driver is not responsible for the regression.

I've tried a bisect process on the kernel module by copy pasting former versions of the file within my 5.2.4 kernel tree, to see if I could get back to a version that worked, but had no luck. I went up to a 2018 version that made a major HID API change so I could not go further back without hacking the module's code.

I tried to add log outputs to the kernel module in several places, and I found out that the method `magicmouse_raw_event` does never get called on touch events, whereas it's supposed to be so.

So I thought it's the setup that's wrong, so I did a bisect on that part of the code, getting back up to a 2013 version of the module, still no luck. `magicmouse_raw_event` still does not gets called.

I'm considering two possibilities for the regression:

- either some change happened outside of the module that changes what shall be setup to start reporting those events ;
- or the mouse firmware or internal settings changed as it connected to macOS (which would be very evil).

I'll try some tests another day, but I already lost like 4/5 hours of work trying to understand this. And I'd appreciate some help/insights, as I'm quite stuck ☺

N.B.: if the owner of the repo is ok with that, I'll keep updating progress on the issue on the github issue, than stay spread between here and the arch forums. This issue is kernel related, not distribution related.