Inconsistent cursor visibility with cursor plugin enabled
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
GNOME Settings Daemon |
New
|
Undecided
|
Unassigned | |||
X.Org X server |
Fix Released
|
Medium
|
||||
gnome-desktop |
Fix Released
|
Medium
|
||||
gnome-settings-daemon (Ubuntu) |
Confirmed
|
High
|
Unassigned | |||
Saucy |
Won't Fix
|
High
|
Unassigned | |||
unity (Ubuntu) | ||||||
Saucy |
Invalid
|
High
|
Unassigned | |||
xorg-server (Ubuntu) |
Fix Released
|
High
|
Maarten Lankhorst | |||
Saucy |
Fix Released
|
High
|
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:/
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-
ProcVersionSign
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-
UpgradeStatus: No upgrade log present (probably fresh install)
description: | updated |
Changed in gnome-settings-daemon (Ubuntu): | |
importance: | Undecided → Low |
Changed in xorg-server: | |
importance: | Unknown → Medium |
status: | Unknown → In Progress |
Changed in gnome-desktop: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
Changed in xorg-server (Ubuntu): | |
assignee: | nobody → Maarten Lankhorst (mlankhorst) |
status: | Triaged → In Progress |
tags: |
added: verification-done removed: verification-needed |
Changed in gnome-settings-daemon (Ubuntu): | |
assignee: | nobody → alex (alex-gfd) |
assignee: | alex (alex-gfd) → nobody |
Changed in xorg-server (Ubuntu Saucy): | |
assignee: | nobody → fferrieu (fferrieu) |
Changed in unity (Ubuntu Saucy): | |
status: | New → Invalid |
Changed in xorg-server (Ubuntu Saucy): | |
importance: | Undecided → High |
Changed in gnome-settings-daemon (Ubuntu Saucy): | |
importance: | Undecided → High |
Changed in unity (Ubuntu): | |
importance: | Undecided → High |
Changed in unity (Ubuntu Saucy): | |
importance: | Undecided → High |
no longer affects: | unity |
no longer affects: | unity |
Changed in xorg-server: | |
status: | In Progress → Fix Released |
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 ketValues( ) is called to re-compute the bracket values
- 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)
- SyncComputeBrac
- 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, SyncComputeBrac ketValues( ) will recompute the bracket values and will install our alarm as lower bracket. Thus, it will trigger for the next reset.