Return-Path: MIME-Version: 1.0 In-Reply-To: <24D2CD11-D43B-4F53-8A7C-175934A54C87@holtmann.org> References: <1411746855-9936-1-git-send-email-fons@spotify.com> <24D2CD11-D43B-4F53-8A7C-175934A54C87@holtmann.org> From: Alfonso Acosta Date: Mon, 29 Sep 2014 12:59:55 +0200 Message-ID: Subject: Re: [PATCH v3] Bluetooth: Add HCI_AUTO_CONN_DIRECT_REPORT_IND To: Marcel Holtmann Cc: linux-bluetooth@vger.kernel.org Content-Type: multipart/alternative; boundary=90e6ba6e87a01de8310504322d39 List-ID: --90e6ba6e87a01de8310504322d39 Content-Type: text/plain; charset=UTF-8 Hi Marcel, > I am not really convinced that this is a good idea. In general either you > really want Action 0x01 and only accept incoming connection or you want > Action 0x02 and connect to the device no matter what. > We are dealing with an HID device which sends meaningful information in ADV_IND reports and to which we want to connect when receiving ADV_DIRECT_IND reports. Without kernel support for auto-connecting on ADV_IND while still forwarding ADV_DIRECT_IND to userland, we are forced to keep active scanning on so that the content of ADV_IND reports isn't lost. We would of course like to avoid active scanning when possible, hence the reason on the patch. Originally I had the idea that the advertising data that you receive from > ADV_IND when Action 0x02 is in play gets also included in Device Connected > event. In our particular case, based on the content of ADV_IND we may not want to or simply can't connect to the device right away. In other words, the Device Connected event may never arrive (if the connection fails) and if it does, it's already too late to decide whether we want to connect or not. One could argue that the device should be broadcasting ADV_NONCONN_IND instead, but I don't think it makes it non-compliant. Johan told me on IRC that, as opposed to introducing HCI_AUTO_CONN_DIRECT_REPORT_IND, modifying HCI_AUTO_CONN_DIRECT to also forward ADV_IND to userland in Device Found events could be considered. Are you open to this idea? -- Alfonso Acosta Embedded Systems Engineer at Spotify Birger Jarlsgatan 61, Stockholm, Sweden http://www.spotify.com --90e6ba6e87a01de8310504322d39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marcel,


I am not really convinced that this is a good idea. In general eithe= r you really want Action 0x01 and only accept incoming connection or you wa= nt Action 0x02 and connect to the device no matter what.

We are dealing with an HID device which sends meaningful = information in=C2=A0ADV_IND=C2=A0reports and to which we want to connec= t=C2=A0when receiving=C2=A0ADV_DIRECT_IND reports.

Without kernel support for=C2=A0auto-connecting=C2= =A0on ADV_IND while still forwarding=C2=A0ADV_DIRECT_= IND to userland,=C2=A0we are forced to keep active scanning on s= o that the content of=C2=A0ADV_IND=C2=A0reports isn&#= 39;t lost.

We would of course like to avoid active scanning when pos= sible, hence the reason on the patch.

Originally I had the idea that the advertising data that you receive from A= DV_IND when Action 0x02 is in play gets also included in Device Connected e= vent.

In our particular case, based on the= content of ADV_IND we may not want to or simply can't connect to the d= evice right away. In other words, the Device Connected event may never arri= ve (if the connection fails) and if it does, it's already too late to d= ecide whether we want to connect or not.

One could argue that the de= vice should be broadcasting ADV_NONCONN_IND instead, but I don't think = it makes it non-compliant.=C2=A0

Johan told me on IRC that, as oppos= ed to introducing HCI_AUTO_CONN_DIRECT_REPORT_IND, modifying=C2=A0HCI_A= UTO_CONN_DIRECT to also forward=C2=A0ADV_IND to userland in Device F= ound events could be considered. Are you open to this idea?

=C2=A0
--
Alfonso Acosta

Emb= edded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
--90e6ba6e87a01de8310504322d39--