libhci update

[Maksim Yevmenkin]

On Thu, May 14, 2009 at 10:33 AM, Iain Hibbert <plunky at rya-online.net> wrote:

[...]

>> > but I think this test might be bogus? manpage implies that the caller
>> > provides a buffer but we allocate one..
>>
>> no, the test is correct. yes, we allocate buffer internally, but we
>> need to return pointer to the buffer back to the caller. so, ii is
>> basically ii is struct bt_devinquiry **. perhaps language in the man
>> page is not clear enough?
>
> Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a
> spelling mistake earlier but I didn't note it :), will examine it in
> detail later. I'm trying to think of another function that does similar to
> copy the language from, perhaps asprintf()?

yeah, may be. please feel free to correct my english :)

> btw do you know what devinfo->role_switch_info might contain?  I have
> link_policy_info which presumably contains the following flags

that is for 'forceful' role switch when we are accepting connection.
basically always try to become master on any connection (or not).

[...]

>> > also, I'm not sure that the timeout is handled right; the bt_devrecv()
>> > uses the complete timeout each time but the time endpoint might need to be
>> > calculated so that time-to-end can be used?
>>
>> well, yes. bt_devrecv() was envisioned as "one-shot" call. the only
>> case, imo, where it can restart internally with the same timeout is
>> when select is interrupted by a signal.
>
> I think the timeout should probably act the same way as in bt_devreq(),
> but I thought there could be close calls at the end because of the integer
> arithmetic.

sorry, are we talking about bt_devrecv() in isolation, or about
bt_devinquiry() usage of bt_devrecv().

in other words, are you saying we should fix bt_devinquiry() and make
sure that is decreases timeout with every call to bt_devrecv()?

>> > Also I'm wondering what to do in the case bt_devrecv() does actually time
>> > out - what can it mean and should we [attempt to] cancel the inquiry?
>>
>> ahh, but in case of bt_devinquiry() it probably does not matter that
>> much because inquiry itself is limited by the "length" parameter. so
>> we have to receive something back from the device. i was thinking to
>> pass -1 as timeout to bt_devrecv() in this particular case, but
>> decided not to do it (try harder to exit the bt_devinquiry()).
>
> mm, -1 is tempting but I think its better to error timeout even if the
> device is left in a weird state. At least the user won't be left waiting..

my thoughts exactly :)

> I'll continue to work on it because a successful exit must wait until the
> device has exited inquiry mode. (I noticed that you can't do things like
> get-remote-name when still in inquiry mode, at least on some devices)

yes, inquiry is weird (from baseband point of view) procedure. device
basically has to blast on the range of frequencies and wait for
someone to respond. technically, nothing prevents device from doing
other rf activity, but some devices choose not to do it.

thanks,
max