Return-Path: MIME-Version: 1.0 Sender: armansito@google.com In-Reply-To: References: <1412028964-5298-1-git-send-email-armansito@chromium.org> <12072518.xz8sZz3RZr@uw000953> Date: Tue, 30 Sep 2014 10:21:17 -0700 Message-ID: Subject: Re: [PATCH BlueZ] core: Reduce RSSI delta threshold for RSSI property updates on Device1. From: Arman Uguray To: Marcel Holtmann Cc: Szymon Janc , BlueZ development Content-Type: text/plain; charset=UTF-8 List-ID: Hi Marcel, > the reason why this threshold exists in the first place is that when you = show the pairing list in your basic UI that the entries not keep jumping ar= ound like crazy. When we added this code 8 dBm made sense for that. That al= lows that you select an entry in the devices list successfully by touch or = mouse. Since sorting close by devices at the top makes more sense than doin= g things alphabetical. > Looks like we order them according to the order in which they were discovered in Chrome OS :P Aside from that though, isn't it a bit strange to set this threshold based on UI a use case? If I'm building a UI around this and entries are jumping around like crazy, then this seems like a UI problem and not a bluetooth daemon problem and I can go and set a new threshold myself in the UI code. -Arman