I have tried 3 mice all from different manufacturers and all have exhibited the same behavior within the Gnome desktop environment.

I'm guessing the same would happen if you plugged, used and then unplugged a USB mouse. mutter is the one handling the cursor visibility now.

Which version of gnome-settings-daemon and mutter are you using?

No the same does not happen with a USB mouse.  The cursor does not
disappear.  It only happens with a bluetooth mouse.  When the bluetooth
mouse times out (as they all do), the cursor disappears from the desktop.
Its gone.  Waking the bluetooth mouse does not bring the cursor back. I have to plug in another mouse (USB) to bring the cursor back to
the desktop; at this point I can use the bluetooth mouse again to control
the cursor.  By the way after the bluetooth mouse goes to sleep and you wake
it you can move an invisible cursor around the desktop.  Its aggravating to
have to keep a usb mouse on hand to bring the cursor back.  It sounds like a bluetooth issue to me.  But perhaps it is mutter that cant handle bluetooth mice. If you truly believe this is mutter is it possible for you to send this on to the mutter team?  In the mean time Ubuntu or KDE are looking better than Gnome.

How about answering the questions instead of rambling on about how other desktop environments do this better?

gnome-setting-daemon-3.18.3
mutter-3.18.3

Do you have a touchscreen on your computers as well?

Yes I do have a touchscreen.

OK, it's a mutter bug.

When the Bluetooth mouse disappears, the last used pointing device will be a touchscreen (or could be a touchscreen, given that it's the only pointing device left), and mutter will hide the cursor, because, if you don't have a mouse, you'll be using the touchscreen, right?

The mutter code will need to get a little bit more complicated, and take into account that this device could disappear because it's Bluetooth, and not hide the cursor when the mouse disappears, but when the touchscreen is used next.

We should really avoid behaving the same way for non-Bluetooth devices disappearing, otherwise removing the keyboard dock on devices like the Surface will keep the cursor showing, instead of hiding it straight away.

Created attachment 362293 [details] [review]
fix cursor vanish on bluetooth mouse disconnect

bug #761067 : bluetooth mouse usually goes in sleep state after a
timeout, when that happen the mouse is disconnected and on_device_removed
function is called. Before the patch if a touch device is available the
on_device_removed function hide the cursor. The issue is that the cursor
does not reappear once the bluetooth mouse is reconnected because
MetaBackend::current_device_id is not invalidated when on_device_removed
was called.

The patch set MetaBackend::current_device_id to -1 if the current device
is removed. This will make update_last_device to be triggered as soon as
another input device is used or the bluetooth mouse reconnect, as
consequence that the cursor reappear.

*** Bug 786482 has been marked as a duplicate of this bug. ***

I'm experiencing this too, also on a touch screen laptop (Razer Blade 14) with an Apple Magic Mouse v1 and v2.

Review of attachment 362293 [details] [review]:

The patch looks correct, but could use a couple of improvements. The commit message needs to be fixed; the others see inline comments.

The commit subject should be something like "backend: Unset current device id when current device removed"

The commit message body looks good however, but you should put the complete bugzilla bug URL in the bottom.

Anyhow, this should fix half the bug (that the cursor doesn't come back when the mouse "resumes"). The other half (pointer cursor vanishes when bluetooth mouse vanishes) needs more work. I think the way to solve that part is to fetch the udev device from the removed device, then check the ID_BUS udev property, and only hide the pointer cursor if it was not using bluetooth.

::: src/backends/meta-backend.c
@@ +338,3 @@
       ClutterInputDeviceType device_type;
 
+      /* set unknown current device, trigger update_last_device for any device */

I think the line below is self explanatory, so no need for this comment.

@@ +339,3 @@
 
+      /* set unknown current device, trigger update_last_device for any device */
+      priv->current_device_id = -1;

For clarity, please add some whitespace after this, so that it doesn't "blend into" the variable definitions below. I also think we should set it to just 0, as that is what it is initialized to. The alternative is to also initialize it to -1, so we only ever have one "not set" value.

FWIW there's no devices with id=0. 0 is a safe initialization and unset value.

(In reply to Jonas Ådahl from comment #12)
<snip>
> Anyhow, this should fix half the bug (that the cursor doesn't come back when
> the mouse "resumes"). The other half (pointer cursor vanishes when bluetooth
> mouse vanishes) needs more work. I think the way to solve that part is to
> fetch the udev device from the removed device, then check the ID_BUS udev
> property, and only hide the pointer cursor if it was not using bluetooth.

I don't think it's a bug, but even if we consider it one, this is really not enough to fix this bug. You'd need to know why the device disconnected, which isn't possible without a lot of work in the backends, and a way to get that data back up the stack (was the device unpaired/removed from the system, was it disconnected because of a timeout, did the user turn it off?)

It also doesn't cover other wireless setups, such as Logitech's unifying receivers which remove devices from the system when they're turned off, run out of battery, or timeout. This might also affect a number of devices with single use USB receivers.

(In reply to Bastien Nocera from comment #14)
> (In reply to Jonas Ådahl from comment #12)
> <snip>
> > Anyhow, this should fix half the bug (that the cursor doesn't come back when
> > the mouse "resumes"). The other half (pointer cursor vanishes when bluetooth
> > mouse vanishes) needs more work. I think the way to solve that part is to
> > fetch the udev device from the removed device, then check the ID_BUS udev
> > property, and only hide the pointer cursor if it was not using bluetooth.
> 
> I don't think it's a bug, but even if we consider it one, this is really not
> enough to fix this bug. You'd need to know why the device disconnected,
> which isn't possible without a lot of work in the backends, and a way to get
> that data back up the stack (was the device unpaired/removed from the
> system, was it disconnected because of a timeout, did the user turn it off?)
> 
> It also doesn't cover other wireless setups, such as Logitech's unifying
> receivers which remove devices from the system when they're turned off, run
> out of battery, or timeout. This might also affect a number of devices with
> single use USB receivers.

I more meant that we could simply rely on hiding the cursor whenever the touch screen is used next, but just for bluetooth mice. Of course limiting the lingering pointer to just timeouts would be better, but it seems fairly complicated to get that information. Then again, the cursor will show again when the device comes back so maybe just making that work is good enough.

Created attachment 363100 [details] [review]
backend: Reset current device id when current device removed

bug #761067 : bluetooth mouse usually goes in sleep state after a
timeout, when that happen the mouse is disconnected and on_device_removed
function is called. Before the patch if a touch device is available the
on_device_removed function hide the cursor. The issue is that the cursor
does not reappear once the bluetooth mouse is reconnected because
MetaBackend::current_device_id is not invalidated when on_device_removed
was called.

The patch set MetaBackend::current_device_id to 0 if the current device
is removed. This will make update_last_device to be triggered as soon as
another input device is used or the bluetooth mouse reconnect, as
consequence that the cursor reappear. The id 0 is never given to devices
and can safely used as undefine id.

Comment on attachment 362293 [details] [review]
fix cursor vanish on bluetooth mouse disconnect

Hello,

I updated the patch following reviews.

For the second half of issue, I'm personally fine with the fact that the cursor disappear when a device is removed, he can disappear for many other reasons anyway: movie player, touch screen or while typing. It is just annoying that it does not reappear. In my case, at first place I thought that my bluetooth mouse was broken and was not able to connect/reconnect until I figured out that UI elements reacted to bluetooth mouse's move.

Best regards.

Pushed after fixing the commit message body and removing the comment (if we comment every obvious line it'll go out of hand quickly). Thanks!

Attachment 363100 [details] pushed as 3ee1999 - backend: Reset current device id when current device removed

Backported to gnome-3-26