drivers: Delay DBus notifying and method returning until first measurement

When claiming a sensor via DBus, there are two possible options:

1. The sensor is not active, and the client is the first one to claim the sensor. In that case iio-sensor-proxy will initialize the sensor and notify the property on dbus once a first measurement has been done.

2. The sensor already is active, the client is not the first one to claim the sensor. In that case iio-sensor-proxy will not really do anything.

In case 2), the client can read the sensor property (so eg. ProximityNear) over DBus immediately and the result will be correct. Meanwhile in case 1), the client will read an outdated result (potentially from the last time the sensor was active, or just the default).

Clients have no way of knowing whether they're the first ones to claim a sensor though, so they can only trust iio-sensor-proxy that the DBus properties are always up-to-date. In case 1), this requirement is not met.

To deliver on that promise without drastically changing the API of iio-sensor-proxy, we have to delay with returning the DBus call on the first Claim() of a sensor until we receive a measurement from the sensor, so that the client has a valid measurement to work with right after Claim() returns.

Same thing goes for the case where a sensor is already claimed, but the actual sensor-hardware is not there yet. In this case we need to delay notifying the HasAccelerometer/HasAmbientLight/... DBus properties until the first measurement is received.

added 5 commits

• f733401d - drivers: Poll driver synchronously when claiming sensor the first time
• c90c582a - drivers/iio-buffer: Do a blocking read when starting up the driver
• 94352528 - drivers/fake: Do a blocking read when starting up the sensor
• 73e95bbc - drivers/poll: Do a blocking poll of sensor when starting up
• e9b8651a - drivers/input: Do a blocking read when starting up the sensor

Compare with previous version

changed the description

added 2 commits

• bf74f4a9 - drivers/iio-poll: Do a blocking poll of sensor when starting up
• b17effec - drivers/input: Do a blocking read when starting up the sensor

Compare with previous version

marked this merge request as ready

Updated and unmarked as draft now, I confirmed this works for the iio-buffer and iio-poll sensor types, just not for "input" types.

So this is ready for review.

Actually, there might be a better approach instead of blocking the main thread: The DBus invocation returns async anyway, so we might as well keep the invocation around and return only on the first measurement: verdre/iio-sensor-proxy@17cf5f79

marked this merge request as draft

added 5 commits

• 0a1bf5c0 - drivers: Delay DBus notifying and method returning until first measurement
• ad8549ad - drivers/iio-buffer: Do a read immediately when starting up the driver
• 2229e901 - drivers/fake: Return measurements immediately when starting up the sensor
• df9aa6ef - drivers/iio-poll: Do a poll immediately when starting up the sensor
• ad7d5e51 - drivers/input: Do a read immediately when starting up the sensor

Compare with previous version

marked this merge request as ready

changed title from Draft: drivers: Poll driver synchronously when claiming sensor the first time to drivers: Delay DBus notifying and method returning until first measurement

changed the description

Okay, updated this one now to go with the non-blocking approach I mentioned, seems a lot cleaner than just blocking the main the thread.

The MR is ready for review again.

Looks mostly good to me. I'd use g_autofree where possible apart from that I think we should merge this.

requested changes

added 8 commits

• ad7d5e51...94a50649 - 3 commits from branch hadess:master
• da8bee3e - drivers: Delay DBus notifying and method returning until first measurement
• d3285f5e - drivers/iio-buffer: Do a read immediately when starting up the driver
• 6b4a6439 - drivers/fake: Return measurements immediately when starting up the sensor
• b5add4ff - drivers/iio-poll: Do a poll immediately when starting up the sensor
• 8a540931 - drivers/input: Do a read immediately when starting up the sensor

Compare with previous version

The test failure looks related to the changes in this MR.