Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression for Magic Mouse v1: no touch events (incl scroll/middle button) #44

Open
guyzmo opened this issue Jul 31, 2019 · 3 comments
Open

Comments

@guyzmo
Copy link

guyzmo commented Jul 31, 2019

Hello,

there's been a regression with the hid_magicmouse driver, probably related to the merge with the magic trackpad 2 work done, where no touch events are reported to userspace by the kernel.

I have been a happy MM1 user for many years, and a couple of months ago I updated my kernel on Arch (a late update because I've been busy), and I lost scrolling and middle button on my MM1.

I tried pinning down the issue, testing with both evdev and libinput, and after some research, it looks like it's the kernel driver the culprit. The last kernel version the driver was working flawlessly was 5.0.3, and it broke when I updated to 5.1.8.

Here's a summary of all the research:

https://bbs.archlinux.org/viewtopic.php?pid=1850232#p1850232
https://forums.gentoo.org/viewtopic-p-8357120.html#8357120

Until I found a related report has been made on the linux-input mailing list back last december:

https://www.spinics.net/lists/linux-input/msg59094.html

I'm trying locally to bisect and tinker the module's code to find out what's wrong or missing to enable the magic mouse events.

It feels related to #26 though I'm convinced it's not libinput's fault. Looking at my current's kernel code and the source code herein, they're the same…

@guyzmo guyzmo changed the title Regression for Magic Mouse v1: no more scroll or middle button Regression for Magic Mouse v1: no touch events (incl scroll/middle button) Jul 31, 2019
@guyzmo
Copy link
Author

guyzmo commented Jul 31, 2019

After some digging, tickering with the kernel module:

  • I tried former versions of the module (up to this commit, before that hid_register_report has another prototype. And it led to no success.
  • I added log points in the magicmouse_raw_event and no event is emitted on touch

so that confirms there's an issue setting up the mouse.

@guyzmo
Copy link
Author

guyzmo commented Jul 31, 2019

because of the issue, I thought it might be the magicmouse_setup_input method that's faulty, so I tried reverting it up to a version from 2013, and it changed nothing. I tried tickering with the input.keybits as well, trying several combinations, and see if it would enable touch events on the magicmouse_raw_event function… still no luck.

I start to believe that indeed your additions are not responsible for the issue. I'm now 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 😖

Would you have any insights on how I could test/reverse communication with the mouse to try and find out how to get touch events again?

@guyzmo
Copy link
Author

guyzmo commented Jul 31, 2019

(and if you don't mind keeping this issue for tracking progress and research about that issue, so it's simpler than going through forums or mailing lists).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant