Ubuntu

Inconsistent cursor visibility with cursor plugin enabled

Reported by Doug McMahon on 2013-10-11
172
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Unity
Undecided
Unassigned
X.Org X server
In Progress
Medium
gnome-desktop
Fix Released
Medium
gnome-settings-daemon
New
Undecided
Unassigned
gnome-settings-daemon (Ubuntu)
High
Unassigned
Saucy
Undecided
Unassigned
xorg-server (Ubuntu)
High
Maarten Lankhorst
Saucy
Undecided
fferrieu

Bug Description

On fresh boots the greeter & desktop may have the cursor visible or may not until mouse is moved.
On a log out/in the cursor is almost always invisible until mouse is moved. (unless made visible in greeter screen, then visible on Desktop

This is all well & good, maybe some intentional aesthetics/design (https://bugzilla.gnome.org/show_bug.cgi?id=687791) , however sometimes the cursor never becomes visible.
In that case hitting some keys or context menu can cause it to show, though most times a log out is needed.
(with the removal of ctrl+alt+delete > log out this means most users will need to either blindly find the session indicator or hit power button.

When the g-s-d cursor plugin is disabled then the cursor is always visible, it the plugin has no use in an ubuntu session then maybe it should be default disabled

There is also the possibility, particularly on ssd drives, of a login with no session indicator. This occasionally combines with no visible cursor.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-settings-daemon 3.8.5-0ubuntu7
ProcVersionSignature: Ubuntu 3.11.0-12.18-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
ApportVersion: 2.12.5-0ubuntu1
Architecture: amd64
Date: Fri Oct 11 00:38:16 2013
InstallationDate: Installed on 2013-10-03 (8 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Beta amd64 (20131002)
MarkForUpload: True
SourcePackage: gnome-settings-daemon
UpgradeStatus: No upgrade log present (probably fresh install)

CVE References

An XSync alarm on the IDLETIME counter set up for a negative transition may not trigger. Specifically:

- the alarm is set up for NegativeTransition, delta 0, abs value 10ms
- if the idle time is > 10ms, a move of the mouse resets the idle time counter to 0. This will trigger the alarm notify to be sent (correct behaviour)
- SyncComputeBracketValues() is called to re-compute the bracket values
- the bracket value for the negative transition (10) is higher than the current value (0). Thus, the bracket is not set.
- the idle timer goes above 10 ms, but a reset will _not_ send an event from now on.

However, if after the 10 ms any alarm triggers and/or is changed by a client, SyncComputeBracketValues() will recompute the bracket values and will install our alarm as lower bracket. Thus, it will trigger for the next reset.

I believe this is causing loads of reports against gnome-settings-daemon's cursor plugin.

In some cases, the device will become active again before we have a chance to install a "became-active" watch on it, and we'll never receive an alarm saying that it became active.

Doug McMahon (mc3man) wrote :

This is a mess in the server and not easy to fix, and I'm not sure how to fix this at the moment.

As a workaround, a client can do the following to address the issue:

If a client needs a NegativeTransition alarm events for a threshold T, it can create _two_ alarms. One for a negative transition on T with the event mask set, and one for a positive transition on T with the event mask not set.

This way, if the negative transition bracket is not set (see comment 0), the positive one is set. And once that fires, the brackets will be recalculated and the negative transition alarm will be re-set. Since the event mask is clear for the positive alarm, no event is sent, so the client doesn't need any further adjustments.

The same should work for a client needing a positive transition alarm, with the obvious changes.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Doug McMahon (mc3man) on 2013-10-16
description: updated
Doug McMahon (mc3man) wrote :

It could be that the cursor *never* becoming visible is more likely to occur if there is no mouse movement at the greeter screen, ie. one goes from greeter to Desktop without making the cursor visible
If so then maybe this is some occasional glitch with the window manager?

(In reply to comment #3)
> Patch series starting here:
> http://lists.freedesktop.org/archives/xorg-devel/2013-October/038198.html

The patches seem to work correctly for me in my testing.

They're available at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6071106

(In reply to comment #4)
> (In reply to comment #3)
> > Patch series starting here:
> > http://lists.freedesktop.org/archives/xorg-devel/2013-October/038198.html
>
> The patches seem to work correctly for me in my testing.

I should qualify that.

Per-device alarms seem to work great, I wasn't able to make the cursor disappear completely without it reappearing when using the touchpad. This was my reproducer:
https://bugzilla.gnome.org/show_bug.cgi?id=706229#c21

However, gnome-settings-daemon's power plugin watches for the global idle time, and it has trouble turning the backlight back on when a key is pressed.

My test case is:
- setup "blank screen" to 1 min in the power settings
- let it blank
- press esc once the screen has gone completely black
- wait a second, screen doesn't turn on
- press ctrl, you'll see the password prompt instead of the shield, meaning that gnome-shell did receive the "esc" (that dismisses the shield) but gnome-settings-daemon didn't notice the key press as not being idle anymore and didn't turn on the backlight.

can you put some sort of debugging output in to check which alarms you're receiving and which ones are missing? I wonder if the alarm is generated but never sent down the wire until there's more input that flushes it.

Bruno Munoz (bruno-bmunoz) wrote :

hello,
same issue here.
I've found a working keyboard shortcut workaround :
move on a text terminal (crtl-alt-F1)
move back on the graphical session (ctrl-alt-F7) and the move cursor will came back

Geoffrey Lehée (socketubs) wrote :

Same bug for me.

Ubuntu 13.10 amd64.

Bruno Munoz workaround works for me! Thank you.

gsbabil (gsbabil) wrote :

I have nearly the same problem. I have recently upgraded to 13.10 and the invisible-mouse-cursor problem immediately affected me. Basically, I have the following:

 - I have no visible cursor inside LightDM during login
 - I have no visible cursor inside the Lubuntu session of LXDE. Although I can click and perform all mouse activities.
 - For a brief moment, after successful login between the Lightdm and LXDE session, I can see the X server's default mouse cursor. But it disappears as soon as LXDE is started.

I found a rather dumb way of fixing the problem and I have no clue why it worked.

1. Created a new user called 'dummy'
2. Logged out from my default user session (where the mouse cursor is invisible). Alternatively you could do 'sudo service restart lightdm' if clicking the right button becomes tedious due to the "invisible" cursor
3. From LightDM, logged in as 'dummy' - great, mouse cursor is visible here.
4. Logged out from 'dummy' user session
5. From LightDM, Logged in as the default user - voila! mouse cursor is back!

Other tricks that I had tried:

 - sudo update-alternatives --display x-cursor-theme ## make sure it is set to a theme that you have installed on your machine
 - Check ~/.config/lxsession/Lubuntu or ~/.config/lxsession/LXDE to make sure it matches what you have set above

Hope it helps.

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
Doug McMahon (mc3man) wrote :

On the same machine with a new 14.04 install this does not occur though still an issue with the 13.10 install
The 13.10 was installed on 10/04 so possibly a new 13.10 release install would be fine, I've no inclination to try as 13.10 is relatively unimportant

Paulo Narciso (p-narciso) wrote :

14.04 have exactly the same issue.

Doug McMahon (mc3man) wrote :

I do now see on 14.04 but much rarer occurrence then in 13.10. So I'll just continue to disable the cursor plugin in g-s-d until this is fixed (if ever
Can't say I've seen any downside to having the plugin disabled, other than the 'no visible cursor till mouse moved feature' which is of no importance here.

tags: added: trusty
Øyvind (sieges) wrote :

Same bug here. 13.10 on Sony Vaio Pro Haswell.
Bruno Munoz' workaround works for the time being. Thanks.

Stuart Bishop (stub) wrote :

Per duped Bug #1237218, the manifestation I see of this is that very occasionally I log in (not having touched the mouse at all so I'm unsure if it is working on the greeter screen), and I find that there is no mouse visible in Unity. It is still active, as I can use the invisible mouse pointer to click on things. Using keyboard navigation to log out and then logging in again, the problem is probably gone and the mouse pointer visible again.

scottku (scottku) wrote :

I have also found this to be a problem a couple of times on Ubuntu 13.10. I haven't experienced it enough times to definitively figure out what is happening. But I believe that this bug might be occurring when you reboot a machine and log in without ever touching the mouse. I resolved the problem by logging out using the indicator (without seeing my cursor), and then logging in while making sure I move the mouse.

I'm not sure why this is categorized as a low priority bug. Although it is fairly minor bug, I can certainly see that it would be very frustrating and annoying for novice and expert users alike.

Sebastien Bacher (seb128) wrote :

That seems like https://bugzilla.gnome.org/show_bug.cgi?id=706229, but the upstream bug applies to GNOME 3.10 and not our 3.8 version.

The GNOME ticket also points to an xorg issue, https://bugs.freedesktop.org/show_bug.cgi?id=59644
which might fixes the issue seen here

Do people having the issue "play" with their trackpad while the screen is loading? it seems like it could be happening while events are mixed on loading. Does it happen if you keep your hands off the device on boot?

Changed in gnome-settings-daemon (Ubuntu):
importance: Low → High
Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → In Progress
Changed in gnome-desktop:
importance: Unknown → Medium
status: Unknown → Fix Released
Sebastien Bacher (seb128) wrote :
Changed in xorg-server (Ubuntu):
status: New → Triaged
importance: Undecided → High
Sebastien Bacher (seb128) wrote :

(the stack of commit from 2013-10-22 on http://cgit.freedesktop.org/xorg/xserver/log/Xext/sync.c?h=server-1.14-branch is likely needed as well)

Changed in xorg-server (Ubuntu):
assignee: nobody → Maarten Lankhorst (mlankhorst)
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.14.4-1ubuntu1

---------------
xorg-server (2:1.14.4-1ubuntu1) trusty; urgency=low

  * Merge released debian-unstable.
  * Cherry-pick fix to sync code. (LP: #1238410)

xorg-server (2:1.14.4-1) unstable; urgency=low

  * New upstream release.
  * Drop upstreamed patches.
    - 02_improve-posix-saved-ids-check.diff
    - 04_hashtabletest-s390x.diff
    - 10_Include-missing-selection-h.diff
 -- Maarten Lankhorst <email address hidden> Wed, 04 Dec 2013 13:54:02 +0100

Changed in xorg-server (Ubuntu):
status: In Progress → Fix Released
Doug McMahon (mc3man) wrote :

Fix appears to be working fine here on 14.04, tested over the day thru numerous restarts & log out/ins
(though 14.04 wasn't as susceptible as 13.10 for whatever reason

Sebastien Bacher (seb128) wrote :

Thanks for confirming Doug, I was a bit unsure how to test that one since I never ran into it (is it specific to laptops/touchpads?). In any case keep looking for it but it's looking good ;-)

On 12/05/2013 03:39 AM, Sebastien Bacher wrote:
> Thanks for confirming Doug, I was a bit unsure how to test that one
> since I never ran into it (is it specific to laptops/touchpads?). In any
> case keep looking for it but it's looking good ;-)
>
It could be specific to laptops, here that's all I have so can't remark
on Desktops anymore.
Maybe I should tag some bugs in future with "laptop", if that's an
acceptable tag??

Alexander Kops (alexkops) wrote :

No, it's not specific to laptops.
I have this issue only on my desktop PC (using a Microsoft Explorer mouse).

Duke (duke1995) wrote :

I experience this problem on my desktop PC too from time to time. The workaround from comment #4 (https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1238410/comments/4) brings back the cursor.

Hello Doug, or anyone else affected,

Accepted xorg-server into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/xorg-server/2:1.14.5-1ubuntu2~saucy1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in xorg-server (Ubuntu Saucy):
status: New → Fix Committed
tags: added: verification-needed
valadil (valadil) wrote :

I'm glad to see there's a fix. I haven't had the cursor staying invisible problem, but I have an issue with this setting in general.

I use focus follows mouse. When the mouse blanks out, whatever window it's over gets focus.

The use case where this behavior is most noticeable is in my IDE. I hit ctrl-h to make a search window pop up. I start typing in the search. Then my mouse disappears and focus switches to my IDE's editor. Now I'm typing a fragment of my search in there. This happens a couple times a minute and it's aggravating as hell.

Please consider changing the default setting OR the behavior of the mosue blanking out so that it doesn't trigger focus.

amjjawad (amjjawad) wrote :

I am NOT sure if this is the same as this bug but in my case, the cursor has disappeared after the monitor was off/screensaver - once I moved the mouse to see the desktop, there was no cursor but I was able to click, I just can NOT see the cursor and it is hard to use a ghost cursor and keep clicking blindly :)

Timo Aaltonen (tjaalton) wrote :

Doug, please test if the update fixes it for you.

On 12/19/2013 08:36 AM, Timo Aaltonen wrote:
> Doug, please test if the update fixes it for you.
>
Tim - I was hoping someone who was using 13.10 & affected would test.
Seeing as that's not happening I'll put up a new 13.10 release install & -

See if the invisible cursor behavior happens.
If so, do any of the current non -proposed updates help.

If still occurring then will upgrade the -proposed & ck.
Should take a day to run thru & report back

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu Saucy):
status: New → Confirmed
Doug McMahon (mc3man) wrote :

Tried for a day plus on 2 laptops to reproduce this bug on fresh 13.10 release installs & *can not* cause it to happen.
Then updated fully & still it does not occur.

After all that did go ahead & upgrade xserver-xorg-core/common from -proposed, see no regressions from it.

So from here the upgrade would not be needed, not sure where that leaves this as no other previously affected user has chimed in.

Philip (philip-b-raymond) wrote :

SInce no one else has chimed in, here's my situation... I had the mouse cursor disappears problem on a fresh install of 13.10. Drove me nuts. Changing the gnome settings to false (as reported elsewhere I think) did not bring the cursor back, however, going to a full-screen terminal (CTL-ALT-F6/F7 for me) brought the cursor back. The cursor would disappear at random times, however there were two things that I could do to guarantee to make it happen. Open a video in VLC or run SSVNC.

I'm not sure I did it correctly, but I added the saucy-proposed repository and I added the /etc/apt/preference file to not force other updates. Then I opened synaptic and could not find the xorg-server package that had been updated. Couldn't find anything like that, but I did find several packages with the similar version (2:1.14.3) so I blindly upgraded xserver-xorg-core, which also upgraded xserver-xorg-common (I think, because I can't find it in synaptic). I am now running xserver-xorg-core 2:1.14.5-1ubuntu2~saucy1.

Anyway, all that to say that since I did that yesterday, it has completely fixed the bug for me. Haven't had the cursor disappear once. It fixed the VLC issue as well as the SSVNC issue. Thank you very much!!!

Previously I had the issue and could replicate by shutting lid on laptop and then open.

Upgraded xserver-org-common and xserver-org-core from proposed and this has resolved the issue.

tags: added: verification-done
removed: verification-needed
alex (alex-gfd) on 2013-12-30
Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → alex (alex-gfd)
assignee: alex (alex-gfd) → nobody
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.14.5-1ubuntu2~saucy1

---------------
xorg-server (2:1.14.5-1ubuntu2~saucy1) saucy-proposed; urgency=low

  * Copy package back to saucy-proposed from trusty.
    - There's a MRE for xorg-server.
    - Fixes mesa >= 10 support on saucy.
    - Fix a timer bug in the sync code. (LP: #1238410)
  * Changes in packaging:
    - Fix gpu screen output hotplugging. (LP: #1259561)
    - Do not render invalid trapezoids. (LP: #1197921) (CVE-2013-6424)
    - Fix for CVE-2013-1056.
 -- Maarten Lankhorst <email address hidden> Mon, 16 Dec 2013 13:27:58 +0100

Changed in xorg-server (Ubuntu Saucy):
status: Fix Committed → Fix Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

fferrieu (fferrieu) on 2014-01-30
Changed in xorg-server (Ubuntu Saucy):
assignee: nobody → fferrieu (fferrieu)
Jaime Pérez (jaime-91) wrote :

unity-tweak-tool --reset-unity

this worked for me until next reboot

Jaime Pérez (jaime-91) wrote :

I have some errors using that comand, though. I suppose fixing it would fix the problem.

Jaime Pérez (jaime-91) wrote :

with that command, power menu and those things disappeared

Jaime Pérez (jaime-91) wrote :

More errors in unity-tweak-tool

Jaime Pérez (jaime-91) wrote :

If the command is used, Unity is loaded with admin privileges, so everything will be opened as root.

Jaime Pérez (jaime-91) wrote :
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.