The Yoga 900 has an accelerometer which should allow auto-rotation behavior.

On installing https://github.com/hadess/iio-sensor-proxy (Linux*, LightDM) it is possible to run monitor-sensor.

➜  ~ monitor-sensor
    Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: undefined)
=== Has ambient light sensor (value: 0.000000, unit: lux)
    Accelerometer orientation changed: normal
    Light changed: 49.999999 (lux)
    Light changed: 79.999998 (lux)
    Accelerometer orientation changed: left-up
    Accelerometer orientation changed: normal
    Accelerometer orientation changed: left-up
    Accelerometer orientation changed: bottom-up

With iio-sensor-proxy the data is made available on dbus. It has the form:

signal time=1479631365.562013 sender=:1.15 -> destination=(null destination) serial=449861 path=/com/ubuntu/Upstart; interface=com.ubuntu.Upstart0_6; member=EventEmitted
   string "dbus"
   array [
      string "SIGNAL=PropertiesChanged"
      string "BUS=system"
      string "INTERFACE=org.freedesktop.DBus.Properties"
      string "OBJPATH=/net/hadess/SensorProxy"
      string "SENDER=:1.4"
      string "ARG0=net.hadess.SensorProxy"
  1. Is it possible to run a script that only wakes up on certain dbus events? Preferably I re-use an event loop in a daemon that already exists rather than building my own Python script or C program. Something like adding a file to /etc/dbus.d/handlers/net/hadess/SensorProxy would be really cool.

  2. If I don't run monitor-sensor I do not seem messages appearing on dbus, even though iio-sensor-proxy is actually run. Are these messages only sent if someone is listening for them?

[*] Linux V 4.8.1-040801-generic #201610071031 SMP Fri Oct 7 14:34:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

PS: According to powertop when using monitor-sensor:

14.7 mW      1.5 ms/s       8.8        Process        dbus-monitor

The answer should describe the canonical way to handle this on Linux and be the most friendly solution from a battery usage perspective.


I'm not a Linux guru, but it seems like dbus-monitor is indeed the tool to use.

An answer to the post How to create a daemon which would be listening to dbus and fire script on message says :

Based on https://askubuntu.com/questions/150790/how-do-i-run-a-script-on-a-dbus-signal



dbus-monitor --profile "interface='$interface',member='$member'" |
while read -r line; do
    echo $line | grep ActiveChanged && your_script_goes_here

Just stick that in /etc/init.d/monitor-for-unlock, make it executable, and then make a soft link in rc2.d

chmod +x /etc/init.d/monitor-for-unlock
cd /etc/rc2.d
ln -s /etc/init.d/monitor-for-unlock .

The article Monitoring D-Bus adds :

Probably the most powerful feature of dbus-monitor is the fact that you are not limited to using just one watch expression at a time. The following example simultaneously monitors all 3 Tomboy signals and uses awk to parse the output from dbus-monitor and display a meaningful message.



WATCH1="type='signal', sender=${OJECT}, interface=${IFACE}, path=${DPATH}, member='NoteAdded'"
WATCH2="type='signal', sender=${OJECT}, interface=${IFACE}, path=${DPATH}, member='NoteSaved'"
WATCH3="type='signal', sender=${OJECT}, interface=${IFACE}, path=${DPATH}, member='NoteDeleted'"

dbus-monitor "${WATCH1}" "${WATCH2}" "${WATCH3}" | \
awk '
/member=NoteAdded/ { getline; print "Created note " substr($2,7) }
/member=NoteSaved/ { getline; print "Added note " substr($2,7) }
/member=NoteDeleted/ { getline; print "Deleted note " substr($2,7) }

Here is the output generated when I clicked on the Tomboy icon to create a new note, waited for the automatic save and then selected the delete option to delete the note.

$ ./test
Created note //tomboy/3da026dc-f6ee-4637-8a94-bec6e2844824"
Added note //tomboy/3da026dc-f6ee-4637-8a94-bec6e2844824"
Deleted note //tomboy/3da026dc-f6ee-4637-8a94-bec6e2844824"
  • What is the influence of the while loop on the cpu? I assume it blocks on read, via a call to read(2). How is it exactly implemented? – Anne van Rossum Dec 29 '16 at 12:53
  • I can't answer that, but it's easily tested. – harrymc Dec 29 '16 at 16:10
  • I've implemented the above in the form of a script and in the form of a C daemon at github. The dbus-monitor solution calls read 27276 times in 2 minutes compared to 6 times with the C daemon. Seems a script like this is definitely not how it should be done from a battery perspective... – Anne van Rossum Dec 30 '16 at 0:17
  • These methods were meant for debug rather than production. But it seems easy enough to create an event-driven script - example. – harrymc Dec 30 '16 at 9:17
  • Mmm. I interpret your remark as "You should now try to use Python. It's all super easy." My intent with this question is to have people understand how to do this in the canonical way on Linux. Not trial and error. – Anne van Rossum Dec 30 '16 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.