-
Notifications
You must be signed in to change notification settings - Fork 86
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
4.18.12: gen-1 magicmouse acts only as 2-button mouse #26
Comments
@rburcham , sorry to hear, that this somehow broke your working device. How did you install the new driver? Can you give me a link to the package? The kernel 4.18 does not come with this driver (neither 4.19, but 4.20), so either you have it installed manually, or this is not a driver related issue. And how did you connect? Via bluetooth or USB? Do you have the same effect, independent of the interface? I think to track this down, you should try 3 things:
|
Thanks for the reply @robotrovsky. I am on gentoo, running a gentoo curated kernel 4.18.12 from the gentoo-sources package in portage. I agree the new version of the driver likely is not in there:
Further, hid_magicmouse is reporting the params:
As you say, I have to think I'm looking at the impact of some kind of change in libinput. Perhaps a quirk change or a wholesale change in behavior. I admit I don't know what version I was running on my original gentoo'd MBP 2012 where the magic mouse behaved flawlessly. Since gentooing this Dell Precision 7330 I can see from emerge.log that within the past two weeks I have updated from
I'll see if I can roll back the libinput. |
You are welcome @rburcham. I think as well, that this is a libinput and no driver issue, so i will close this issue. Good luck ;-) |
Sorry to bump this item @robotrovsky , but could you help me interpret this dmesg output when the hid_magicmouse discovers and drives the device:
Specifically what does the "unknown main item tag" mean? And is the input,hidraw4 correct for a gen-1 magic mouse? Is anyone able to actually drive their gen-1 magicmouse properly these days? It really seems like there are a lot of folks making the same observations I'm making. |
@rburcham i am sorry, but i cannot help you with your questions. I think the best might be, if you ask your questions on the linux-input mailinglist: linux-input@vger.kernel.org |
@rburcham did you end up solving your issue? I opened a new issue ☝️ to track research and progress on the issue to maybe get to a solution, given @robotrovsky is ok with that. |
Never did. I did get a response on linux-input pointing the finger at the kernel module: https://gitlab.freedesktop.org/libinput/libinput/issues/200#note_95204 But no joy. Honestly I do feel that the commit (redesign) referenced in that thread must have something to do with the issue. It's possible something was lost in translation, or maybe Peter didn't look closely enough, as the change referenced dealt with MT in the magicmouse kernel module which is essentially the problem. I bought an MS arc mouse and have been using it ever since. |
I've documented details of my observations here: https://forums.gentoo.org/viewtopic-t-1089352.html
In essence I cannot get the gen-1 magicmouse to middle click or v-scroll or h-scroll.
The hid_magicmouse module discovers and drives the device according to dmesg. Running xinput with list, list-props and set-props all act as you would expect, but the device never behaves differently, that is enabling the middle button or scroll wheel props is successful, but the device continues to behave as a 2-button mouse. Running evtest never shows any middle click or h-scroll or v-scroll activity.
This device used to operate properly but I'm unsure what's different about the driver now.
I noticed in the file /usr/share/libinput/50-system-apple.quirks
I don't know how to interpret the comment... What does ABS mean?
EDIT-
I found this link https://www.kernel.org/doc/Documentation/input/event-codes.txt so now I kind of know what EV_ABS means... I still don't understand if it is relevant though. If I comment that out of the quirk file there is no change in the driver/device behavior.
The text was updated successfully, but these errors were encountered: