Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp488309pxa; Tue, 4 Aug 2020 10:13:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwREoUnZUJ0bARw3/WtPL9maVfy8nygUl2kI/D6qUiREOJ3eV8i8c0CHhV3Zk2wrj+x9UU8 X-Received: by 2002:a17:906:d102:: with SMTP id b2mr21525270ejz.465.1596561229214; Tue, 04 Aug 2020 10:13:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596561229; cv=none; d=google.com; s=arc-20160816; b=l/K9cCTonC7nXlGrXdAL0eXX0VgMuiR7wGEiGAb8KLLWCsCzMlMWT8GYCTQ08Cq1WE yyPa6W7AIUMqe+oyynB74jkXZ6n1xSJxDBq3wBtxtIPl3OqkkB1502wXGNpuFpWPaHwd Or9hBb5hqR8cEb6yEslVB4E+8urWbySbdU6GHJ1rV7EOAV74KyITUULmgm8R0AcJs2NT uF3BBt1gXLn5psvN33jmA2z7ekAlyPZoqPt942vflGV0k5ZtvM+k+ayTEnIOPakc49jT BSZUN/eAO3ULpBMMCHpk6JL3XreMasrflr4wTG7beNxqA7TndocmsSAff7OtqxSqLaN7 KVKA== 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=aldbhSzOkNRsGNiPJyEC/gglp+26OuNIUIYrm3hBhJE=; b=BgsAt9XViGJff/nxP1DB6T4ObZb8VuPPjOfuL6Fr7BGZtzwXU0cxBlAHLJgpQnHXBr cQK0eTuTLnfsAu7myPk5CIzrV4627Wn0q8vOMIPSYzkXGb9pjvCmr7B13hG1hJ4IrcQT TicUWUd2MkomNoObGn85flLt76KvfoqDVRUEi1QCiCwpuiM928Pbnn5zMp1PTmWfp8+7 zglvx7QB6K7zOq7RIvls7OffA8BoJ2E2DQQNv/vQOvX1FB8FqBUylvjabP2yPEPpWnlG DP0XU4QrpXR7KX3VuMhuSBm3bxI6UJ54EjSxC7Z5aiGsqRusENlucCZB8wuYbxjCYEwv 6F0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=iX6Uye0a; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t17si13342166ejs.588.2020.08.04.10.13.23; Tue, 04 Aug 2020 10:13:49 -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=@chromium.org header.s=google header.b=iX6Uye0a; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729853AbgHDRMe (ORCPT + 99 others); Tue, 4 Aug 2020 13:12:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729391AbgHDRMa (ORCPT ); Tue, 4 Aug 2020 13:12:30 -0400 Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9185DC06174A for ; Tue, 4 Aug 2020 10:12:30 -0700 (PDT) Received: by mail-vs1-xe42.google.com with SMTP id j23so15092341vsq.7 for ; Tue, 04 Aug 2020 10:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aldbhSzOkNRsGNiPJyEC/gglp+26OuNIUIYrm3hBhJE=; b=iX6Uye0aXNQArYfLdZEVLD/zW8NoQMEHi2sfdh9o/pwjVrCyRREZ3+tgmYgVBwQH01 VAmkPVQNbpkphKOQkbfN7v1XrkGtoZ/rB5kJYtyJaibhJwE3biZBN6x5w1xNBEd79NRz HMHeJcaQB7zR5LaEtOv3GRtFA811E+5vYp/0s= 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=aldbhSzOkNRsGNiPJyEC/gglp+26OuNIUIYrm3hBhJE=; b=W/B74WfIlSHBO/s3g0n0l9n61KCpKVx3KqJ2p1T4r6TDo3iOVv35t/Md/C/cVm6Nly FW8TwY1qeYYzgdx0qtZBqo9UIcN9RKkr4LhPhFwUBdYGXIMn5eI3Yc0VU/6I1o3reCe1 Xg9sbMHuOxWReVW1wwq+aUqmKc9tskEZAfVrbub/vBp/vLY9sN9cRN66aMO3tSKxpMzo arnkJhLqTU0JcFp8DANVVO1H1/VvnzGdkj3oj3XjmPQ2EsYUkCxQB13FAGcvoI7zQecc CfolQlCbg75t/Z3p1gGt5HBOdHbUK6qLqF+D4PHzVx+7dJAzT/ZGhIwDdGdtIHpONXQK aWSQ== X-Gm-Message-State: AOAM531Qm91M4qkvUY6Oofh10OiJ4SX58JOvNiHxfaUCdiv/wmm2tJdk LJ105I1pAP26vTY9J6DPZCBMypsr+jRti5nBeSiSwg== X-Received: by 2002:a67:3111:: with SMTP id x17mr16188920vsx.196.1596561148224; Tue, 04 Aug 2020 10:12:28 -0700 (PDT) MIME-Version: 1.0 References: <20200729015540.1848987-1-abhishekpandit@chromium.org> In-Reply-To: <20200729015540.1848987-1-abhishekpandit@chromium.org> From: Abhishek Pandit-Subedi Date: Tue, 4 Aug 2020 10:12:16 -0700 Message-ID: Subject: Re: [RFC Bluez PATCH 0/3] adapter: Reconnect audio when resuming from suspend To: Luiz Augusto von Dentz , Marcel Holtmann Cc: ChromeOS Bluetooth Upstreaming , Bluez mailing list 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, Gentle reminder that this is waiting for feedback. Thanks Abhishek On Tue, Jul 28, 2020 at 6:55 PM Abhishek Pandit-Subedi wrote: > > > Hi Luiz and Marcel, > > This is a quality of life improvement for the behavior of audio devices > during system suspend. This depends on a kernel change that emits > suspend/resume events: > > https://patchwork.kernel.org/project/bluetooth/list/?series=325771 > > Right now, audio devices will be disconnected as part of suspend but > won't be reconnected when the system resumes without user interaction. > This is annoying to some users as it causes an interruption to their > normal work flow. > > This change reconnects audio devices that were disconnected for suspend > using the following logic: > > * In the Device Disconnected management event, if the disconnect reason > was 0x5 (Disconnected by Local Host for Suspend) and the device is an > audio sink (implements major services Audio + Rendering), then it is > queued for reconnect. > * When the Controller Resumed management event is seen, we check if > an audio device needs to be reconnected. If yes, we queue a delayed > callback to do the reconnection. The delay is 5s by default and is > meant to allow sufficient time for any Wi-Fi activity that may occur > during resume (since Bluetooth connect may adversely affect that). > > A reconnect is only attempted once after the controller resumes and the > delay between resume and reconnect is configurable via the > ReconnectAudioDelay key in the General settings. The 5s delay was chosen > arbitrarily and I think anywhere up to 10s is probably ok. A longer > delay is better to account for spurious wakeups and Wi-Fi reconnection > time (avoiding any co-ex issues) at the downside of reconnection speed. > > Here are the tests I have done with this: > - Single suspend and verified the headphones reconnect > - Suspend stress test for 25 iterations and verify both Wi-Fi and > Bluetooth audio reconnect on resume. (Ran with wake minimum time of > 10s) > - Suspend test with wake time < 5s to verify that BT reconnect isn't > attempted. Ran 5 iterations with low wake time and then let it stay > awake to confirm reconnect finally completed after 5s+ wake time. > - Suspend test with wake time between 3s - 6s. Ran with 5 iterations and > verified it wasn't connected at the end. A connection attempt was > made but not completed due to suspend. A reconnect attempt was not > made afterwards, which is by design. > > Luiz@ Marcel@: Does this sound ok (give up after an attempt)? > > I've tested this on a Pixelbook Go (AC-9260 controller) and HP > Chromebook 14a (RTL8822CE controller) with GID6B headset. I'm hoping to > test this with a few more headsets to make sure this is ok and I'm > looking for some early feedback. > > Thanks > Abhishek > > > > Abhishek Pandit-Subedi (3): > mgmt: Add controller suspend and resume events > monitor: Add btmon support for Suspend and Resume events > adapter: Reconnect audio on controller resume > > lib/mgmt.h | 14 +++++++++ > monitor/packet.c | 55 ++++++++++++++++++++++++++++++++ > src/adapter.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ > src/device.c | 27 ++++++++++++++++ > src/device.h | 2 ++ > src/main.conf | 6 ++++ > 6 files changed, 186 insertions(+) > > -- > 2.28.0.rc0.142.g3c755180ce-goog >