|
24 | 24 | DEALINGS IN THE SOFTWARE.
|
25 | 25 | </copyright>
|
26 | 26 |
|
27 |
| - <interface name="ext_idle_notifier_v1" version="1"> |
| 27 | + <interface name="ext_idle_notifier_v1" version="2"> |
28 | 28 | <description summary="idle notification manager">
|
29 | 29 | This interface allows clients to monitor user idle status.
|
30 | 30 |
|
|
54 | 54 | <arg name="timeout" type="uint" summary="minimum idle timeout in msec"/>
|
55 | 55 | <arg name="seat" type="object" interface="wl_seat"/>
|
56 | 56 | </request>
|
| 57 | + |
| 58 | + <!-- Version 2 additions --> |
| 59 | + |
| 60 | + <request name="get_input_idle_notification" since="2"> |
| 61 | + <description summary="create a notification object"> |
| 62 | + Create a new idle notification object to track input from the |
| 63 | + user, such as keyboard and mouse movement. Because this object is |
| 64 | + meant to track user input alone, it ignores idle inhibitors. |
| 65 | + |
| 66 | + The notification object has a minimum timeout duration and is tied to a |
| 67 | + seat. The client will be notified if the seat is inactive for at least |
| 68 | + the provided timeout. See ext_idle_notification_v1 for more details. |
| 69 | + |
| 70 | + A zero timeout is valid and means the client wants to be notified as |
| 71 | + soon as possible when the seat is inactive. |
| 72 | + </description> |
| 73 | + <arg name="id" type="new_id" interface="ext_idle_notification_v1"/> |
| 74 | + <arg name="timeout" type="uint" summary="minimum idle timeout in msec"/> |
| 75 | + <arg name="seat" type="object" interface="wl_seat"/> |
| 76 | + </request> |
| 77 | + |
57 | 78 | </interface>
|
58 | 79 |
|
59 |
| - <interface name="ext_idle_notification_v1" version="1"> |
| 80 | + <interface name="ext_idle_notification_v1" version="2"> |
60 | 81 | <description summary="idle notification">
|
61 | 82 | This interface is used by the compositor to send idle notification events
|
62 | 83 | to clients.
|
|
65 | 86 | becomes idle when no user activity has happened for at least the timeout
|
66 | 87 | duration, starting from the creation of the notification object. User
|
67 | 88 | activity may include input events or a presence sensor, but is
|
68 |
| - compositor-specific. If an idle inhibitor is active (e.g. another client |
69 |
| - has created a zwp_idle_inhibitor_v1 on a visible surface), the compositor |
70 |
| - must not make the notification object idle. |
| 89 | + compositor-specific. |
| 90 | + |
| 91 | + How this notification responds to idle inhibitors depends on how |
| 92 | + it was constructed. If constructed from the |
| 93 | + get_idle_notification request, then if an idle inhibitor is |
| 94 | + active (e.g. another client has created a zwp_idle_inhibitor_v1 |
| 95 | + on a visible surface), the compositor must not make the |
| 96 | + notification object idle. However, if constructed from the |
| 97 | + get_input_idle_notification request, then idle inhibitors are |
| 98 | + ignored, and only input from the user, e.g. from a keyboard or |
| 99 | + mouse, counts as activity. |
71 | 100 |
|
72 | 101 | When the notification object becomes idle, an idled event is sent. When
|
73 | 102 | user activity starts again, the notification object stops being idle,
|
|
0 commit comments