* Re: [PATCH obexd v1 1/4] build: BlueZ version 4.100 or later is required
From: Luiz Augusto von Dentz @ 2012-08-23 14:12 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZLWnOZZGWHb5dwbbAt9pQXxdYz7ULn7JYx9mmbhBs3phQ@mail.gmail.com>
Hi Syam,
On Thu, Aug 23, 2012 at 5:04 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Syam,
>
> On Wed, Aug 22, 2012 at 7:35 PM, Syam Sidhardhan <s.syam@samsung.com> wrote:
>> If we use the BlueZ version less than 4.100, then the following
>> compilation error happens.
>>
>> Error:
>> ======
>> btio/btio.c: In function ‘l2cap_connect’:
>> btio/btio.c:301:6: error: ‘struct sockaddr_l2’ has no member named
>> ‘l2_bdaddr_type’
>> btio/btio.c: In function ‘parse_set_opts’:
>> btio/btio.c:707:19: error: ‘BDADDR_BREDR’ undeclared (first use in
>> this function)
>> btio/btio.c:707:19: note: each undeclared identifier is reported only
>> once for each function it appears in
>> make[1]: *** [btio/btio.o] Error 1
>> make: *** [all] Error 2
>> ---
>
> Strange I don't get this error with 4.99, anyway I guess it is fine to
> bump 4.100
Patches 1,3 and 4 are now upstream, for the issue about glib Im
figuring out how to fix it properly.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH obexd v1 1/4] build: BlueZ version 4.100 or later is required
From: Luiz Augusto von Dentz @ 2012-08-23 14:04 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: linux-bluetooth
In-Reply-To: <1345653354-23720-1-git-send-email-s.syam@samsung.com>
Hi Syam,
On Wed, Aug 22, 2012 at 7:35 PM, Syam Sidhardhan <s.syam@samsung.com> wrote:
> If we use the BlueZ version less than 4.100, then the following
> compilation error happens.
>
> Error:
> ======
> btio/btio.c: In function ‘l2cap_connect’:
> btio/btio.c:301:6: error: ‘struct sockaddr_l2’ has no member named
> ‘l2_bdaddr_type’
> btio/btio.c: In function ‘parse_set_opts’:
> btio/btio.c:707:19: error: ‘BDADDR_BREDR’ undeclared (first use in
> this function)
> btio/btio.c:707:19: note: each undeclared identifier is reported only
> once for each function it appears in
> make[1]: *** [btio/btio.o] Error 1
> make: *** [all] Error 2
> ---
Strange I don't get this error with 4.99, anyway I guess it is fine to
bump 4.100
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Re : BLE -Multiple connection
From: Ajay KV @ 2012-08-23 13:50 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <CAJdJm_NkobxyO=Ks=hdMxNjHNb1jSMotNPCcLrtwq+bjKxkJYw@mail.gmail.com>
On 08/22/2012 12:01 PM, Anderson Lizardo wrote:
> Hi Ajay,
>
> On Wed, Aug 22, 2012 at 7:18 PM, Ajay KV<ajay.kv@globaledgesoft.com> wrote:
>> First of all, sorry for my ignorance . Following are the steps i did
>> in my test case. i am also using dual mode dongles , so as you said spec
>> is not allowing us to do this operation
>> [snip]
>
> I remembered that the Core spec mentions that it is not required for a
> controller to support more than one connection. Maybe it is the case
> for the dongles you have? In this case, the controller will not allow
> to send connectable advertising because of the active connection.
>
> (sorry, I could not find the section of the spec that mentions this)
>
> If you close the connection, are you able to run "hciconfig hci0
> leadv" again on "A"?
>
> Regards,
Hi ,
yes , exactly the moment the connection get terminates , i could able
to enable advertise again. The intresting point is that during connected
mode , even advertise disable is also giving the same "command
disallowed" error.
regards
^ permalink raw reply
* Re: PBAP + two-step download
From: Patrick Ohly @ 2012-08-23 12:24 UTC (permalink / raw)
To: Mikel Astiz; +Cc: Luiz Augusto von Dentz, Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <CANT-zCV-SW9B9JOoYV506yK+tH5xDNKeMtXf98NBDVJxVHyO5w@mail.gmail.com>
On Thu, 2012-08-23 at 13:59 +0200, Mikel Astiz wrote:
> Hi,
>
> On Thu, Aug 23, 2012 at 1:28 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
> >> Hi Patrick,
> >>
> >> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> >> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
> >> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> >> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> >> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
> >> >> > because the PullAll download doesn't include the information that is
> >> >> > necessary to get the full vcard later on. Any comments about my
> >> >> > proposals for fixing this (download into dir and/or add X- prop to
> >> >> > vcards)?
>
> This is a limitation in the PBAP specification, not the API.
Oops. I was assuming (without checking) that the information was
available at the protocol level and just getting thrown away when
returning it to the caller.
That of course renders the entire discussion mute, there's nothing in
obexd that can be done to make the two-step download more efficient.
Thanks for clarifying that.
> >> > I also don't expect it to work reliably, for example when there is a
> >> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
> >> > number also isn't unique (might have been added to two different persons
> >> > who are sharing the same address and phone).
> >>
> >> Yep, but that is the general problem isn't it?
> >
> > Right, but that doesn't mean that we have to start using a method that
> > is prone to this problem when there are better alternatives, like using
> > a known contact number in the current session and requesting that
> > directly.
>
> I don't see any problem here. Every single pass (with or without
> photos) would replace the previous cache. So being smart to match
> contacts is just about optimizing the number of writes to the
> database. We don't need to merge any contact at this point.
You are right, the second pass can simply use the same approach as the
first one, with photo data as additional information. My goal was to
optimize the second pass by limiting it to contacts which have photos
and not having to do the matching again.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: [PATCH BlueZ] gatt: GAP and GATT services are mandatory
From: Johan Hedberg @ 2012-08-23 12:15 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1345664329-30577-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Aug 22, 2012, Claudio Takahasi wrote:
> This patch fixes potential segmentation fault if the remote doesn't
> support GAP and GATT services.
> ---
> profiles/gatt/manager.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: PBAP + two-step download
From: Mikel Astiz @ 2012-08-23 11:59 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Luiz Augusto von Dentz, Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <1345721323.29868.443.camel@pohly-mobl1.fritz.box>
Hi,
On Thu, Aug 23, 2012 at 1:28 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
>> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> >> >> When we connect we attempt to
>> >> >> download the full phonebook which is cached for fast lookup but while
>> >> >> ringing we can download the full vcard including the picture.
This would be too slow, adding a noticeable delay to the user.
>> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
>> >> > because the PullAll download doesn't include the information that is
>> >> > necessary to get the full vcard later on. Any comments about my
>> >> > proposals for fixing this (download into dir and/or add X- prop to
>> >> > vcards)?
This is a limitation in the PBAP specification, not the API.
>> >> What about Search + Pull? If you have download the contact already you
>> >> have the name then you search by name, otherwise search by number,
>> >> with the response you can download the vcard with Pull.
>> >
>> > Isn't that very inefficient? One search request for each contact?
>>
>> It is, that why we need to download this info before hand, but since
>> we cannot depend on the contact handle being unique across the
>> sessions
>
> We don't - the two steps would be in the same PBAP session. In the
> future it might even work across sessions, once the Bluetooth consortium
> adds cross-session references (planned for 2013, as far as I know).
The vcard handled are stable within the session, but AFAIK there is no
link between the PullAll result and the vcard handles. Searching
doesn't solve anything because you still need to use PullAll
(individually pulling is too slow), so you still miss the link.
>> > I also don't expect it to work reliably, for example when there is a
>> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
>> > number also isn't unique (might have been added to two different persons
>> > who are sharing the same address and phone).
>>
>> Yep, but that is the general problem isn't it?
>
> Right, but that doesn't mean that we have to start using a method that
> is prone to this problem when there are better alternatives, like using
> a known contact number in the current session and requesting that
> directly.
I don't see any problem here. Every single pass (with or without
photos) would replace the previous cache. So being smart to match
contacts is just about optimizing the number of writes to the
database. We don't need to merge any contact at this point.
Cheers,
Mikel
^ permalink raw reply
* Re: PBAP + two-step download
From: Luiz Augusto von Dentz @ 2012-08-23 11:57 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <1345721323.29868.443.camel@pohly-mobl1.fritz.box>
Hi Patrick,
On Thu, Aug 23, 2012 at 2:28 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
>> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> >> >> When we connect we attempt to
>> >> >> download the full phonebook which is cached for fast lookup but while
>> >> >> ringing we can download the full vcard including the picture.
>> >> >
>> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
>> >> > because the PullAll download doesn't include the information that is
>> >> > necessary to get the full vcard later on. Any comments about my
>> >> > proposals for fixing this (download into dir and/or add X- prop to
>> >> > vcards)?
>> >>
>> >> What about Search + Pull? If you have download the contact already you
>> >> have the name then you search by name, otherwise search by number,
>> >> with the response you can download the vcard with Pull.
>> >
>> > Isn't that very inefficient? One search request for each contact?
>>
>> It is, that why we need to download this info before hand, but since
>> we cannot depend on the contact handle being unique across the
>> sessions
>
> We don't - the two steps would be in the same PBAP session. In the
> future it might even work across sessions, once the Bluetooth consortium
> adds cross-session references (planned for 2013, as far as I know).
I suppose this will also mean contacts/handle updates will also have
to be supported. Anyway it is not ready now so we can't really depend
on that.
>> > I also don't expect it to work reliably, for example when there is a
>> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
>> > number also isn't unique (might have been added to two different persons
>> > who are sharing the same address and phone).
>>
>> Yep, but that is the general problem isn't it?
>
> Right, but that doesn't mean that we have to start using a method that
> is prone to this problem when there are better alternatives, like using
> a known contact number in the current session and requesting that
> directly.
Well it seems that your method is also error prone, because there is
still a chance the contact handle has been invalidated, removed or
something like that which can cause Pull to fail. Anyway when I said
it is the general problem I was referring to number or name mapping to
multiple contacts and that doesn't matter if you resolve then locally
or search first to only then pull with handles found, the fact is you
can find more than one matching regardless of method you use.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: PBAP + two-step download
From: Patrick Ohly @ 2012-08-23 11:28 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <CABBYNZJ0TSX53ZF5_SgamiLSMFLAsrcFYVGNNk=QbEExn-AC2A@mail.gmail.com>
On Thu, 2012-08-23 at 14:06 +0300, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
> >> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> >> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> >> >> When we connect we attempt to
> >> >> download the full phonebook which is cached for fast lookup but while
> >> >> ringing we can download the full vcard including the picture.
> >> >
> >> > Even if we wanted to do it that way, it also wouldn't work at the moment
> >> > because the PullAll download doesn't include the information that is
> >> > necessary to get the full vcard later on. Any comments about my
> >> > proposals for fixing this (download into dir and/or add X- prop to
> >> > vcards)?
> >>
> >> What about Search + Pull? If you have download the contact already you
> >> have the name then you search by name, otherwise search by number,
> >> with the response you can download the vcard with Pull.
> >
> > Isn't that very inefficient? One search request for each contact?
>
> It is, that why we need to download this info before hand, but since
> we cannot depend on the contact handle being unique across the
> sessions
We don't - the two steps would be in the same PBAP session. In the
future it might even work across sessions, once the Bluetooth consortium
adds cross-session references (planned for 2013, as far as I know).
> > I also don't expect it to work reliably, for example when there is a
> > "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
> > number also isn't unique (might have been added to two different persons
> > who are sharing the same address and phone).
>
> Yep, but that is the general problem isn't it?
Right, but that doesn't mean that we have to start using a method that
is prone to this problem when there are better alternatives, like using
a known contact number in the current session and requesting that
directly.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: PBAP + two-step download
From: Luiz Augusto von Dentz @ 2012-08-23 11:06 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <1345716915.29868.426.camel@pohly-mobl1.fritz.box>
Hi Patrick,
On Thu, Aug 23, 2012 at 1:15 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> >> Hi Patrick,
>> >>
>> >> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> >> > Hello!
>> >> >
>> >> > For IVI use cases, Mikel and I were discussing how a phone's address
>> >> > book could be cached intelligently by an IVI head unit. The rough idea
>> >> > is that first all contacts get pulled without PHOTO data. This data is
>> >> > used to match the current phone address book with some potentially
>> >> > cached local data. Then in a second step, the PHOTO data of all contacts
>> >> > is requested (*). This is all done in the same PBAP session, so the
>> >> > numbering of contacts is the same in both steps.
>> >> >
>> >> > The goal is to get the essential data (names, phone numbers) quickly and
>> >> > then add pictures later on.
>> >>
>> >> I think it is a good idea, but what about to download the full contact
>> >> vcard only when it is to be displayed?
>> >
>> > There are other use cases that depend on having all data locally, for
>> > example merging address books from several different phones into a
>> > single unified address book. Browsing that unified address book is
>> > expected to include photo data, so loading that on demand isn't an
>> > option.
>>
>> How you deal with conflicts such as different pictures, names for the
>> same contact? In theory merging seems to be the right thing to do but
>> if you have used e.g. Nokia N9 it can cause many problems where the
>> same phone number can be found in multiple contacts. What if we got in
>> a situation where the IVI system show 'Joe' but the phone shows "John"
>> with a different picture, I guess this is supposed to be consistent
>> with the phone that is handling the call.
>
> That wasn't mentioned before as a requirement. I guess it could be done
> so that the local cache is used as a first approximation while the phone
> is asked to provide the final answer.
Yep, that is my understanding too and since the phone has to give the
final answer anyway, we might just download the essential things like
name and number the rest is filled on demand, obviously if we already
have done this in a previous session we keep in storage.
>> >> When we connect we attempt to
>> >> download the full phonebook which is cached for fast lookup but while
>> >> ringing we can download the full vcard including the picture.
>> >
>> > Even if we wanted to do it that way, it also wouldn't work at the moment
>> > because the PullAll download doesn't include the information that is
>> > necessary to get the full vcard later on. Any comments about my
>> > proposals for fixing this (download into dir and/or add X- prop to
>> > vcards)?
>>
>> What about Search + Pull? If you have download the contact already you
>> have the name then you search by name, otherwise search by number,
>> with the response you can download the vcard with Pull.
>
> Isn't that very inefficient? One search request for each contact?
It is, that why we need to download this info before hand, but since
we cannot depend on the contact handle being unique across the
sessions I don't see any other option except if we have fetched the
handle in the same session then we can skip Search and Pull directly.
> I also don't expect it to work reliably, for example when there is a
> "John Doe, Sr." and John Doe, Jr." in the same address book. Phone
> number also isn't unique (might have been added to two different persons
> who are sharing the same address and phone).
Yep, but that is the general problem isn't it? When you got a call you
just have the number if it maps to multiple contacts that is something
the user interface has to handle.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: PBAP + two-step download
From: Patrick Ohly @ 2012-08-23 10:15 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <CABBYNZJGDM7jg8ETGJSQHXUzqx6Lui1Jj8DhSya0+b+xhNp9Ew@mail.gmail.com>
On Thu, 2012-08-23 at 11:15 +0300, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> >> Hi Patrick,
> >>
> >> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> >> > Hello!
> >> >
> >> > For IVI use cases, Mikel and I were discussing how a phone's address
> >> > book could be cached intelligently by an IVI head unit. The rough idea
> >> > is that first all contacts get pulled without PHOTO data. This data is
> >> > used to match the current phone address book with some potentially
> >> > cached local data. Then in a second step, the PHOTO data of all contacts
> >> > is requested (*). This is all done in the same PBAP session, so the
> >> > numbering of contacts is the same in both steps.
> >> >
> >> > The goal is to get the essential data (names, phone numbers) quickly and
> >> > then add pictures later on.
> >>
> >> I think it is a good idea, but what about to download the full contact
> >> vcard only when it is to be displayed?
> >
> > There are other use cases that depend on having all data locally, for
> > example merging address books from several different phones into a
> > single unified address book. Browsing that unified address book is
> > expected to include photo data, so loading that on demand isn't an
> > option.
>
> How you deal with conflicts such as different pictures, names for the
> same contact? In theory merging seems to be the right thing to do but
> if you have used e.g. Nokia N9 it can cause many problems where the
> same phone number can be found in multiple contacts. What if we got in
> a situation where the IVI system show 'Joe' but the phone shows "John"
> with a different picture, I guess this is supposed to be consistent
> with the phone that is handling the call.
That wasn't mentioned before as a requirement. I guess it could be done
so that the local cache is used as a first approximation while the phone
is asked to provide the final answer.
> >> When we connect we attempt to
> >> download the full phonebook which is cached for fast lookup but while
> >> ringing we can download the full vcard including the picture.
> >
> > Even if we wanted to do it that way, it also wouldn't work at the moment
> > because the PullAll download doesn't include the information that is
> > necessary to get the full vcard later on. Any comments about my
> > proposals for fixing this (download into dir and/or add X- prop to
> > vcards)?
>
> What about Search + Pull? If you have download the contact already you
> have the name then you search by name, otherwise search by number,
> with the response you can download the vcard with Pull.
Isn't that very inefficient? One search request for each contact?
I also don't expect it to work reliably, for example when there is a
"John Doe, Sr." and John Doe, Jr." in the same address book. Phone
number also isn't unique (might have been added to two different persons
who are sharing the same address and phone).
> Btw, Im changing the PhonebookAccess API so the parameters like order,
> format and filter is passed in the same method call so the client
> doesn't have to call multiple methods for setting those.
Sure, why not.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: PBAP + two-step download
From: Luiz Augusto von Dentz @ 2012-08-23 8:15 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <1345707325.29868.403.camel@pohly-mobl1.fritz.box>
Hi Patrick,
On Thu, Aug 23, 2012 at 10:35 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> > Hello!
>> >
>> > For IVI use cases, Mikel and I were discussing how a phone's address
>> > book could be cached intelligently by an IVI head unit. The rough idea
>> > is that first all contacts get pulled without PHOTO data. This data is
>> > used to match the current phone address book with some potentially
>> > cached local data. Then in a second step, the PHOTO data of all contacts
>> > is requested (*). This is all done in the same PBAP session, so the
>> > numbering of contacts is the same in both steps.
>> >
>> > The goal is to get the essential data (names, phone numbers) quickly and
>> > then add pictures later on.
>>
>> I think it is a good idea, but what about to download the full contact
>> vcard only when it is to be displayed?
>
> There are other use cases that depend on having all data locally, for
> example merging address books from several different phones into a
> single unified address book. Browsing that unified address book is
> expected to include photo data, so loading that on demand isn't an
> option.
How you deal with conflicts such as different pictures, names for the
same contact? In theory merging seems to be the right thing to do but
if you have used e.g. Nokia N9 it can cause many problems where the
same phone number can be found in multiple contacts. What if we got in
a situation where the IVI system show 'Joe' but the phone shows "John"
with a different picture, I guess this is supposed to be consistent
with the phone that is handling the call.
> What you describe is part of the plan, as fallback when the data is not
> (yet) available locally.
>
>> When we connect we attempt to
>> download the full phonebook which is cached for fast lookup but while
>> ringing we can download the full vcard including the picture.
>
> Even if we wanted to do it that way, it also wouldn't work at the moment
> because the PullAll download doesn't include the information that is
> necessary to get the full vcard later on. Any comments about my
> proposals for fixing this (download into dir and/or add X- prop to
> vcards)?
What about Search + Pull? If you have download the contact already you
have the name then you search by name, otherwise search by number,
with the response you can download the vcard with Pull.
Btw, Im changing the PhonebookAccess API so the parameters like order,
format and filter is passed in the same method call so the client
doesn't have to call multiple methods for setting those.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: PBAP + two-step download
From: Patrick Ohly @ 2012-08-23 7:35 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <CABBYNZL_P-if4JxM5K8jXvc86aJWXPfoY2xJAGpSV784XWABww@mail.gmail.com>
On Thu, 2012-08-23 at 01:13 +0300, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > Hello!
> >
> > For IVI use cases, Mikel and I were discussing how a phone's address
> > book could be cached intelligently by an IVI head unit. The rough idea
> > is that first all contacts get pulled without PHOTO data. This data is
> > used to match the current phone address book with some potentially
> > cached local data. Then in a second step, the PHOTO data of all contacts
> > is requested (*). This is all done in the same PBAP session, so the
> > numbering of contacts is the same in both steps.
> >
> > The goal is to get the essential data (names, phone numbers) quickly and
> > then add pictures later on.
>
> I think it is a good idea, but what about to download the full contact
> vcard only when it is to be displayed?
There are other use cases that depend on having all data locally, for
example merging address books from several different phones into a
single unified address book. Browsing that unified address book is
expected to include photo data, so loading that on demand isn't an
option.
What you describe is part of the plan, as fallback when the data is not
(yet) available locally.
> When we connect we attempt to
> download the full phonebook which is cached for fast lookup but while
> ringing we can download the full vcard including the picture.
Even if we wanted to do it that way, it also wouldn't work at the moment
because the PullAll download doesn't include the information that is
necessary to get the full vcard later on. Any comments about my
proposals for fixing this (download into dir and/or add X- prop to
vcards)?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* RE: [PATCH] Add support for downloading binary patch.
From: Chen, Peng @ 2012-08-23 3:01 UTC (permalink / raw)
To: marcel@holtmann.org; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1343788938-7420-1-git-send-email-pengchen@qca.qualcomm.com>
SGkgTWFyY2VsLA0KDQpTb3JyeSB0byB0cm91YmxlIHlvdS4gSSB3YW50IHRvIGtub3cgd2hlbiB3
aWxsIHRoaXMgcGF0Y2ggY2FuIGJlIGFwcGxpZWQ/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBDaGVuLCBQZW5nIA0KU2VudDogMjAxMsTqONTCMcjVIDEwOjQyDQpUbzogbWFy
Y2VsQGhvbHRtYW5uLm9yZw0KQ2M6IGxpbnV4LWJsdWV0b290aEB2Z2VyLmtlcm5lbC5vcmc7IENo
ZW4sIFBlbmcNClN1YmplY3Q6IFtQQVRDSF0gQWRkIHN1cHBvcnQgZm9yIGRvd25sb2FkaW5nIGJp
bmFyeSBwYXRjaC4NCg0KLS0tDQogdG9vbHMvaGNpYXR0YWNoX2F0aDNrLmMgfCAgMTMzICsrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tDQogMSBmaWxlIGNoYW5n
ZWQsIDExNSBpbnNlcnRpb25zKCspLCAxOCBkZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdpdCBhL3Rv
b2xzL2hjaWF0dGFjaF9hdGgzay5jIGIvdG9vbHMvaGNpYXR0YWNoX2F0aDNrLmMgaW5kZXggMjMy
MDhjNi4uZWMzOWY1ZSAxMDA2NDQNCi0tLSBhL3Rvb2xzL2hjaWF0dGFjaF9hdGgzay5jDQorKysg
Yi90b29scy9oY2lhdHRhY2hfYXRoM2suYw0KQEAgLTQ5OCw2ICs0OTgsMzEgQEAgc3RhdGljIGlu
dCBzZXRfcGF0Y2hfcmFtKGludCBkZXYsIGNoYXIgKnBhdGNoX2xvYywgaW50IGxlbikNCiAJcmV0
dXJuIGVycjsNCiB9DQogDQorc3RhdGljIGludCBzZXRfcGF0Y2hfcmFtX2RmdShpbnQgZGV2LCB1
bnNpZ25lZCBpbnQgYWRkcikgew0KKwlpbnQgZXJyOw0KKwl1aW50OF90IGNtZFsyMF07DQorCXVp
bnQ4X3QgKmV2ZW50Ow0KKwl1aW50OF90ICpsb2NfcHRyID0gJmNtZFs3XTsNCisNCisJbG9hZF9o
Y2lfcHNfaGRyKGNtZCwgU0VUX1BBVENIX1JBTV9JRCwgQUREUkVTU19MRU4sIDApOw0KKw0KKwls
b2NfcHRyWzBdID0gKHVuc2lnbmVkIGNoYXIpKGFkZHIgJiAweGZmKTsNCisJbG9jX3B0clsxXSA9
ICh1bnNpZ25lZCBjaGFyKSgoYWRkciA+PiA4KSAmIDB4ZmYpOw0KKwlsb2NfcHRyWzJdID0gKHVu
c2lnbmVkIGNoYXIpKChhZGRyID4+IDE2KSAmIDB4ZmYpOw0KKwlsb2NfcHRyWzNdID0gKHVuc2ln
bmVkIGNoYXIpKChhZGRyID4+IDI0KSAmIDB4ZmYpOw0KKw0KKwllcnIgPSBzZW5kX2hjaV9jbWRf
c3luYyhkZXYsIGNtZCwgU0VUX1BBVENIX1JBTV9DTURfU0laRSwgJmV2ZW50KTsNCisJaWYgKGVy
ciA8IDApDQorCQlyZXR1cm4gZXJyOw0KKw0KKwllcnIgPSByZWFkX3BzX2V2ZW50KGV2ZW50LCBI
Q0lfUFNfQ01EX09DRik7DQorDQorCWZyZWUoZXZlbnQpOw0KKw0KKwlyZXR1cm4gZXJyOw0KK30N
CisNCiAjZGVmaW5lIFBBVENIX0xPQ19LRVkgICAgIkRBOiINCiAjZGVmaW5lIFBBVENIX0xPQ19T
VFJJTkdfTEVOICAgIDgNCiBzdGF0aWMgaW50IHBzX3BhdGNoX2Rvd25sb2FkKGludCBmZCwgRklM
RSAqc3RyZWFtKSBAQCAtNTU5LDYgKzU4NCw2MCBAQCBzdGF0aWMgaW50IHBzX3BhdGNoX2Rvd25s
b2FkKGludCBmZCwgRklMRSAqc3RyZWFtKQ0KIAlyZXR1cm4gcGF0Y2hfY291bnQ7DQogfQ0KIA0K
K3N0cnVjdCBBVEhERlVfRklMRUhEUiB7DQorCXVpbnQzMl90IEFGX1dyaXRlQWRkcjsgICAvKiBk
b3dubG9hZCB0aGUgZmlsZSB0byBhZl93cml0ZV9hZGRyICovDQorCXVpbnQzMl90IEFGX0VudHJ5
QWRkcjsgICAvKiB0aGUgYXBwbGljYXRpb24gcHJvZ3JhbSdzIGVudHJ5IGFkZHJlc3MgKi8NCisJ
dWludDMyX3QgQUZfRmlsZUxlbmd0aDsgIC8qIHRoZSBhcHBsaWNhdGlvbiBwcm9ncmFtJ3MgbGVu
Z3RoICovDQorCXVpbnQzMl90IEFGX0ZpbGVDUkM7ICAgICAvKiBjcmMgdGhlIGFwcGxpY2F0aW9u
ICovDQorCXVpbnQzMl90IEFGX0ZpbGVUeXBlOyAgICAvKiB0aGUgZmlsZSB0eXBlICovDQorfTsN
CisNCisjZGVmaW5lIERGVV9HQVAgMTINCisNCitzdGF0aWMgaW50IHBzX3BhdGNoX2Rvd25sb2Fk
X2RmdShpbnQgZmQsIEZJTEUgKnN0cmVhbSkgew0KKwlzdHJ1Y3QgQVRIREZVX0ZJTEVIRFIgZGZ1
X2hkcjsNCisJdWludDhfdCBkZnVfZ2FwW0RGVV9HQVBdOw0KKwlpbnQgYnl0ZV9jbnQgPSAwOw0K
KwlpbnQgcGF0Y2hfY291bnQgPSAwOw0KKw0KKwlpZiAoKGZyZWFkKCh1aW50OF90ICopJmRmdV9o
ZHIsIDEsIHNpemVvZihkZnVfaGRyKSwgc3RyZWFtKSkNCisJCQk8IHNpemVvZihkZnVfaGRyKSkN
CisJCXJldHVybiAtMTsNCisJc2V0X3BhdGNoX3JhbV9kZnUoZmQsIGRmdV9oZHIuQUZfV3JpdGVB
ZGRyKTsNCisNCisJaWYgKChmcmVhZChkZnVfZ2FwLCAxLCBERlVfR0FQLCBzdHJlYW0pKSA8IERG
VV9HQVApDQorCQlyZXR1cm4gLTE7DQorDQorCWJ5dGVfY250ID0gZGZ1X2hkci5BRl9GaWxlTGVu
Z3RoIC0gREZVX0dBUDsNCisNCisJd2hpbGUgKGJ5dGVfY250ID4gMCkgew0KKwkJdWludDhfdCBj
bWRbSENJX01BWF9DTURfU0laRV07DQorCQlzdHJ1Y3QgcGF0Y2hfZW50cnkgcGF0Y2g7DQorDQor
CQlpZiAoYnl0ZV9jbnQgPiBNQVhfUEFUQ0hfQ01EKQ0KKwkJCXBhdGNoLmxlbiA9IE1BWF9QQVRD
SF9DTUQ7DQorCQllbHNlDQorCQkJcGF0Y2gubGVuID0gYnl0ZV9jbnQ7DQorDQorCQlpZiAoKGZy
ZWFkKHBhdGNoLmRhdGEsIDEsIHBhdGNoLmxlbiwgc3RyZWFtKSkNCisJCQkJPCAodWludDE2X3Qp
cGF0Y2gubGVuKQ0KKwkJCXJldHVybiAtMTsNCisNCisJCWxvYWRfaGNpX3BzX2hkcihjbWQsIFdS
SVRFX1BBVENILCBwYXRjaC5sZW4sIHBhdGNoX2NvdW50KTsNCisJCW1lbWNweSgmY21kW0hDSV9Q
U19DTURfSERSX0xFTl0sIHBhdGNoLmRhdGEsIHBhdGNoLmxlbik7DQorDQorCQlpZiAod3JpdGVf
Y21kKGZkLCBjbWQsIHBhdGNoLmxlbiArIEhDSV9QU19DTURfSERSX0xFTikgPCAwKQ0KKwkJCXJl
dHVybiAtMTsNCisNCisJCXBhdGNoX2NvdW50Kys7DQorCQlieXRlX2NudCA9IGJ5dGVfY250IC0g
cGF0Y2gubGVuOw0KKwl9DQorDQorCWlmICh3cml0ZV9wc19jbWQoZmQsIEVOQUJMRV9QQVRDSCwg
MCkgPCAwKQ0KKwkJcmV0dXJuIC0xOw0KKwlyZXR1cm4gMTsNCit9DQogI2RlZmluZSBQU19SQU1f
U0laRSAyMDQ4DQogDQogc3RhdGljIGludCBwc19jb25maWdfZG93bmxvYWQoaW50IGZkLCBpbnQg
dGFnX2NvdW50KSBAQCAtNTg4LDE5ICs2NjcsMzEgQEAgc3RhdGljIHZvaWQgZ2V0X3BzX2ZpbGVf
bmFtZSh1aW50MzJfdCBkZXZ0eXBlLCB1aW50MzJfdCByb21fdmVyc2lvbiwNCiAJc25wcmludGYo
cGF0aCwgTUFYUEFUSExFTiwgIiVzJXgvJXMiLCBGV19QQVRILCByb21fdmVyc2lvbiwgZmlsZW5h
bWUpOyAgfQ0KIA0KLSNkZWZpbmUgUEFUQ0hfRklMRSAgICAgICAgIlJhbVBhdGNoLnR4dCINCisj
ZGVmaW5lIFRYVF9QQVRDSF9GSUxFICAgICAgICAiUmFtUGF0Y2gudHh0Ig0KKyNkZWZpbmUgREZV
X1BBVENIX0ZJTEUgICAgICAgICJBdGhyQlRfMHgwIg0KICNkZWZpbmUgRlBHQV9ST01fVkVSU0lP
TiAgMHg5OTk5OTk5OQ0KICNkZWZpbmUgUk9NX0RFVl9UWVBFICAgICAgMHhkZWFkYzBkZQ0KIA0K
LXN0YXRpYyB2b2lkIGdldF9wYXRjaF9maWxlX25hbWUodWludDMyX3QgZGV2X3R5cGUsIHVpbnQz
Ml90IHJvbV92ZXJzaW9uLA0KLQkJCQl1aW50MzJfdCBidWlsZF92ZXJzaW9uLCBjaGFyICpwYXRo
KQ0KK3N0YXRpYyB2b2lkIGdldF9maWxlX25hbWVfb2ZfcGF0Y2hfaW5fdHh0X2Zvcm1hdCh1aW50
MzJfdCBkZXZfdHlwZSwNCisJCXVpbnQzMl90IHJvbV92ZXJzaW9uLCB1aW50MzJfdCBidWlsZF92
ZXJzaW9uLCBjaGFyICpwYXRoKQ0KIHsNCiAJaWYgKHJvbV92ZXJzaW9uID09IEZQR0FfUk9NX1ZF
UlNJT04gJiYgZGV2X3R5cGUgIT0gUk9NX0RFVl9UWVBFICYmDQogCQkJCQlkZXZfdHlwZSAhPSAw
ICYmIGJ1aWxkX3ZlcnNpb24gPT0gMSkNCiAJCXBhdGhbMF0gPSAnXDAnOw0KIAllbHNlDQogCQlz
bnByaW50ZihwYXRoLCBNQVhQQVRITEVOLCAiJXMleC8lcyIsDQotCQkJCUZXX1BBVEgsIHJvbV92
ZXJzaW9uLCBQQVRDSF9GSUxFKTsNCisJCQkJRldfUEFUSCwgcm9tX3ZlcnNpb24sIFRYVF9QQVRD
SF9GSUxFKTsgfQ0KKw0KK3N0YXRpYyB2b2lkIGdldF9maWxlX25hbWVfb2ZfcGF0Y2hfaW5fZGZ1
X2Zvcm1hdCh1aW50MzJfdCBkZXZfdHlwZSwNCisJCXVpbnQzMl90IHJvbV92ZXJzaW9uLCB1aW50
MzJfdCBidWlsZF92ZXJzaW9uLCBjaGFyICpwYXRoKSB7DQorCWlmIChyb21fdmVyc2lvbiA9PSBG
UEdBX1JPTV9WRVJTSU9OICYmIGRldl90eXBlICE9IFJPTV9ERVZfVFlQRSAmJg0KKwkJCQkJZGV2
X3R5cGUgIT0gMCAmJiBidWlsZF92ZXJzaW9uID09IDEpDQorCQlwYXRoWzBdID0gJ1wwJzsNCisJ
ZWxzZQ0KKwkJc25wcmludGYocGF0aCwgTUFYUEFUSExFTiwgIiVzJXMleC5kZnUiLA0KKwkJCQlG
V19QQVRILCBERlVfUEFUQ0hfRklMRSwgcm9tX3ZlcnNpb24pOw0KIH0NCiANCiAjZGVmaW5lIFZF
UklGWV9DUkMgICA5DQpAQCAtNzk4LDcgKzg4OSw4IEBAIHN0YXRpYyBpbnQgYXRoX3BzX2Rvd25s
b2FkKGludCBmZCkNCiAJdWludDMyX3Qgcm9tX3ZlcnNpb24gPSAwOw0KIAl1aW50MzJfdCBidWls
ZF92ZXJzaW9uID0gMDsNCiAJdWludDMyX3QgZGV2X3R5cGUgPSAwOw0KLQljaGFyIHBhdGNoX2Zp
bGVbUEFUSF9NQVhdOw0KKwljaGFyIHBhdGNoX2ZpbGVfaW5fdHh0X2ZtdFtQQVRIX01BWF07DQor
CWNoYXIgcGF0Y2hfZmlsZV9pbl9kZnVfZm10W1BBVEhfTUFYXTsNCiAJY2hhciBwc19maWxlW1BB
VEhfTUFYXTsNCiAJRklMRSAqc3RyZWFtOw0KIA0KQEAgLTgyMyw3ICs5MTUsMTAgQEAgc3RhdGlj
IGludCBhdGhfcHNfZG93bmxvYWQoaW50IGZkKQ0KIAl9DQogDQogCWdldF9wc19maWxlX25hbWUo
ZGV2X3R5cGUsIHJvbV92ZXJzaW9uLCBwc19maWxlKTsNCi0JZ2V0X3BhdGNoX2ZpbGVfbmFtZShk
ZXZfdHlwZSwgcm9tX3ZlcnNpb24sIGJ1aWxkX3ZlcnNpb24sIHBhdGNoX2ZpbGUpOw0KKwlnZXRf
ZmlsZV9uYW1lX29mX3BhdGNoX2luX3R4dF9mb3JtYXQoZGV2X3R5cGUsIHJvbV92ZXJzaW9uLA0K
KwkJCWJ1aWxkX3ZlcnNpb24sIHBhdGNoX2ZpbGVfaW5fdHh0X2ZtdCk7DQorCWdldF9maWxlX25h
bWVfb2ZfcGF0Y2hfaW5fZGZ1X2Zvcm1hdChkZXZfdHlwZSwgcm9tX3ZlcnNpb24sDQorCQkJYnVp
bGRfdmVyc2lvbiwgcGF0Y2hfZmlsZV9pbl9kZnVfZm10KTsNCiANCiAJc3RyZWFtID0gZm9wZW4o
cHNfZmlsZSwgInIiKTsNCiAJaWYgKCFzdHJlYW0pIHsNCkBAIC04NDQsMjAgKzkzOSwyMiBAQCBz
dGF0aWMgaW50IGF0aF9wc19kb3dubG9hZChpbnQgZmQpDQogCSAqIEl0IGlzIG5vdCBuZWNlc3Nh
cnkgdGhhdCBQYXRjaCBmaWxlIGJlIGF2YWlsYWJsZSwNCiAJICogY29udGludWUgd2l0aCBQUyBP
cGVyYXRpb25zIGlmIHBhdGNoIGZpbGUgaXMgbm90IGF2YWlsYWJsZS4NCiAJICovDQotCWlmIChw
YXRjaF9maWxlWzBdID09ICdcMCcpDQotCQllcnIgPSAwOw0KLQ0KLQlzdHJlYW0gPSBmb3Blbihw
YXRjaF9maWxlLCAiciIpOw0KLQlpZiAoIXN0cmVhbSkNCi0JCWVyciA9IDA7DQotCWVsc2Ugew0K
LQkJcGF0Y2hfY291bnQgPSBwc19wYXRjaF9kb3dubG9hZChmZCwgc3RyZWFtKTsNCisJc3RyZWFt
ID0gZm9wZW4ocGF0Y2hfZmlsZV9pbl9kZnVfZm10LCAiciIpOw0KKwlpZiAocGF0Y2hfZmlsZV9p
bl9kZnVfZm10WzBdICE9ICdcMCcgJiYgc3RyZWFtKSB7DQorCQlwYXRjaF9jb3VudCA9IHBzX3Bh
dGNoX2Rvd25sb2FkX2RmdShmZCwgc3RyZWFtKTsNCiAJCWZjbG9zZShzdHJlYW0pOw0KLQ0KLQkJ
aWYgKHBhdGNoX2NvdW50IDwgMCkgew0KLQkJCWVyciA9IC1FSUxTRVE7DQotCQkJZ290byBkb3du
bG9hZF9jbXBsZXRlOw0KKwl9IGVsc2UgaWYgKHBhdGNoX2ZpbGVfaW5fdHh0X2ZtdFswXSAhPSAn
XDAnKSB7DQorCQlzdHJlYW0gPSBmb3BlbihwYXRjaF9maWxlX2luX3R4dF9mbXQsICJyIik7DQor
CQlpZiAoc3RyZWFtKSB7DQorCQkJcGF0Y2hfY291bnQgPSBwc19wYXRjaF9kb3dubG9hZChmZCwg
c3RyZWFtKTsNCisJCQlmY2xvc2Uoc3RyZWFtKTsNCiAJCX0NCisJfSBlbHNlDQorCQllcnIgPSAw
Ow0KKw0KKwlpZiAocGF0Y2hfY291bnQgPCAwKSB7DQorCQllcnIgPSAtRUlMU0VROw0KKwkJZ290
byBkb3dubG9hZF9jbXBsZXRlOw0KIAl9DQogDQogCWVyciA9IHBzX2NvbmZpZ19kb3dubG9hZChm
ZCwgdGFnX2NvdW50KTsNCi0tDQoxLjcuOS41DQoNCg==
^ permalink raw reply
* [PATCH RESEND RESEND] Bluetooth: Add support for Apple MacBook Pro 9,2
From: Shea Levy @ 2012-08-22 23:39 UTC (permalink / raw)
To: linux-bluetooth
Cc: linux-kernel, Johan Hedberg, Gustavo Padovan, Marcel Holtmann
$ usb-devices
<snip>
T: Bus=04 Lev=04 Prnt=04 Port=02 Cnt=01 Dev#= 9 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=821d Rev=00.86
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
<snip>
Signed-off-by: Shea Levy <shea@shealevy.com>
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index f077f4d..fdddb6e 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -73,6 +73,9 @@ static struct usb_device_id btusb_table[] = {
/* Apple MacBookPro8,2 */
{ USB_DEVICE(0x05ac, 0x821a) },
+ /* Apple MacBookPro9,2 */
+ { USB_DEVICE(0x05ac, 0x821d) },
+
/* Apple MacMini5,1 */
{ USB_DEVICE(0x05ac, 0x8281) },
--
1.7.11.4
^ permalink raw reply related
* Re: Re : BLE -Multiple connection
From: Ajay KV @ 2012-08-22 23:18 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <CAJdJm_NHy82UOofuQv1jGObJPg4MOj68R3D_xcBjNhCZWdy9Hw@mail.gmail.com>
On 08/22/2012 08:24 AM, Anderson Lizardo wrote:
> Hi Ajay,
>
> On Wed, Aug 22, 2012 at 4:49 PM, Ajay KV<ajay.kv@globaledgesoft.com> wrote:
>> I think we already discussed about this issue . following is
>> our previous conversation. please go through it
>
> Please, try to disable HTML on your email client and send plain text
> e-mails. It is difficult to follow your discussion with all this HTML.
> It is very likely people are not helping you because your emails are
> unreadable for a lot of people here.
>
> Much information is missing from your previous messages:
>
> 1) You did not provide the exact steps you followed (which commands
> you run after plugging the bluetooth dongle). Therefore it is
> difficult to reproduce your tests.
> 2) Your HCI dump output shows just the command giving error. This is
> not enough, you should provide the entire dump since the adapter was
> plugged, including the first "B to A" connection you described, and
> the second LE advertising attempt, otherwise it is not possible to
> identify at which state the LE controller is when the LE adv. enable
> command is issued.
>
> Also, do you realize that you are not allowed by the current Core spec
> v4.0 to have one dual mode device connected to another dual mode over
> the LE link? The spec says that a dual mode device in "connectable
> mode" (like device "A" in you original scenario) shall not be issuing
> connectable advertising over the LE channel. This is not enforced by
> the controller (and we actually do this for testing BlueZ to BlueZ
> connections over LE), but the spec explicitly forbids it.
>
> Regards,
Hi Anderson,
First of all, sorry for my ignorance . Following are the steps i did in
my test case. i am also using dual mode dongles , so as you said spec
is not allowing us to do this operation
In device A side:
1: Enable advertise using hciconfig hci0 leadv
2: run "l2test" tool in bluez as a server ( slight modification has
been made in this code, like we are explicitly making cid as 0x04 )
In Device B side:
1: Enable scanning using hcitool lescan
2: run "l2test -S <bdaddr A>" as a client ( slight modification has
been made in this code, like we are explicitly making cid as 0x04)
now the LE connection is established b/w A and B and data starts
transferring
In this state i can not able to enable or disable advertise again ,
showing "command disallowed"
In Device C side
1; Enabled LE scanning , but device A is not detecting since it is
connected to device B
2: ran l2test -s <bdaddr A > as client gives connection timed out
Only essential log messages are given below
DEVICE A
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
value 0x01 (advertising enabled)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 43, role slave
data receiving.......
DEVICE B
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:1B:DC:05:E0:5D type 0
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role master
data sending.......
Now if tries to enable or disable advertising in Device A it shows
error as follows
root@localhost ~]# hciconfig 0 leadv
LE set advertise enable on hci0 returned status 12
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
value 0x01 (advertising enabled)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
status 0x0c pktlen 0x0004 maxpkt 0x38
Error: Command Disallowed
DEVICE C
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:1B:DC:05:E0:5D type 0
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
< HCI Command: LE Create Connection Cancel (0x08|0x000e)plen 0
> HCI Event: Command Complete (0x0e) plen 4
LE Create Connection Cancel (0x08|0x000e) ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x02 handle 0, role master
BR,
ajay.kv
^ permalink raw reply
* Re: [PATCH obexd v1 2/4] build: Require GLib 2.32 or later
From: Luiz Augusto von Dentz @ 2012-08-22 22:36 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZLr1iENopeSbqqiQuryC0T99KkG=Go-K0j9zNca_ijpVQ@mail.gmail.com>
Hi Syam,
On Thu, Aug 23, 2012 at 1:27 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Syam,
>
> On Wed, Aug 22, 2012 at 7:35 PM, Syam Sidhardhan <s.syam@samsung.com> wrote:
>> If we use GLib version less than 2.32 (more precisely < 2.31.2) then
>> the following build error may occure in a 32 bit.
>
> We had the issue with BlueZ but we did not bump the glib version,
> which makes me wonder if you are able to compile bluetoothd?
It looks like we fix it with use of a variable:
commit e34836262ba6a46491b6a760520158d70e8b51b5
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Wed Oct 12 00:48:59 2011 +0300
Fix compilation error on 32-bit systems
This fixes the following compilation error with GLib on 32-bit sytems:
audio/media.c: In function 'get_setting':
audio/media.c:1109:44: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
audio/media.c: In function 'set_setting':
audio/media.c:1132:41: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH obexd v1 2/4] build: Require GLib 2.32 or later
From: Luiz Augusto von Dentz @ 2012-08-22 22:27 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: linux-bluetooth
In-Reply-To: <1345653354-23720-2-git-send-email-s.syam@samsung.com>
Hi Syam,
On Wed, Aug 22, 2012 at 7:35 PM, Syam Sidhardhan <s.syam@samsung.com> wrote:
> If we use GLib version less than 2.32 (more precisely < 2.31.2) then
> the following build error may occure in a 32 bit.
We had the issue with BlueZ but we did not bump the glib version,
which makes me wonder if you are able to compile bluetoothd?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: PBAP + two-step download
From: Luiz Augusto von Dentz @ 2012-08-22 22:13 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Bluez, Mikel Astiz, Jeremy Whiting
In-Reply-To: <1345651474.29868.344.camel@pohly-mobl1.fritz.box>
Hi Patrick,
On Wed, Aug 22, 2012 at 7:04 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> Hello!
>
> For IVI use cases, Mikel and I were discussing how a phone's address
> book could be cached intelligently by an IVI head unit. The rough idea
> is that first all contacts get pulled without PHOTO data. This data is
> used to match the current phone address book with some potentially
> cached local data. Then in a second step, the PHOTO data of all contacts
> is requested (*). This is all done in the same PBAP session, so the
> numbering of contacts is the same in both steps.
>
> The goal is to get the essential data (names, phone numbers) quickly and
> then add pictures later on.
I think it is a good idea, but what about to download the full contact
vcard only when it is to be displayed? When we connect we attempt to
download the full phonebook which is cached for fast lookup but while
ringing we can download the full vcard including the picture. A single
vcard should be really fast specially since we are already connected
and should have a session active, in any case this would have to be
done if the contact is not found locally we should stop any ongoing
operation and attempt to search for the phone number.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ v0 0/5] HoG Suspend/Resume
From: Claudio Takahasi @ 2012-08-22 21:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345237703-15342-1-git-send-email-claudio.takahasi@openbossa.org>
On Fri, Aug 17, 2012 at 6:08 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> This patch series adds HID Control Point support. This control point
> allows the report host(BlueZ) to notify the report device(HoG device)
> when the host is entering or leaving the Suspend Mode.
>
> The low power Suspend Mode concept is implementation specific. This
> proposal adds the support for UPower backend. UPower signals Resuming
> /Sleeping are used to trigger the control point writing.
>
> Claudio Takahasi (5):
> hog: Adds initial files for suspend support
> hog: Add UPower Resuming/Suspending watch
> hog: Add Suspend/Resume callbacks
> hog: Move HoG device list to manager
> hog: Add writting Control Point
>
> Makefile.am | 3 +-
> profiles/input/hog_device.c | 73 ++++++++++++++++++++----------
> profiles/input/hog_device.h | 9 +++-
> profiles/input/hog_manager.c | 69 ++++++++++++++++++++++++++++-
> profiles/input/upower.c | 101 ++++++++++++++++++++++++++++++++++++++++++
> profiles/input/upower.h | 29 ++++++++++++
> 6 files changed, 254 insertions(+), 30 deletions(-)
> create mode 100644 profiles/input/upower.c
> create mode 100644 profiles/input/upower.h
>
> --
> 1.7.8.6
>
ping ...
Regards,
Claudio
^ permalink raw reply
* Re: Agenda for Linux Wireless (802.11/Bluetooth/NFC) Mini-Summit 2012 (Barcelona!)
From: John W. Linville @ 2012-08-22 20:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-bluetooth, alexander.smirnov
In-Reply-To: <1345667975.8786.0.camel@jlt3.sipsolutions.net>
On Wed, Aug 22, 2012 at 10:39:35PM +0200, Johannes Berg wrote:
> On Wed, 2012-08-22 at 16:19 -0400, John W. Linville wrote:
>
> > With that said, there are still a number of slots available for
> > presentations or discussion topics. This is especially true for the
> > 802.11 group... Please step-up with some suggested topics!
>
> Anyone want to carefully review & present Michal's and my work on
> multi-channel in mac80211? :-)
I would _really_ like to see this. Anyone (smarter than me) that is
willing to do this for the group?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Agenda for Linux Wireless (802.11/Bluetooth/NFC) Mini-Summit 2012 (Barcelona!)
From: Johannes Berg @ 2012-08-22 20:39 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, linux-bluetooth, alexander.smirnov
In-Reply-To: <20120822201930.GC14913@tuxdriver.com>
On Wed, 2012-08-22 at 16:19 -0400, John W. Linville wrote:
> With that said, there are still a number of slots available for
> presentations or discussion topics. This is especially true for the
> 802.11 group... Please step-up with some suggested topics!
Anyone want to carefully review & present Michal's and my work on
multi-channel in mac80211? :-)
johannes
^ permalink raw reply
* Agenda for Linux Wireless (802.11/Bluetooth/NFC) Mini-Summit 2012 (Barcelona!)
From: John W. Linville @ 2012-08-22 20:19 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth, alexander.smirnov
All,
The time for our meeting in Barcelona is drawing near. I think it
is time that we start nailing-down the agenda.
We have one room on the first day, and three rooms on the second day.
I figure that the Bluetooth and 802.11 groups should each get a
break-out room for their own in-depth discussons on the second day and
the third room can be used for more general topics and presentations.
With that said, there are still a number of slots available for
presentations or discussion topics. This is especially true for the
802.11 group... Please step-up with some suggested topics!
Below is my strawman agenda proposal. Please make suggestions for
improvements!
Day 1
-----
Everyone together in a single room...
Time Topic Speaker
---- ----- -------
0930 Welcome/Intro/Agenda John Linville
1000 802.15.4 stack, 6lowpan Alexander Smirnov
1100 Break
1130 Virtual Bluetooth AMP Controller for mac80211 Andrei Emeltchenko
1230 Lunch
1400 NFC "state of the union", etc. Ortiz / Elias / Chlad
1500 Break
...
1800 Adjourn
Day 2
-----
802.11 break-out room...
Time Topic Speaker
---- ----- -------
1000 Regulatory updates Luis Rodriguez
1100 Break
...
1800 Adjourn
Bluetooth break-out room...
Time Topic Speaker
---- ----- -------
1000 Bluetooth: state of the union Marcel Holtmann
1100 Break
1130 status and roadmap of Bluetooth LE Joao Paulo Rechi Vita
1230 Lunch
...
1800 Adjourn
Presentation room...
Time Topic Speaker
---- ----- -------
1000 wireless community networks Nick Kossifidis
1100 Break
1130 "a short overview what we do in ConnMan" Wagner / Flykt
1230 Lunch
1400 oFono / mobile wireless Denis Kenzior
1500 Break
...
1800 Adjourn
So...suggestions??
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH BlueZ v0 8/8] scan: Avoid discover if scan handle is known
From: Claudio Takahasi @ 2012-08-22 19:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345664723-30814-1-git-send-email-claudio.takahasi@openbossa.org>
This patch avoids the characteristic discovery for Scan Interval Window
if the attribute value handle was discovered on a previous interaction.
---
profiles/scanparam/scan.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/profiles/scanparam/scan.c b/profiles/scanparam/scan.c
index f292eb1..788f183 100644
--- a/profiles/scanparam/scan.c
+++ b/profiles/scanparam/scan.c
@@ -206,11 +206,16 @@ static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
struct scan *scan = user_data;
bt_uuid_t iwin_uuid, refresh_uuid;
+ scan->attrib = g_attrib_ref(attrib);
+
+ if (scan->iwhandle) {
+ write_scan_params(scan->attrib, scan->iwhandle);
+ return;
+ }
+
bt_uuid16_create(&iwin_uuid, SCAN_INTERVAL_WIN_UUID);
bt_uuid16_create(&refresh_uuid, SCAN_REFRESH_UUID);
- scan->attrib = g_attrib_ref(attrib);
-
gatt_discover_char(scan->attrib, scan->range.start, scan->range.end,
&iwin_uuid, iwin_discovered_cb, scan);
--
1.7.12
^ permalink raw reply related
* [PATCH BlueZ v0 7/8] scan: Write parameters when requested
From: Claudio Takahasi @ 2012-08-22 19:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345664723-30814-1-git-send-email-claudio.takahasi@openbossa.org>
This patch implements the update procedure of the scan parameters
when the Scan Server requests. The Scan Refresh characteristic is
used to inform the Scan Client(BlueZ) that the Scan Server requires
the most recent scan settings.
---
profiles/scanparam/scan.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/profiles/scanparam/scan.c b/profiles/scanparam/scan.c
index 36e21f3..f292eb1 100644
--- a/profiles/scanparam/scan.c
+++ b/profiles/scanparam/scan.c
@@ -43,6 +43,7 @@
#define SCAN_INTERVAL 0x0060
#define SCAN_WINDOW 0x0030
+#define SERVER_REQUIRES_REFRESH 0x00
struct scan {
struct btd_device *device;
@@ -51,6 +52,7 @@ struct scan {
guint attioid;
uint16_t interval;
uint16_t window;
+ uint16_t iwhandle;
uint16_t refresh_handle;
uint16_t refresh_cb_id;
};
@@ -65,6 +67,16 @@ static gint scan_device_cmp(gconstpointer a, gconstpointer b)
return (device == scan->device ? 0 : -1);
}
+static void write_scan_params(GAttrib *attrib, uint16_t handle)
+{
+ uint8_t value[4];
+
+ att_put_u16(SCAN_INTERVAL, &value[0]);
+ att_put_u16(SCAN_WINDOW, &value[2]);
+
+ gatt_write_char(attrib, handle, value, sizeof(value), NULL, NULL);
+}
+
static void refresh_value_cb(const uint8_t *pdu, uint16_t len,
gpointer user_data)
{
@@ -82,6 +94,9 @@ static void refresh_value_cb(const uint8_t *pdu, uint16_t len,
return;
DBG("Server requires refresh: %d", pdu[3]);
+
+ if (pdu[3] == SERVER_REQUIRES_REFRESH)
+ write_scan_params(scan->attrib, scan->iwhandle);
}
static void ccc_written_cb(guint8 status, const guint8 *pdu,
@@ -171,7 +186,6 @@ static void iwin_discovered_cb(GSList *chars, guint8 status,
{
struct scan *scan = user_data;
struct gatt_char *chr;
- uint8_t value[4];
if (status) {
error("Discover Scan Interval Window: %s",
@@ -180,15 +194,11 @@ static void iwin_discovered_cb(GSList *chars, guint8 status,
}
chr = chars->data;
+ scan->iwhandle = chr->value_handle;
- DBG("Scan Interval Window handle: 0x%04x",
- chr->value_handle);
-
- att_put_u16(SCAN_INTERVAL, &value[0]);
- att_put_u16(SCAN_WINDOW, &value[2]);
+ DBG("Scan Interval Window handle: 0x%04x", scan->iwhandle);
- gatt_write_char(scan->attrib, chr->value_handle, value,
- sizeof(value), NULL, NULL);
+ write_scan_params(scan->attrib, scan->iwhandle);
}
static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
--
1.7.12
^ permalink raw reply related
* [PATCH BlueZ v0 6/8] scan: Register notification handler
From: Claudio Takahasi @ 2012-08-22 19:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345664723-30814-1-git-send-email-claudio.takahasi@openbossa.org>
This patch registers the GAttrib notification handler for Refresh
Characteristic notification.
---
profiles/scanparam/scan.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/profiles/scanparam/scan.c b/profiles/scanparam/scan.c
index 59ff336..36e21f3 100644
--- a/profiles/scanparam/scan.c
+++ b/profiles/scanparam/scan.c
@@ -51,6 +51,8 @@ struct scan {
guint attioid;
uint16_t interval;
uint16_t window;
+ uint16_t refresh_handle;
+ uint16_t refresh_cb_id;
};
GSList *servers = NULL;
@@ -63,9 +65,30 @@ static gint scan_device_cmp(gconstpointer a, gconstpointer b)
return (device == scan->device ? 0 : -1);
}
+static void refresh_value_cb(const uint8_t *pdu, uint16_t len,
+ gpointer user_data)
+{
+ struct scan *scan = user_data;
+ uint16_t handle;
+
+ if (len < 4) { /* 1-byte opcode + 2-byte handle + refresh */
+ error("Malformed ATT notification");
+ return;
+ }
+
+ handle = att_get_u16(&pdu[1]);
+
+ if (handle != scan->refresh_handle)
+ return;
+
+ DBG("Server requires refresh: %d", pdu[3]);
+}
+
static void ccc_written_cb(guint8 status, const guint8 *pdu,
guint16 plen, gpointer user_data)
{
+ struct scan *scan = user_data;
+
if (status != 0) {
error("Write Scan Refresh CCC failed: %s",
att_ecode2str(status));
@@ -73,6 +96,10 @@ static void ccc_written_cb(guint8 status, const guint8 *pdu,
}
DBG("Scan Refresh: notification enabled");
+
+ scan->refresh_cb_id = g_attrib_register(scan->attrib,
+ ATT_OP_HANDLE_NOTIFY, refresh_value_cb,
+ user_data, NULL);
}
static void discover_descriptor_cb(guint8 status, const guint8 *pdu,
@@ -101,7 +128,7 @@ static void discover_descriptor_cb(guint8 status, const guint8 *pdu,
att_put_u16(GATT_CLIENT_CHARAC_CFG_NOTIF_BIT, value);
gatt_write_char(scan->attrib, handle, value, sizeof(value),
- ccc_written_cb, NULL);
+ ccc_written_cb, user_data);
done:
att_data_list_free(list);
}
@@ -133,6 +160,8 @@ static void refresh_discovered_cb(GSList *chars, guint8 status,
if (start >= end)
return;
+ scan->refresh_handle = chr->value_handle;
+
gatt_find_info(scan->attrib, start, end,
discover_descriptor_cb, user_data);
}
@@ -216,6 +245,11 @@ void scan_unregister(struct btd_device *device)
scan = l->data;
servers = g_slist_remove(servers, scan);
+ if (scan->refresh_cb_id) {
+ g_attrib_unregister(scan->attrib, scan->refresh_cb_id);
+ scan->refresh_cb_id = 0;
+ }
+
btd_device_remove_attio_callback(scan->device, scan->attioid);
btd_device_unref(scan->device);
g_attrib_unref(scan->attrib);
--
1.7.12
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox