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 Ubuntu Desktop Bugs, which is subscribed to gnome-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/1238410 Title: Inconsistent cursor visibility with cursor plugin enabled To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-desktop/+bug/1238410/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
