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