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.
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.
Patch series starting here: http://lists.freedesktop.org/archives/xorg-devel/2013-October/038198.html
(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.
follow-up patch: http://patchwork.freedesktop.org/patch/15061/
commit f36f5a65f639b6524191d888d5bf89e73027156c Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed Oct 30 15:40:58 2013 +1000 sync: fix corner-case in triggering idle alarms
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.