Launchpad has imported 8 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=59644.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-01-21T01:38:37+00:00 Peter Hutterer wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/0 ------------------------------------------------------------------------ On 2013-10-05T16:00:45+00:00 Bugzilla-x wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/1 ------------------------------------------------------------------------ On 2013-10-15T03:42:42+00:00 Peter Hutterer 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/4 ------------------------------------------------------------------------ On 2013-10-17T04:18:28+00:00 Peter Hutterer wrote: Patch series starting here: http://lists.freedesktop.org/archives/xorg- devel/2013-October/038198.html Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/7 ------------------------------------------------------------------------ On 2013-10-17T22:35:16+00:00 Bugzilla-x wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/8 ------------------------------------------------------------------------ On 2013-10-18T10:07:49+00:00 Bugzilla-x wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/9 ------------------------------------------------------------------------ On 2013-10-22T02:58:52+00:00 Peter Hutterer wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/10 ------------------------------------------------------------------------ On 2013-10-30T06:41:55+00:00 Peter Hutterer wrote: follow-up patch: http://patchwork.freedesktop.org/patch/15061/ Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings- daemon/+bug/1238410/comments/15 ** Changed in: xorg-server Status: Unknown => In Progress ** Changed in: xorg-server Importance: Unknown => Medium ** Changed in: gnome-desktop Status: Unknown => Fix Released ** Changed in: gnome-desktop Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/1238410 Title: Inconsistent cursor visibility with cursor plugin enabled Status in GNOME Desktop Common Files: Fix Released Status in X.Org X server: In Progress Status in “gnome-settings-daemon” package in Ubuntu: Confirmed Status in “xorg-server” package in Ubuntu: Triaged 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) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-desktop/+bug/1238410/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
