[systemd-devel] Detecting inactive sessions

[Bastien Nocera]

On Tue, 2014-11-04 at 10:09 +0100, David Herrmann wrote:
> Hi Bastien
> 
> On Mon, Nov 3, 2014 at 5:30 PM, Bastien Nocera <hadess at hadess.net> 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 <hadess at hadess.net> 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.

That's really not the way that the proxy is done, it only sends events
via uinput when the orientation changes in a major way. This is really
not setup to help configure anything but the screen orientation.

> 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.

No, we don't. We send uevents when the orientation is changed (landscape
vs. portrait, not a 5 degrees angle change).