Hi Marcel,
> the D-Bus API have all been designed with user interaction in mind. So it makes sense to impose this kind of extra thresholds. That is why you can map D-Bus things 1:1 to your UI and it will all nicely work.
>
I guess this falls into the overall question of designing an
application API vs an API for system UI. I always look at the D-Bus
API as an application API where system UI is one specific application.
In the end, we should be able to build use cases that require more
fine-tuned RSSI updates.
I don't know if the RSSI property of Device1 is the right thing to use
for this, though I still find it strange that it's hardwired to serve
system UI only.
In any case, I'm open to suggestions. Could we perhaps introduce a new
API for RSSI updates? Or a new property maybe? Perhaps we could expose
a property that sets the RSSI update threshold? Something like:
int16 RSSIUpdateThreshold [readwrite]
Defines the minimum amount of change required (in dBm) for the
RSSI property of a device
to be updated. Set to 8 dBm by default.
And this would be a property on Adapter1. I'm mostly thinking out loud
here though, so this may not be the best answer.
Cheers,
Arman
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
