| Message ID | 1484927552.21721.17.camel@hadess.net (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > Hey, > > TLDR: > # first bad commit: [50ba22479c324c0d9dc8134d519dcba92d83a8a7] Merge > back earlier ACPI PM material for v4.3. > > hid-sensor-hub devices only start sending events through the IIO > trigger after a suspend/resume cycle. > > Other IIO drivers don't seem to exhibit those problems. I had another go, trying to break into the merge commit, and it's slightly more precise, but still doesn't make any sense to me. # first bad commit: [3431e490b50356b56084305a2e93b3a980802b22] Merge branch 'acpi-scan' into acpi-pm Any ideas? I'm running out of them... git bisect start # good: [25e5eaf19962bd48788371e4f516bdd89ce248bc] ALSA: sparc: Add missing kfree in error path git bisect good 25e5eaf19962bd48788371e4f516bdd89ce248bc # bad: [3431e490b50356b56084305a2e93b3a980802b22] Merge branch 'acpi-scan' into acpi-pm git bisect bad 3431e490b50356b56084305a2e93b3a980802b22 # good: [0755e74b8f04d17cea09fa342a788025b2b50e2e] ALSA: Fix uninintialized error return git bisect good 0755e74b8f04d17cea09fa342a788025b2b50e2e # good: [5b4ca4447757019f11a601b0009534ef84bed801] Merge tag 'media/v4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media git bisect good 5b4ca4447757019f11a601b0009534ef84bed801 # good: [23908db413eccd77084b09c9b0a4451dfb0524c0] Merge tag 'staging-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging git bisect good 23908db413eccd77084b09c9b0a4451dfb0524c0 # good: [13d45f79a2af84de9083310db58b309a61065208] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds git bisect good 13d45f79a2af84de9083310db58b309a61065208 # good: [91cca0f0ffa3e485ad9d5b44744f23318c8f99ab] Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 91cca0f0ffa3e485ad9d5b44744f23318c8f99ab # good: [84e3e9d04d5b5368a1c26f744a98c492052d0523] Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 84e3e9d04d5b5368a1c26f744a98c492052d0523 # good: [d8b2ba7c5928173fe1c12bd2545f5ed85d1c3c7a] IB/core: Destroy ocrdma_dev_id IDR on module exit git bisect good d8b2ba7c5928173fe1c12bd2545f5ed85d1c3c7a # good: [9c69481ed0b4e6e525e6d8d4d3d83b612397e67d] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect good 9c69481ed0b4e6e525e6d8d4d3d83b612397e67d # good: [761ab7664b30ed907f55da7f6966d4537f36d9ff] Merge branch 'for-linus' of git://git.kernel.dk/linux-block git bisect good 761ab7664b30ed907f55da7f6966d4537f36d9ff # good: [3e87ee06d0d6b759471a487ceb8a48ecc5dee1f8] Merge tag 'platform-drivers-x86-v4.2-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86 git bisect good 3e87ee06d0d6b759471a487ceb8a48ecc5dee1f8 # good: [5af310a8ee70dd6a588c8ee1d4487a230a7b7b65] Merge tag 'ib-mfd-base-acpi-dma-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into acpi-pm git bisect good 5af310a8ee70dd6a588c8ee1d4487a230a7b7b65 # good: [17ffc8b083ac299ff798419d1887b7cdcd4ae4d2] Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'acpi-resources' git bisect good 17ffc8b083ac299ff798419d1887b7cdcd4ae4d2 # good: [68c6b148daa6e45a85b31ef60ed9c9bfd556fff0] ACPI / scan: Move device matching code to bus.c git bisect good 68c6b148daa6e45a85b31ef60ed9c9bfd556fff0 # good: [1dcc3d3362b0c97e48290f7786be85b4cec2a147] ACPI / bus: Move ACPI bus type registration git bisect good 1dcc3d3362b0c97e48290f7786be85b4cec2a147 # first bad commit: [3431e490b50356b56084305a2e93b3a980802b22] Merge branch 'acpi-scan' into acpi-pm
On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess.net> wrote: > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: >> Hey, >> >> TLDR: >> # first bad commit: [50ba22479c324c0d9dc8134d519dcba92d83a8a7] Merge >> back earlier ACPI PM material for v4.3. >> >> hid-sensor-hub devices only start sending events through the IIO >> trigger after a suspend/resume cycle. >> >> Other IIO drivers don't seem to exhibit those problems. > > I had another go, trying to break into the merge commit, and it's > slightly more precise, but still doesn't make any sense to me. > > # first bad commit: [3431e490b50356b56084305a2e93b3a980802b22] Merge > branch 'acpi-scan' into acpi-pm > > Any ideas? I'm running out of them... The parents of this merge are 5af310a8ee70 and 1dcc3d3362b0. Can you please check if the problem is present in any of them alone? If not, it is theoretically possible that the merge itself had introduced it (as this is not a trivial merge). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hey Rafael, On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess.net> > wrote: > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > > > Hey, > > > > > > TLDR: > > > # first bad commit: [50ba22479c324c0d9dc8134d519dcba92d83a8a7] > > > Merge > > > back earlier ACPI PM material for v4.3. > > > > > > hid-sensor-hub devices only start sending events through the IIO > > > trigger after a suspend/resume cycle. > > > > > > Other IIO drivers don't seem to exhibit those problems. > > > > I had another go, trying to break into the merge commit, and it's > > slightly more precise, but still doesn't make any sense to me. > > > > # first bad commit: [3431e490b50356b56084305a2e93b3a980802b22] > > Merge > > branch 'acpi-scan' into acpi-pm > > > > Any ideas? I'm running out of them... > > The parents of this merge are 5af310a8ee70 and 1dcc3d3362b0. > > Can you please check if the problem is present in any of them alone? Both of those were already in the git bisect output: # good: [5af310a8ee70dd6a588c8ee1d4487a230a7b7b65] Merge tag 'ib-mfd-base-acpi-dma-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into acpi-pm git bisect good 5af310a8ee70dd6a588c8ee1d4487a230a7b7b65 # good: [1dcc3d3362b0c97e48290f7786be85b4cec2a147] ACPI / bus: Move ACPI bus type registration git bisect good 1dcc3d3362b0c97e48290f7786be85b4cec2a147 Or did I do this wrong? > If not, it is theoretically possible that the merge itself had > introduced it (as this is not a trivial merge). Yeah, I tried diving into the merge, but never managed to do so. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ Srinivas On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote: > Hey Rafael, > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess.net> > > wrote: > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > > > > Hey, > > > > > > > > TLDR: > > > > # first bad commit: [50ba22479c324c0d9dc8134d519dcba92d83a8a7] > > > > Merge > > > > back earlier ACPI PM material for v4.3. > > > > > > > > hid-sensor-hub devices only start sending events through the IIO > > > > trigger after a suspend/resume cycle. > > > > > > > > Other IIO drivers don't seem to exhibit those problems. > > > > > > I had another go, trying to break into the merge commit, and it's > > > slightly more precise, but still doesn't make any sense to me. > > > > > > # first bad commit: [3431e490b50356b56084305a2e93b3a980802b22] > > > Merge > > > branch 'acpi-scan' into acpi-pm > > > > > > Any ideas? I'm running out of them... > > > > The parents of this merge are 5af310a8ee70 and 1dcc3d3362b0. > > > > Can you please check if the problem is present in any of them alone? > > Both of those were already in the git bisect output: > # good: [5af310a8ee70dd6a588c8ee1d4487a230a7b7b65] Merge tag 'ib-mfd-base-acpi-dma-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into acpi-pm > git bisect good 5af310a8ee70dd6a588c8ee1d4487a230a7b7b65 > > # good: [1dcc3d3362b0c97e48290f7786be85b4cec2a147] ACPI / bus: Move ACPI bus type registration > git bisect good 1dcc3d3362b0c97e48290f7786be85b4cec2a147 > > Or did I do this wrong? > > > If not, it is theoretically possible that the merge itself had > > introduced it (as this is not a trivial merge). > > Yeah, I tried diving into the merge, but never managed to do so. Srinivas, does it sound like anything familiar to you? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote: > + Srinivas > > On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote: > > > > Hey Rafael, > > > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: > > > > > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess.ne > > > t> > > > wrote: > > > > > > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > > > > > > > > > > Hey, > > > > > > > > > > TLDR: > > > > > # first bad commit: > > > > > [50ba22479c324c0d9dc8134d519dcba92d83a8a7] > > > > > Merge > > > > > back earlier ACPI PM material for v4.3. > > > > > > > > > > hid-sensor-hub devices only start sending events through the > > > > > IIO > > > > > trigger after a suspend/resume cycle. > Srinivas, does it sound like anything familiar to you? I guess this is related to https://github.com/hadess/iio-sensor-proxy/issues/82 There is some race between user space and iio. So the driver powerup never gets called back to power a hub during system boot. So the workaround was to add to systemd unit file for iio-sensor-proxy [Unit] After=multi-user.target Something changed timings in the kernel, which triggered this issue. I never got chance to root cause this. Thanks, Srinivas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2017-02-01 at 15:57 -0800, Srinivas Pandruvada wrote: > On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote: > > + Srinivas > > > > On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote: > > > > > > Hey Rafael, > > > > > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: > > > > > > > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess. > > > > ne > > > > t> > > > > wrote: > > > > > > > > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > > > > > > > > > > > > Hey, > > > > > > > > > > > > TLDR: > > > > > > # first bad commit: > > > > > > [50ba22479c324c0d9dc8134d519dcba92d83a8a7] > > > > > > Merge > > > > > > back earlier ACPI PM material for v4.3. > > > > > > > > > > > > hid-sensor-hub devices only start sending events through > > > > > > the > > > > > > IIO > > > > > > trigger after a suspend/resume cycle. > > > > Srinivas, does it sound like anything familiar to you? > > I guess this is related to > https://github.com/hadess/iio-sensor-proxy/issues/82 > > There is some race between user space and iio. So the driver powerup > never gets called back to power a hub during system boot. So the > workaround was to add to systemd unit file for iio-sensor-proxy > [Unit] > After=multi-user.target > > Something changed timings in the kernel, which triggered this issue. I don't think it's simply "timings", or at least it's a big enough window of opportunity that I can reproduce the bug 100% of the time when not adding timeouts to iio-sensor-proxy's timeout. Putting the machine on suspend and resuming it also fixes the problem (for a machine I've been testing that can be suspended, it's not an option for all of them). > I never got chance to root cause this. Well, at least the root cause is limited to a single commit, shame it's a merge one. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, February 02, 2017 11:35:05 AM Bastien Nocera wrote: > On Wed, 2017-02-01 at 15:57 -0800, Srinivas Pandruvada wrote: > > On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote: > > > + Srinivas > > > > > > On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote: > > > > > > > > Hey Rafael, > > > > > > > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: > > > > > > > > > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess. > > > > > ne > > > > > t> > > > > > wrote: > > > > > > > > > > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > TLDR: > > > > > > > # first bad commit: > > > > > > > [50ba22479c324c0d9dc8134d519dcba92d83a8a7] > > > > > > > Merge > > > > > > > back earlier ACPI PM material for v4.3. > > > > > > > > > > > > > > hid-sensor-hub devices only start sending events through > > > > > > > the > > > > > > > IIO > > > > > > > trigger after a suspend/resume cycle. > > > > > > > Srinivas, does it sound like anything familiar to you? > > > > I guess this is related to > > https://github.com/hadess/iio-sensor-proxy/issues/82 > > > > There is some race between user space and iio. So the driver powerup > > never gets called back to power a hub during system boot. So the > > workaround was to add to systemd unit file for iio-sensor-proxy > > [Unit] > > After=multi-user.target > > > > Something changed timings in the kernel, which triggered this issue. > > I don't think it's simply "timings", or at least it's a big enough > window of opportunity that I can reproduce the bug 100% of the time > when not adding timeouts to iio-sensor-proxy's timeout. > > Putting the machine on suspend and resuming it also fixes the problem > (for a machine I've been testing that can be suspended, it's not an > option for all of them). > > > I never got chance to root cause this. > > Well, at least the root cause is limited to a single commit, shame it's > a merge one. In fact this is a merge that doesn't change any code by itself (I thought it did, but that was not correct), so if that had been more than timings, you'd have seen breakage on at least one of the merged branches. Moreover, it merges the commits under 3431e490b503 back on top of material that went into 4.2, so if you only see the problem in 4.3 and later, this has to be the 3431e490b503 branch. Can you double check 3431e490b503 alone, please? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-02-02 at 12:33 +0100, Rafael J. Wysocki wrote: > On Thursday, February 02, 2017 11:35:05 AM Bastien Nocera wrote: > > On Wed, 2017-02-01 at 15:57 -0800, Srinivas Pandruvada wrote: > > > On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote: > > > > + Srinivas > > > > > > > > On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote: > > > > > > > > > > Hey Rafael, > > > > > > > > > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: > > > > > > > > > > > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@had > > > > > > ess. > > > > > > ne > > > > > > t> > > > > > > wrote: > > > > > > > > > > > > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: > > > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > TLDR: > > > > > > > > # first bad commit: > > > > > > > > [50ba22479c324c0d9dc8134d519dcba92d83a8a7] > > > > > > > > Merge > > > > > > > > back earlier ACPI PM material for v4.3. > > > > > > > > > > > > > > > > hid-sensor-hub devices only start sending events > > > > > > > > through > > > > > > > > the > > > > > > > > IIO > > > > > > > > trigger after a suspend/resume cycle. > > > > > > > > > > Srinivas, does it sound like anything familiar to you? > > > > > > I guess this is related to > > > https://github.com/hadess/iio-sensor-proxy/issues/82 > > > > > > There is some race between user space and iio. So the driver > > > powerup > > > never gets called back to power a hub during system boot. So the > > > workaround was to add to systemd unit file for iio-sensor-proxy > > > [Unit] > > > After=multi-user.target > > > > > > Something changed timings in the kernel, which triggered this > > > issue. > > > > I don't think it's simply "timings", or at least it's a big enough > > window of opportunity that I can reproduce the bug 100% of the time > > when not adding timeouts to iio-sensor-proxy's timeout. > > > > Putting the machine on suspend and resuming it also fixes the > > problem > > (for a machine I've been testing that can be suspended, it's not an > > option for all of them). > > > > > I never got chance to root cause this. > > > > Well, at least the root cause is limited to a single commit, shame > > it's > > a merge one. > > In fact this is a merge that doesn't change any code by itself (I > thought it > did, but that was not correct), so if that had been more than > timings, you'd > have seen breakage on at least one of the merged branches. > > Moreover, it merges the commits under 3431e490b503 back on top of > material > that went into 4.2, so if you only see the problem in 4.3 and later, > this has to > be the 3431e490b503 branch. > > Can you double check 3431e490b503 alone, please? I don't understand what you're asking of me. I'm not a git master, and I've never had to deal with merge commits. Did you want me to run "git reset --hard 3431e490b503" and test the resulting kernel? I'm pretty sure that's equivalent what my 3 runs of bisection have done, and it failed. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 2, 2017 at 1:42 PM, Bastien Nocera <hadess@hadess.net> wrote: > On Thu, 2017-02-02 at 12:33 +0100, Rafael J. Wysocki wrote: >> On Thursday, February 02, 2017 11:35:05 AM Bastien Nocera wrote: >> > On Wed, 2017-02-01 at 15:57 -0800, Srinivas Pandruvada wrote: >> > > On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote: >> > > > + Srinivas >> > > > >> > > > On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote: >> > > > > >> > > > > Hey Rafael, >> > > > > >> > > > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote: >> > > > > > >> > > > > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@had >> > > > > > ess. >> > > > > > ne >> > > > > > t> >> > > > > > wrote: >> > > > > > > >> > > > > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote: >> > > > > > > > >> > > > > > > > Hey, >> > > > > > > > >> > > > > > > > TLDR: >> > > > > > > > # first bad commit: >> > > > > > > > [50ba22479c324c0d9dc8134d519dcba92d83a8a7] >> > > > > > > > Merge >> > > > > > > > back earlier ACPI PM material for v4.3. >> > > > > > > > >> > > > > > > > hid-sensor-hub devices only start sending events >> > > > > > > > through >> > > > > > > > the >> > > > > > > > IIO >> > > > > > > > trigger after a suspend/resume cycle. >> > > >> > > >> > > > Srinivas, does it sound like anything familiar to you? >> > > >> > > I guess this is related to >> > > https://github.com/hadess/iio-sensor-proxy/issues/82 >> > > >> > > There is some race between user space and iio. So the driver >> > > powerup >> > > never gets called back to power a hub during system boot. So the >> > > workaround was to add to systemd unit file for iio-sensor-proxy >> > > [Unit] >> > > After=multi-user.target >> > > >> > > Something changed timings in the kernel, which triggered this >> > > issue. >> > >> > I don't think it's simply "timings", or at least it's a big enough >> > window of opportunity that I can reproduce the bug 100% of the time >> > when not adding timeouts to iio-sensor-proxy's timeout. >> > >> > Putting the machine on suspend and resuming it also fixes the >> > problem >> > (for a machine I've been testing that can be suspended, it's not an >> > option for all of them). >> > >> > > I never got chance to root cause this. >> > >> > Well, at least the root cause is limited to a single commit, shame >> > it's >> > a merge one. >> >> In fact this is a merge that doesn't change any code by itself (I >> thought it >> did, but that was not correct), so if that had been more than >> timings, you'd >> have seen breakage on at least one of the merged branches. >> >> Moreover, it merges the commits under 3431e490b503 back on top of >> material >> that went into 4.2, so if you only see the problem in 4.3 and later, >> this has to >> be the 3431e490b503 branch. >> >> Can you double check 3431e490b503 alone, please? > > I don't understand what you're asking of me. I'm not a git master, and > I've never had to deal with merge commits. > > Did you want me to run "git reset --hard 3431e490b503" and test the > resulting kernel? I'm pretty sure that's equivalent what my 3 runs of > bisection have done, and it failed. I must have misunderstood you, sorry. This means that the error is present in 3431e490b503, though, so something on this branch had introduced it, most likely. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From fb595ab43f1e24a2f65298f8e9f7cd49a2d7dd29 Mon Sep 17 00:00:00 2001 From: Bastien Nocera <hadess@hadess.net> Date: Thu, 19 Jan 2017 22:20:25 +0100 Subject: [PATCH] Test ALS for events coming in --- src/monitor-sensor.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/src/monitor-sensor.c b/src/monitor-sensor.c index 8d1e997..730ed4d 100644 --- a/src/monitor-sensor.c +++ b/src/monitor-sensor.c @@ -12,6 +12,8 @@ static GMainLoop *loop; static guint watch_id; static GDBusProxy *iio_proxy, *iio_proxy_compass; +static int retval = 1; +static double last_als = 0.0; static void properties_changed (GDBusProxy *proxy, @@ -49,6 +51,7 @@ properties_changed (GDBusProxy *proxy, GVariant *unit; v = g_dbus_proxy_get_cached_property (iio_proxy, "LightLevel"); + last_als = g_variant_get_double (v); unit = g_dbus_proxy_get_cached_property (iio_proxy, "LightLevelUnit"); g_print (" Light changed: %lf (%s)\n", g_variant_get_double (v), g_variant_get_string (unit, NULL)); g_variant_unref (v); @@ -194,6 +197,19 @@ vanished_cb (GDBusConnection *connection, } } +static gboolean +check_als (gpointer data) +{ + if (last_als == 0.0) + retval = 1; + else + retval = 0; + g_main_loop_quit (loop); + g_message ("%s", retval == 1 ? "FAILED" : "SUCCESS"); + + return TRUE; +} + int main (int argc, char **argv) { watch_id = g_bus_watch_name (G_BUS_TYPE_SYSTEM, @@ -205,7 +221,8 @@ int main (int argc, char **argv) g_print (" Waiting for iio-sensor-proxy to appear\n"); loop = g_main_loop_new (NULL, TRUE); + g_timeout_add_seconds (10, check_als, NULL); g_main_loop_run (loop); - return 0; + return retval; } -- 2.9.3