From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 24 Feb 2015 12:51:57 +0200 From: Johan Hedberg To: Jakub Pawlowski Cc: Arman Uguray , Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" , Marcel Holtmann Subject: Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. Message-ID: <20150224105157.GA7112@t440s.lan> References: <1423528495-13173-1-git-send-email-jpawlowski@google.com> <20150223130923.GA28722@t440s.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-ID: Hi Jakub, On Mon, Feb 23, 2015, Jakub Pawlowski wrote: >>>> From an API stand point, I like Johan's suggestion better. Basically >>>> we treat all discovery APIs as "filtered" except StartDiscovery is >>>> just a special case of StartFilteredDiscovery that has 8 dB as the >>>> "RSSI" argument and "auto" for transport. If an app wants to use a >>>> lower RSSI threshold then whether or not the UI will flicker should be >>>> the responsibility of the UI code. Basically we should treat >>>> StartDiscovery as a legacy API and perhaps mark it as deprecated while >>>> maintaining support for it for backwards compatibility. >>> >>> I think you get the meaning of RSSI parameter wrong. It's not delta, >>> chow much rssi must change to report device again (I think chromeos >>> change that internally to something smaller). It's for proximity - if >>> device reported RSSI is bigger than this RSSI parameter then report >>> it, and there's no delta - we report every RSSI change we get (around >>> 3 times/sec). >> >> You're right, it's just delta so I was wrong there. Still, the 8 dBm >> thing shouldn't dictate how the discovery API should work since it >> only affects what delta threshold to use when updating the >> Device1.RSSI property. So, perhaps we can add a global D-Bus property >> for RSSI delta-threshold or perhaps make that a filter parameter of >> StartFilteredDiscovery. > > If we add global property for changing RSSI delta-threshold we would > have to define api to change and probably also negotiate RSSI when > multiple apps require different values. > Putting it into StartFilteredDiscovery parameter seems more > reasonable, but do we really need that ? > Can't we just have no RSSI delta for filtered scan, and let apps > decide on their own in their logic ? If something like this was exposed through D-Bus then a parameter to StartFilteredDiscovery would be the way to go, I think. However, until we have a clear need for it we can simply keep track of this internally. I.e. StartDiscovery keeps imposing the delta-threshold but as soon as there's one or more StartFilteredDiscovery active this type of filtering is removed. Johan