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 <had...@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 <had...@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). _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
