Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp740056ybt; Fri, 10 Jul 2020 11:07:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRsu5KgR8T+ER9HiqUPLN8Q6HvGSE97Sa0ORfqfxLfi2RVXgBKhhfLmW36m8ftA7u96+Kr X-Received: by 2002:a17:906:2616:: with SMTP id h22mr61441074ejc.154.1594404433439; Fri, 10 Jul 2020 11:07:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594404433; cv=none; d=google.com; s=arc-20160816; b=Sbdo7YVlO9/wfuKCqn+1fmNGiqfkIujz12TOU8QktB4pv33syCF7QU9asplrGbxACT kEkz3sZyIuKXEypI2I+d7si6c1ehiN3Nr8ZT7zEm0NSSw/XN6zXbUpx4YSJAX2xt+2Fz QsIQqgmAAswaMGDSVz4D55WD3Q8nkhoU4G6UucHIG6X+Nt3eJMNY1uEXHxnRZkxA461H NMq9PpAH9E9Ofbz11A+COrQHjGDgOtARXwWZmZXXMonmZZuEnXQR6nN0yAE8lowS/f5V 7PE/ADvsz7OSqBEoy7jkAS4ao4lByhuHzbxVyxv2vnMN8F4SOcodO+I3aZ3vlGfjx3CK XYRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Mwwxt+6Dm0ceODIWJuacgu8G2+IT6Ypl2+OAhI2wq48=; b=Z/rTOftXsPM3WE3tMhWxb/hWDL0UrEHBJ+k7qahU3j2D3GTM/3N0QeRdIGeCvElXFp ycr+5PxVp/fNuWUPv+RJiQyZ2IpR7fjkC3tDonpH2qybYehsPuSTcli5U8RzlZv8ykzd E5lcFycMBI5Xd4t4TlCg7PxCMeDR4+AeoOgqGA0JpbRi81E7//6dw2gmEWMtMeq/e08L iCxajG80Z6eO4Xaet0/p7Yy6vl9g6RACM4IzfqeXGEAs67ai21VuaXTM3f7TeZdy4wiy pw6k/fupUffR4NY2biqYtk/bTQc6OuRZdxOuM2zgBbb9mKp3p3YsKEkmX4xcX7aw3Zc/ YqaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dXsLtgdI; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r5si416747edh.198.2020.07.10.11.06.39; Fri, 10 Jul 2020 11:07:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dXsLtgdI; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726962AbgGJSGf (ORCPT + 99 others); Fri, 10 Jul 2020 14:06:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726920AbgGJSGf (ORCPT ); Fri, 10 Jul 2020 14:06:35 -0400 Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E963BC08C5DC for ; Fri, 10 Jul 2020 11:06:34 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id t198so5496708oie.7 for ; Fri, 10 Jul 2020 11:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mwwxt+6Dm0ceODIWJuacgu8G2+IT6Ypl2+OAhI2wq48=; b=dXsLtgdIutKGrFJ+t1nZg/NvSd2nia9K52l7u1DSdYJeipCK2p/LXuLdR8DopSq8Ey aFTkYa9JUaVVuyPbKqYShTkb6nutyBzRaDWAlTqAi7Qw3JZp7D4rd7isGjIPfqS5qTYx Rm5JbyXzvDrUPUNqgQ0p6VNOyrAthJddWV6o7f9vm1HX92GXRz5AmAWd/Z+WCGZxFAAD BJ+VN4c7NJOrsGqRUeJuiGTjBgWNiK1ZE5vz4jS4mMdOe6AzPVA1sGXtlatVEOBSgL7s J7h9T0zmaAN+U9ofTjzJ3ZQxJpNPF1cweR3q68fE7ZEAeiy4pcuWY5Q+C+meFoJgP67+ bAuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mwwxt+6Dm0ceODIWJuacgu8G2+IT6Ypl2+OAhI2wq48=; b=ctFA+DXGfRF4zi8d1AvwxpUzjUbpHJAUtFKlVxHgt4zszZChXeSYRl8F4y4OkTsMRq pclDxJzaqRQuqQ94Ydlo1okFiJbHK1O4i+i2mxyRd32OBHc7PZuwlFzQ3q5snD4JbsPD 5u77+Jx9Kz3evI3KsZDOMVOfQrDTXxvmCanSvL6fIQ4ZE8/LzpZsFSxPWpMVH+jsyTW+ uv3bdrhKvmHoAgw+uUJjk9wL/MGt+ge///XC0iMbZXg/GhqsVO15IZdT7trYbUnqDISq SHN568WjDbx+SdcO/4gpgp6MJFNQgWzx1Zj7sU8X5S6sPtCMQVEeg+EmdfJqqmEXqn8B UV2Q== X-Gm-Message-State: AOAM532YzYRmt//Z/p8mWopeZTvGFeUuURcuWkRXW0CbAOLmU0a331Oc SJLPGE+5L2gH0SA9TYtoSwg15NRNYRM3m24fd1w= X-Received: by 2002:aca:4a04:: with SMTP id x4mr4898436oia.152.1594404394207; Fri, 10 Jul 2020 11:06:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luiz Augusto von Dentz Date: Fri, 10 Jul 2020 11:06:22 -0700 Message-ID: Subject: Re: Temporary device removal during discovery To: Bastien Nocera Cc: Andrey Batyiev , linux-bluetooth Content-Type: text/plain; charset="UTF-8" Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Bastien, On Thu, Jul 9, 2020 at 1:26 AM Bastien Nocera wrote: > > On Thu, 2020-07-09 at 01:57 +0300, Andrey Batyiev wrote: > > Hi Luiz, > > > > On Thu, Jul 9, 2020 at 12:14 AM Luiz Augusto von Dentz > > wrote: > > > The delta logic might be a nice addition as a separate patch, it is > > > more for detecting devices disappearing then actually cleanup > > > during > > > power off. > > No-no, it's not about adapter powering off. > > > > I meant that (external) devices never disappear from the bluez device > > list during the discovery, > > even if the (external) devices are turned off (i.e. they should be > > purged by bluez). > > > > So: > > - bluez is central > > - bluez is discovering > > - peripheral appear for a moment, than disappear (i.e. peripheral > > would be turned off) > > - bluez would not remove device from the list (at least until > > discovery is stopped) > > > > Use case: > > - bluez is monitoring environment (discovering literally forever) > > - peripherals are brought in and out of bluez visibility range > > - bluez list of visible devices grows infinitely and causes problems > > (hundreds of devices) > > I'd also expect devices that are recently discovered to disappear if > they haven't replied to a discovery in 30 seconds. It would stop > GNOME's Bluetooth Settings's Bluetooth list forever expanding. > > Or we need to give the ability for front-ends to do that by exporting > the "last seen" dates. I am fine with that as well, 30 seconds doesn't sound too bad even for cleanup temporary devices as the current 3 minutes seems awful long sometimes, we could perhaps have a filter for configuring that though so if the application wants to have its own timeout, the only problem is if there are multiple application doing that on parallel we would need a strategy on how to handle that. -- Luiz Augusto von Dentz