Hi Johan,
So please ignore this patch.
On Fri, Apr 29, 2011 at 2:56 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote:
> Hi Claudio,
>
> On Fri, Apr 29, 2011, Claudio Takahasi wrote:
>> > On Fri, Apr 29, 2011 at 1:34 AM, Claudio Takahasi
>> > <claudio.takahasi@xxxxxxxxxxxxx> wrote:
>> >> Infer that the found device is a legacy device based on the presence
>> >> of its name in the storage is wrong.
>> >> ---
>> >> Âsrc/event.c | Â Â2 --
>> >> Â1 files changed, 0 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/src/event.c b/src/event.c
>> >> index 5373e33..b873000 100644
>> >> --- a/src/event.c
>> >> +++ b/src/event.c
>> >> @@ -481,8 +481,6 @@ void btd_event_device_found(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
>> >>
>> >> Â Â Â Âif (data)
>> >> Â Â Â Â Â Â Â Âlegacy = FALSE;
>> >> - Â Â Â else if (name == NULL)
>> >> - Â Â Â Â Â Â Â legacy = TRUE;
>> >> Â Â Â Âelse if (read_remote_features(local, peer, NULL, features) == 0) {
>> >> Â Â Â Â Â Â Â Âif (features[0] & 0x01)
>> >> Â Â Â Â Â Â Â Â Â Â Â Âlegacy = FALSE;
>> >> --
>> >
>> > That was some use of it, but I can't remember now, maybe some broken
>> > stack which has feature bits broken or we do actually infer if we ever
>> > connect to the device before trying to read its features from the
>> > storage.
>> >
>> >
>> > --
>> > Luiz Augusto von Dentz
>> > Computer Engineer
>> >
>>
>> I found the commit that introduced this code, but it is still not clear to me:
>> 989c60c0b9c96edf1fbdf80356abf05bac336673
>
> I think the logic has gone like this: we get the remote features as a
> side effect of a successful remote name request, so by checking for the
> name first we don't do an unnecessary file-system lookup.
I got the idea, I will keep the same approach in the discovery cleanup patches.
So, if I understood correctly, in the case that it is the first the
device is seen(name is unknown) and EIR data is not sent the
legacy=TRUE will be emitted.
In the first connection, the remote features will be retrieved
"automatically" by the kernel and user space will set "legacy"
variable based on the features bits. The updated legacy value will be
emitted only in the next discovery session.
BR,
Claudio
>
>> BTW: why this information needs to be exposed through the DeviceFound() signal?
>> It is not used internally in the adapter.c source.
>
> It's useful for pairing UIs. If a device is expected to produce legacy
> pairing when calling CreatePairedDevice the UI can ask the user for the
> PIN *before* calling CreatePairedDevice and thereby eliminate the risk of
> user response timeout locally.
>
> Johan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
