After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 650604 - Hide mouse pointer if no mice
Hide mouse pointer if no mice
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: mouse
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2011-05-19 16:07 UTC by Bastien Nocera
Modified: 2011-11-11 09:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2011-05-19 16:07:00 UTC
If we don't have a mouse, touchpad, or similar, connected, and only have a touchscreen device, we should hide the cursor itself.

Peter, is there X API to do that?
Comment 1 William Jon McCann 2011-05-19 23:43:47 UTC
It might be interesting to use the spinner next to the App name when a busy cursor would be used too.
Comment 2 Peter Hutterer 2011-05-20 00:01:58 UTC
XFixesHideCursor(display, window) and XFixesShowCursor(display, window), provided XFIXES version 4 or greater.

We don't have a useful way to find out which devices are "real" and which ones are devices like "Video Bus" though. You can test for the virtual XTest devices by testing for the "XTEST Device" property on the device.
Comment 3 Bastien Nocera 2011-05-20 00:09:32 UTC
(In reply to comment #2)
> XFixesHideCursor(display, window) and XFixesShowCursor(display, window),
> provided XFIXES version 4 or greater.

I'm guessing that means that the toolkit needs to know about it as well, so that the apps don't show the cursor either. I'm starting to think that we might as well use a different cursor theme.

> We don't have a useful way to find out which devices are "real" and which ones
> are devices like "Video Bus" though. You can test for the virtual XTest devices
> by testing for the "XTEST Device" property on the device.

We can test for having a touchscreen first, so we never end up hiding the cursor in the wrong case.

(In reply to comment #1)
> It might be interesting to use the spinner next to the App name when a busy
> cursor would be used too.

I have no idea how we would get that information from the X server though.
Comment 4 Peter Hutterer 2011-05-20 00:17:41 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > XFixesHideCursor(display, window) and XFixesShowCursor(display, window),
> > provided XFIXES version 4 or greater.
> 
> I'm guessing that means that the toolkit needs to know about it as well, so
> that the apps don't show the cursor either. I'm starting to think that we might
> as well use a different cursor theme.

bit out of my depth here but I _think_ that hide cursor overrides app cursor updates. so even if the application changes cursors they will be invisible until a ShowCursor is called. Plus, HideCursor/ShowCursor are a stack, if you call it on the root window the cursors should be invisible until you pop the stack.

but yes, gtk would have to expose this call first too.

> (In reply to comment #1)
> > It might be interesting to use the spinner next to the App name when a busy
> > cursor would be used too.
> 
> I have no idea how we would get that information from the X server though.

how is the current spinning cursor decided on? wouldn't it be the same thing?
Comment 5 Bastien Nocera 2011-06-07 17:20:04 UTC
commit 3d2f33aa46f2c524fbd0c00def12fa1c7178a71c
Author: Bastien Nocera <hadess@hadess.net>
Date:   Tue Jun 7 18:09:02 2011 +0100

    cursor: Hide cursor on tablets with only a touchscreen
    
    When a tablet is available and no external pointer devices are
    available, hide the cursor.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=650604

Filed the gnome-shell part of the bug in bug 652066.