Commit Graph

9 Commits

Author SHA1 Message Date
Andika Triwidada
9b21346427 Changed obsolete FSF postal address into generic URL.
Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-13 11:35:47 -05:00
Rui Matos
5ea443eb4b idle-monitor: Fix a GSList leak
https://bugzilla.gnome.org/show_bug.cgi?id=712833
2013-11-21 19:22:25 +01:00
Giovanni Campagna
348f3007d9 MetaIdleMonitor: protect the monitor instance while calling destroy notify
The destroy notify for a DBus watch holds a reference to the IdleMonitor,
but the IdleMonitorWatch object doesn't (it knows all watches will
be destroyed before the monitor is, so it doesn't need one). This
means that the DBus watch reference can be the only one keeping
the IdleMonitor alive (expecially true for device idle monitors,
which are only used by g-s-d/cursor), and that means that calling
the destroy notify freezes the monitor (and the next X calls
access garbage).

https://bugzilla.gnome.org/show_bug.cgi?id=708420
2013-09-26 18:57:49 +02:00
Giovanni Campagna
389e04c715 MetaIdleMonitor: fire immediately watches that are already expired
The XSync semantics mandate that alarms already expired will not
fire until the counter is reset and the alarm triggered again, so
clients traditionally called get_idle_time() first to see if they
should install the alarm.
This is inherently racy, as by the time the call is handled by
mutter and the reply received the idle time could be different.
Instead, if we see that the watch would have fired in the past,
fire it immediately.

This is a behavior change, but it's a compatible one, as all legacy
clients are calling get_idle_time() first, and it was perfectly
possible for the idle time counter to trigger the alarm right
after the get_idle_time() call.

https://bugzilla.gnome.org/show_bug.cgi?id=707302
2013-09-16 22:42:22 +02:00
Cosimo Cecchi
22ca820c44 idle-monitor: fix event propagation to devices
device_id_max is set to the device_id in ensure_device_monitor(), but we
will loop only to (device_id_max - 1) when propagating the sync XEvent
down, missing the device correspondng to device_id_max.

https://bugzilla.gnome.org/show_bug.cgi?id=707250
2013-09-01 17:51:10 -07:00
Jasper St. Pierre
6526e9882b idle-monitor: Fix a warning when a callback removes the user active watch
The user active watch is a one-fire watch, but it is valid in the API
for the callback to explicitly remove the watch itself. In that case,
the watch will be invalid after the user removes it, and the memory
potentially freed. So make sure to not dereference the watch after
the callback is called.

https://bugzilla.gnome.org/show_bug.cgi?id=706825
2013-08-27 09:57:06 +02:00
Giovanni Campagna
9affbf10a6 MetaIdleMonitor: add wayland support
Keep a timer source that we reset when we capture an event in
MetaWayland, and fire watches accordingly.

https://bugzilla.gnome.org/show_bug.cgi?id=706005
2013-08-23 16:34:02 +02:00
Giovanni Campagna
c0acf3ae6d MetaIdleMonitor: add a DBus interface for the idle monitor
To allow other clients (gnome-session, gnome-settings-daemon)
to monitor user activity, introduce a DBus interface for the
idle monitor inside mutter.

https://bugzilla.gnome.org/show_bug.cgi?id=706005
2013-08-23 16:34:02 +02:00
Giovanni Campagna
2c1b20e15f Add a new helper for tracking user idle activity
When running as a wayland compositor, we can't use the xserver's
IDLETIME, because that's updated only in response to X events.
But we have all the events ourselves, so we can just run the timer
in process.

https://bugzilla.gnome.org/show_bug.cgi?id=706005
2013-08-23 16:34:02 +02:00