We already track clients, and we'll need to start using the second paramater of g_dbus_connection_emit_signal() to only send this signal to the D-Bus clients that are interested in it, for efficiency reasons (no need to wake a client listening to light sensor changes with an accelerometer update), and for security reasons (the raw accelerometer information should only go to the client that requested it, not all of them).
This however poses a problem as the driver types don't allow for 2 different types of clients when raw accelerometer, or computed accelerometer data is requested).
We should be doing this with or without that functionality. It's currently possible for clients to receive signals if:
1) client 1 starts (for example, gnome-settings-daemon in gdm), claims the light sensor, starts receiving signals
2) client 2 starts (for example, gnome-settings-daemon as a normal user), claims the light sensor, starts receiving signals
3) Either before or after 2) client 1 loses its seat, and calls ReleaseLight, but its D-Bus proxy is still running
4) iio-sensor-proxy sends a signal, and every one of the proxies still alive receives it, whether or not they have called ClaimLight themselves.
hadess
commented
4 years ago
From #193
We should be doing this with or without that functionality. It's currently possible for clients to receive signals if: 1) client 1 starts (for example, gnome-settings-daemon in gdm), claims the light sensor, starts receiving signals 2) client 2 starts (for example, gnome-settings-daemon as a normal user), claims the light sensor, starts receiving signals 3) Either before or after 2) client 1 loses its seat, and calls ReleaseLight, but its D-Bus proxy is still running 4) iio-sensor-proxy sends a signal, and every one of the proxies still alive receives it, whether or not they have called ClaimLight themselves.
See: https://bugzilla.gnome.org/show_bug.cgi?id=756539