Re: [systemd-devel] Detecting inactive sessions
On Wed, 2014-12-03 at 02:41 +0100, Lennart Poettering wrote: On Wed, 19.11.14 00:46, Bastien Nocera (had...@hadess.net) wrote: On Tue, 2014-11-18 at 19:32 +0100, Bastien Nocera wrote: On Tue, 2014-11-11 at 16:46 +0100, Lennart Poettering wrote: snip I am willing to take a patch for this, but then again, as I own a Yoga I might look into this myself too one day. If you can write the scaffolding for it, I'm happy writing the code that talks to the accelerometer, and that would make it work on your Yoga. I've already written that code once, and I should be able to transform it into something mergeable. Do note that we would have to handle 3 types of accelerometers: - IIO with ring buffer (the type supported by iio-sensor-proxy and in the Yoga) - polling IIO (the type used in cheap tablets such as mine) - input device accelerometers (as present in the WeTab, and Dell Venue 8 tablet, apparently) I'll correct my own mail. We want to handle 4 types of accelerometers: - quaternion sensor IIO with ring buffer (the type present in some Yogas) - accelerometer IIO with ring buffer (the type supported by iio-sensor-proxy and in the Yoga as well) - polling IIO (the type used in cheap tablets such as mine) - input device accelerometers (as present in the WeTab) Given that range of devices, it makes less and less sense to me to put it in systemd. I think that I might start thinking about a D-Bus API, and expect interested desktops to use that instead of adding hardware specific code in systemd. What do you think? Sounds OK to me too. As you prefer, especially if you are doing the work ;-) There's support for items 2 and 3 in iio-sensor-proxy. Would be nice if somebody with access to the quaternion sensor would write a driver for it (probably re-using quite a bit from the accelerometer code), and submit it. The support for the input devices will need to happen at the same time as the D-Bus API, as it replaces the udev accelerometer code. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
On Tue, 2014-11-11 at 16:46 +0100, Lennart Poettering wrote: snip I am willing to take a patch for this, but then again, as I own a Yoga I might look into this myself too one day. If you can write the scaffolding for it, I'm happy writing the code that talks to the accelerometer, and that would make it work on your Yoga. I've already written that code once, and I should be able to transform it into something mergeable. Do note that we would have to handle 3 types of accelerometers: - IIO with ring buffer (the type supported by iio-sensor-proxy and in the Yoga) - polling IIO (the type used in cheap tablets such as mine) - input device accelerometers (as present in the WeTab, and Dell Venue 8 tablet, apparently) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
On Tue, 2014-11-18 at 19:32 +0100, Bastien Nocera wrote: On Tue, 2014-11-11 at 16:46 +0100, Lennart Poettering wrote: snip I am willing to take a patch for this, but then again, as I own a Yoga I might look into this myself too one day. If you can write the scaffolding for it, I'm happy writing the code that talks to the accelerometer, and that would make it work on your Yoga. I've already written that code once, and I should be able to transform it into something mergeable. Do note that we would have to handle 3 types of accelerometers: - IIO with ring buffer (the type supported by iio-sensor-proxy and in the Yoga) - polling IIO (the type used in cheap tablets such as mine) - input device accelerometers (as present in the WeTab, and Dell Venue 8 tablet, apparently) I'll correct my own mail. We want to handle 4 types of accelerometers: - quaternion sensor IIO with ring buffer (the type present in some Yogas) - accelerometer IIO with ring buffer (the type supported by iio-sensor-proxy and in the Yoga as well) - polling IIO (the type used in cheap tablets such as mine) - input device accelerometers (as present in the WeTab) Given that range of devices, it makes less and less sense to me to put it in systemd. I think that I might start thinking about a D-Bus API, and expect interested desktops to use that instead of adding hardware specific code in systemd. What do you think? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
On Tue, 2014-11-11 at 16:46 +0100, Lennart Poettering wrote: On Wed, 29.10.14 15:45, 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? logind knows when sessions are active and not. Note that access control to such devices should really not be per-session, but per-user. Meaning that a user should get access to the device as long as he has at least one session active. That said, I am not sure I really grok what iio-sensor-proxy is doing, and whether doing it involving both uinput and uevents is really such a great idea. I am tempted to say that we should probably add support for the orientation sensors to logind, and abstract them away in logind so that only simple high-level rotation change events are sent out. Which is already what the code in the iio-sensor-proxy tries to do. iio-sensor-proxy's code means that we can have an accelerometer device showing up in udev, with the orientation updated only when the orientation of the device changes in a major way. I am pretty sure that orientation is something pretty much all desktop environments really want to know about, and as logind is really a system service these days that only exists for the purpose of making writing of desktop environments easy I think adding the orientation stuff to logind wouldn't be too far off. And I figure we need it for the userspace console too in one way or another... Orientation is pretty much a property of a seat anyway, and I figure it should be exposed as one, too. It's not a seat property. It's a property of the display itself. If you connected a tablet to a TV and rotated the tablet, you're not rotating the TV as well. Also, we really should figure out a logic where the desktop subscribes to orientation changes and we only in that case even do the IIO access, rather than pushing the IIO events up the stack even when nobody is listening. Which is what my original request was all about. I am willing to take a patch for this, but then again, as I own a Yoga I might look into this myself too one day. I need to figure out how to make the IIO code not suck first though. Cheers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
On Wed, 29.10.14 15:45, 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? logind knows when sessions are active and not. Note that access control to such devices should really not be per-session, but per-user. Meaning that a user should get access to the device as long as he has at least one session active. That said, I am not sure I really grok what iio-sensor-proxy is doing, and whether doing it involving both uinput and uevents is really such a great idea. I am tempted to say that we should probably add support for the orientation sensors to logind, and abstract them away in logind so that only simple high-level rotation change events are sent out. I am pretty sure that orientation is something pretty much all desktop environments really want to know about, and as logind is really a system service these days that only exists for the purpose of making writing of desktop environments easy I think adding the orientation stuff to logind wouldn't be too far off. And I figure we need it for the userspace console too in one way or another... Orientation is pretty much a property of a seat anyway, and I figure it should be exposed as one, too. Also, we really should figure out a logic where the desktop subscribes to orientation changes and we only in that case even do the IIO access, rather than pushing the IIO events up the stack even when nobody is listening. I am willing to take a patch for this, but then again, as I own a Yoga I might look into this myself too one day. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
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. 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
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
Re: [systemd-devel] Detecting inactive sessions
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. This way, iio-sensor-proxy would get an OPEN event if at least one user reads the data it produces, and a CLOSE event once the last user closed the device. Unfortunately, this requires kernel changes, which you probably want to avoid. But a user-space solution sounds like a hack to me. You'd have to somehow 'guess' whether there's a user of your input device. Not sure how to make that reliable.. I wrote something up: https://gist.github.com/dvdhrm/6af5b000ddaed781764c I can try to send this to linux-input@vger today. One downside is that there's no way to synchronously query iio-sensor-proxy to provide the needed information on wake-up. That is, if the screen is turned on but iio-sensor-proxy is suspended, then the first frame might be displayed in the wrong layout. If iio-sensor-proxy was a kernel driver, this wouldn't happen. Similarly, if it provided a dbus API, gnome could query it synchronously on wake-up. I could make the UI_EV_OPEN event synchronous, but that seems overkill to me... hmm, not sure. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Detecting inactive sessions
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? Cheers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
