Fedora 39 - Bluetooth - Apple Magic Mouse keeps disconnecting and no scrolling

Hello everyone,

I am trying to get my apple magic mouse fully working with Fedora 39. Some time ago (break of more than 9 months) it was working all fine. It stayed connected all the time, scrolling worked and no further issues. 2 weeks ago, when I started using my laptop again, I first updated everything and connected the mouse. Now, nothing works as expected. To be specific,

  1. it always disconnects itself after some time,
  2. whenever it was disconnected once the scrolling function does not work anymore.

Could you please help me out?

Any help is very much appreciated!

I have the same problem with a Magic Mouse on Fedora 39. It’s pretty annoying. Every time the screen saver lock screen kicks in, the mouse seems to disconnect, and when it reconnects scrolling is broken. Unfortunately I don’t have an answer other than to manually disconnect and reconnect in the Bluetooth settings.

Unrelated to this, I found the default scrolling terribly slow with no obvious setting and the middle “button” because frustrating with constant accidental pasting. I came across a post with this to fix both of these:

sudo grubby --update-kernel=ALL --args=“hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40”

1 Like

It is good to hear that I am not the only one facing this issue. However, pretty annoying not having a fix for this. If I, for any reason, find a fix I will post it here and let you know.

Thank you for the scrolling speed fix!!

[reported here: Magic mouse not working properly after suspend - #2 by dr-prodigy too]
Hi, I have a very similar issue: suddenly (ie: after a very recent update) my Magic Trackpad integration got broken, in that the pointer stops being moved by the trackpad after a desktop suspension: click remains the only working thing… pretty useless.
Not even Bluetooth disconnect → connect does any good: only rebooting fixes (until next suspension).
Very annoying.

Apple Mac, Fedora 39, Linux 6.8.6-200.fc39.x86_64, Gnome 45.5, Wayland

Instead of rebooting I do sudo service bluetooth restart and then the device functions normally for a very short time before everything happens again…

Hey @ejoin7937 that’s a very good point… of course the issue is still there (and still, it’s very annoying), but it’s a good workaround. Thank you very much! :+1:

PS: I really hope this gets fixed soon… when I migrated my old iMac to Fedora I had to struggle a lot to make the bluetooth work (basically I had to remove it from low power consumption-enabled devices, otherwise it was disconnecting randomly), and now I’m at it again :face_with_symbols_over_mouth:

I fully agree! Hopefully, Fedora 40 will solve this issue! Are you using gnome-power-management or tlp? I`ve heard that many times it is the power saving issue and that using tlp instead of the gnome-power-management would help!

I double-checked and need to amend: at the time I in fact tried a number of tweaks to bluetooth power management but I had no success… so I finally made it like so:

sudo systemctl stop upower
sudo systemctl disable upower
sudo systemctl mask upower

(note: masking is important, otherwise upower gets enabled again by the OS)

Of course this “solution” would probably be less viable on a laptop, but I found it acceptable for my iMac desktop use.

PS: I found this apparently better solution today:

but, while it could solve my original disconnection issue, I cannot test it now due to the current issue which would most probably shadow the fix anyway :weary:

Your mouse battery may be failing. I worked in a cubicle farm with many Apple workstations and users often absent at sea for 2-week stints. The Magic Mice were high maintenance due to battery issues and workstations connecting to the mouse in an adjacent cubicle (user A had “borrowed” user B’s mouse while charging their own mouse?).

You can use bluetoothctl in a terminal.

To see battery capacity, use cat /sys/class/power_supply/hid-<HID>-battery/capacity where the HID can be obtained using the scan function of bluetoothctl.

I am sure the problem is not the mouse battery. Checked the battery level when connected to a different device and also changed them already. But anyways thanks for reminding me!

Unfortunately, the command does not work as expected. bash tells me no file or path was found. Do you have any clues?

You appear to have the original 2009 model mouse with AA batteries. It is possible that the current linux driver was developed and tested with the newer (2015) model mouse.

One of the drivers that was used to develop the kernel.org version was: RicardoEPRodrigues Magic Mouse github says:

This repository contains the linux hid-magicmouse driver with Magic Trackpad 2 and Magic Mouse 2 support for Linux 4.18 onwards. For older kernels you might have to diff and backport. It also contains 2 fixes to the Magic Mouse 2 regarding Bluetooth random disconnections and this driver not loading on bluetooth reconnection.

This is correct. So, does this mean that the Linux kernel actually has certain drivers for the Magic Mouse 2?

It is interesting, as various other people report the same issues I am having and I suspect not everyone of them uses the old variant. Furthermore, it was working properly for a good amount of time!

@gnwiii :
same as for @ejoin7937 here: my Magic Trackpad is the first version from 2009, ie: with AA batteries, which I always replace when required, so I definitely exclude any issue there.

Going further, I honestly have no clue where the relevant kernel driver comes from, but:

  • out of the aforementioned power management issues - which were there since I started with Fedora (late 2023) and, as stated, I could fix disabling upower - my trackpad used to work perfectly up to a couple of weeks ago
  • kernel v4.18 you mention is very old compared to the current version (v6.8.6), so I honestly can’t see any relationship between that magicmouse-hid library and the issue I’ve reported, which instead is clearly a very recent regression.

Linux does often have problems with support for hardware over a decade old (and Fedora is often the first place they appear because it is an early adopter of new kernels). Few developers would have access to the hardware, so it is left to users to discover problems and then a question of whether anyone with the necessary expertise and has the time is willing to work on the problem.

A detailed bug report can be useful, even if it only serves to alert others with similar issues to the diagnostic messages that will let them verify that their issue hais the same.

Mice are easily replaceable while detailed bug reports require some effort. I generally just replace cheap hardware over that is a decade old when problems appear.

1 Like

Even the most expensive mouse/trackball for intel is currently about $60 or less. I don’t know about apple devices though.

@gnwiii
I don’t want to be rude… I honestly didn’t feel the need for software lifecycle explanation, but thank you anyway.
As I’ve already stated, I am referring to a regression originated by a very recent update, so it looks meaningful to me to report it as I’m doing, because it could most probably impact devices other than mine (as we see, Magic Mouse is another one, and others could be in the list), even not necessarily very old.

Finally, if you feel like Apple Magic Trackpad is cheap hardware, I can send you my address and you can send me the newest, surely supported, version! :joy:

Unfortunately, reporting problems here is only the first step.
If you do not also file a bug report at bugzilla.redhat.com then the developers are not informed of the problem and your issue is not likely to be fixed. Developers do not use this forum as their main means of problem reports for what may be bugs.

Please try with FEDORA-2024-184c7a59f8 — bugfix update for bluez — Fedora Updates System . I’ve only just created it so downloading it according to the instructions there may not work, you can get the packages directly from bluez-5.75-1.fc39 | Build Info | koji .

1 Like