Bug 59644 - XSync alarms with negative transitions may not trigger
Summary: XSync alarms with negative transitions may not trigger
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-21 01:38 UTC by Peter Hutterer
Modified: 2017-02-03 05:03 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Hutterer 2013-01-21 01:38:37 UTC
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.
Comment 1 Bastien Nocera 2013-10-05 16:00:45 UTC
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.
Comment 2 Peter Hutterer 2013-10-15 03:42:42 UTC
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.
Comment 3 Peter Hutterer 2013-10-17 04:18:28 UTC
Patch series starting here: http://lists.freedesktop.org/archives/xorg-devel/2013-October/038198.html
Comment 4 Bastien Nocera 2013-10-17 22:35:16 UTC
(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
Comment 5 Bastien Nocera 2013-10-18 10:07:49 UTC
(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.
Comment 6 Peter Hutterer 2013-10-22 02:58:52 UTC
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.
Comment 7 Peter Hutterer 2013-10-30 06:41:55 UTC
follow-up patch: http://patchwork.freedesktop.org/patch/15061/
Comment 8 Peter Hutterer 2017-02-03 05:03:17 UTC
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.