Hi Bastien On Mon, Nov 3, 2014 at 5:30 PM, Bastien Nocera <[email protected]> wrote: > On Mon, 2014-11-03 at 17:28 +0100, David Herrmann wrote: >> Hi >> >> On Wed, Oct 29, 2014 at 3:45 PM, Bastien Nocera <[email protected]> wrote: >> > For a very specific definition of inactive. >> > >> > I'm looking at a way for the iio-sensor-proxy at: >> > https://github.com/hadess/iio-sensor-proxy >> > to suspend reading from accelerometers (or maybe to turn them off), when >> > all the sessions are locked and the screens turned off. >> > >> > This would usually mean that I would enable reading from the sensor if >> > one session is "active" and stop reading if none are "active". Is this >> > correct? Is it up to the session manager (eg. gnome-session) to tell us >> > whether a session is active or not, or do I have this backwards? >> >> For uhid (similar to uinput) you get an OPEN and CLOSE event whenever >> the first/last user opens/closes the device you created. I think we >> want something similar for uinput. That is, when a gnome session is >> inactive, they should just close the input devices that were created >> by iio-sensor-proxy (done automatically if you use the systemd-logind >> API to access devices). This way, iio-sensor-proxy knows whenever at >> least one session uses the data. This is also how most kernel-internal >> APIs work. > > The session doesn't read from the uinput device. The iio-sensor-proxy > just sends out a kevent, which is caught by the accelerometer helper in > udev. The GNOME session catches the udev event and reads the changed > property.
Ugh, you're right, of course! So we have this user-space driver, iio-sensor-proxy, which wants to stop reporting data if the there is no consumer of it. Still, the obvious way is for the consumers to tell iio-sensor-proxy. Given the current design (via uevents), this is not possible, though. I have no idea how to fix this up. I really dislike adding heuristics to iio-sensor-proxy to "guess" whether there is any consumer of the data. Imagine there's a system that uses the orientation data to control sound-output, instead of video-output. How would you know that in iio-sensor-proxy? The system might look idle, all displays are off, but still, someone might want this data. btw., looking at iio-sensor-proxy: you send uevents for _each_ accelerometer event? uevents are _really_ heavy, compared to input events. I'm not sure this is a good idea, unless the accelerometers report data only every few seconds. Thanks David _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
