* Re: [PATCH] Initial draft of Application registration API
From: Claudio Takahasi @ 2010-12-11 19:27 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTik8pqd0uaV2kVaeenBOfTPrVeO0YuW2mfQzJy1J@mail.gmail.com>
Hi Luiz,
On Fri, Dec 10, 2010 at 8:31 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Fri, Dec 10, 2010 at 6:13 AM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>> doc/attribute-api.txt | 44 +++++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 43 insertions(+), 1 deletions(-)
>>
>> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
>> index 23808e6..ab62313 100644
>> --- a/doc/attribute-api.txt
>> +++ b/doc/attribute-api.txt
>> @@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
>> A service consists of some generic service information and a set of
>> characteristics. All characteristic are presented as object path as well.
>>
>> -
>> Local Service hierarchy
>> =======================
>>
>> @@ -37,6 +36,35 @@ Methods
>> Properties
>>
>>
>> +Adapter Application Attribute hierarchy
>> +=======================================
>> +
>> +Service org.bluez
>> +Interface org.bluez.Attrib
>> +Object path [variable prefix]/{hci0,hci1,...}
>> +
>> +Methods void RegisterApplication(array{string} uuids, dict settings)
>> +
>> + Method to allow applications to control automatic
>> + connections to known devices.
>> +
>> + "settings" dictionary defines the wanted application
>> + connection parameters. Defined values:
>> + - Latency: low, medium and high
>> + - BandWidth: TBD
>> + - AutoConnect: boolean
>> +
>> + Latency parameter controls the scan and connect
>> + interval. AutoConnect parameter controls automatic
>> + connections if a bonded device emits a connectable
>> + advertising report.
>> +
>> + void UnregisterApplication(array{string} uuids)
>> +
>> + Unregister a previously registered application.
>> + Remotes are automatically disconnected if no more
>> + applications are interested in the given services.
>> +
>> Device Service hierarchy
>> ========================
>>
>> @@ -154,3 +182,17 @@ Object path freely definable
>> Methods void ValueChanged(object characteristic, array{byte})
>>
>> New raw value of the Characteristic Value attribute.
>> +
>> +Adapter Application Agent hierarchy
>> +====================================
>> +
>> +Service unique name
>> +Interface org.bluez.Application
>> +Object path freely definable
>> +
>> +Methods void Connected(object device, array{object} services)
>> +
>> + Indication that a given remote device was found
>> + and the connection has been established. service
>> + object represents an instance of a primary service
>> + that the application is interested in.
>
> It seems it is missing the object path on RegisterAplication to be
> used to call Connected, also I could see some use of this Application
> Agent for regular (non-LE) profiles, but of course the settings would
> have a bit different purpose for those.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
I discussed this issue with Vinicius before send the initial proposal,
but it is unclear to me if we need to support multiple calls/registers
for the same application or change the parameters. Returning an object
path will be easier to manage the unregister procedure, but once we
export an object path we need to export some methods and properties
for this object. For instance, allow the caller/owner change the UUIDs
and connection parameters.
Is it necessary to pass the application object path in the Connected
method? In my opinion only the object path for the primary services
are enough.
Implement the support for non-LE profiles will be trick, I am not sure
at the moment if we will be able to support BR/EDR and LE profiles
using the same API, but this is something that we already discussed
previously.
Claudio.
^ permalink raw reply
* AVDTP_DELAY_REPORT
From: pl bossart @ 2010-12-10 21:58 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Does anyone know of audio headsets supporting the new DELAY_REPORT
commands? This could be very useful to improve a/v sync and may
require some additions to PulseAudio.
Thanks,
-Pierre
^ permalink raw reply
* Re: [PATCH] Fix crash while reading from mapped file
From: Luiz Augusto von Dentz @ 2010-12-10 17:45 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1291989348-3911-1-git-send-email-michalski.raf@gmail.com>
Hi,
On Fri, Dec 10, 2010 at 3:55 PM, Rafal Michalski
<michalski.raf@gmail.com> wrote:
> After opening file from /var/lib/bluetooth/<bt_addr>/ and mapping to
> memory as it is done in "textfile_foreach" function in textfile.c,
> it may crash when size of file is equal to page size
> (or it's multiplicity) since "strpbrk" function operates on string
> so it expects zero at the end of buffer ("mmap" function zeroes
> remaining memory when mapped only for a file which size is not a
> multiple of the page size, so in this case "strpbrk" function can't
> find null terminating character and goes out of bounds).
> This patch provide buffer which contains null terminating character to
> avoid crash.
> ---
> src/textfile.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/src/textfile.c b/src/textfile.c
> index 2429cc7..393efb8 100644
> --- a/src/textfile.c
> +++ b/src/textfile.c
> @@ -376,7 +376,7 @@ char *textfile_caseget(const char *pathname, const char *key)
> int textfile_foreach(const char *pathname, textfile_cb func, void *data)
> {
> struct stat st;
> - char *map, *off, *end, *key, *value;
> + char *map, *off, *end, *key, *value, *buffer = NULL;
> off_t size; size_t len;
> int fd, err = 0;
>
> @@ -404,6 +404,13 @@ int textfile_foreach(const char *pathname, textfile_cb func, void *data)
>
> off = map;
>
> + if (!(size % getpagesize())) {
> + buffer = malloc(size + 1);
> + memset(buffer, 0, size + 1);
> + memcpy(buffer, map, size);
> + off = buffer;
> + }
Isn't this doing exact the same as strncpy or g_strndup does? Actually
it is really too bad there is no str(n)pbrk variant.
> while (1) {
> end = strpbrk(off, " ");
> if (!end) {
> @@ -458,6 +465,7 @@ unlock:
>
> close:
> close(fd);
> + free(buffer);
> errno = err;
>
> return 0;
I also wonder why we didn't use g_strsplit for this, it seems it would
actually do the same, there is a little performance impact since we
would have to iterate on the vector generated to call the callback
while the current code do it in-place.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Fix crash while reading from mapped file
From: Rafal Michalski @ 2010-12-10 13:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
After opening file from /var/lib/bluetooth/<bt_addr>/ and mapping to
memory as it is done in "textfile_foreach" function in textfile.c,
it may crash when size of file is equal to page size
(or it's multiplicity) since "strpbrk" function operates on string
so it expects zero at the end of buffer ("mmap" function zeroes
remaining memory when mapped only for a file which size is not a
multiple of the page size, so in this case "strpbrk" function can't
find null terminating character and goes out of bounds).
This patch provide buffer which contains null terminating character to
avoid crash.
---
src/textfile.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/textfile.c b/src/textfile.c
index 2429cc7..393efb8 100644
--- a/src/textfile.c
+++ b/src/textfile.c
@@ -376,7 +376,7 @@ char *textfile_caseget(const char *pathname, const char *key)
int textfile_foreach(const char *pathname, textfile_cb func, void *data)
{
struct stat st;
- char *map, *off, *end, *key, *value;
+ char *map, *off, *end, *key, *value, *buffer = NULL;
off_t size; size_t len;
int fd, err = 0;
@@ -404,6 +404,13 @@ int textfile_foreach(const char *pathname, textfile_cb func, void *data)
off = map;
+ if (!(size % getpagesize())) {
+ buffer = malloc(size + 1);
+ memset(buffer, 0, size + 1);
+ memcpy(buffer, map, size);
+ off = buffer;
+ }
+
while (1) {
end = strpbrk(off, " ");
if (!end) {
@@ -458,6 +465,7 @@ unlock:
close:
close(fd);
+ free(buffer);
errno = err;
return 0;
--
1.6.3.3
^ permalink raw reply related
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: roystonr @ 2010-12-10 12:19 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Johan Hedberg
Cc: linux-bluetooth, roystonr, skrovvid, rshaffer
In-Reply-To: <c2cb901974d908ed9f808324e4b4f6fb.squirrel@www.codeaurora.org>
Hi Johan/Luiz,
> On Fri, Dec 10, 2010, Luiz Augusto von Dentz wrote:
> I guess it would be better to have the call to
> avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
> there and less code too, but the fix is probably right.
Along with this as per my understanding, struct avdtp_remote_sep *rsep has
to be added as member to struct a2dp_setup and rsep should be overridden
as follows in a2dp_reconfigure after call to avdtp_get_seps which returns
the sep corresponding to the stream not in use. If the remote device
supports multi-stream then sep returned would be based on the order of
get_capabilities response. Hence the following override is needed to
ensure that closed stream is reconfigured. Correct me if mistaken.
if (setup->rsep) {
rsep = setup->rsep;
}
Have provided the patch to the tester to verify as we don't have the BMW
CK available locally. Would update the feedback received.
Regards,
Royston Rodrigues
^ permalink raw reply
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: Johan Hedberg @ 2010-12-10 10:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: roystonr, linux-bluetooth, skrovvid, rshaffer
In-Reply-To: <AANLkTik78DiC7TgWtR0q=xPs+ZZq470_md-gJWv8tB8f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
Hi Luiz,
On Fri, Dec 10, 2010, Luiz Augusto von Dentz wrote:
> I guess it would be better to have the call to
> avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
> there and less code too, but the fix is probably right.
Good point. Attach is a patch which does this. Could we now please get
some feedback from the reporter if this really helps? :)
Johan
[-- Attachment #2: acp_sep_selection.patch --]
[-- Type: text/x-diff, Size: 1420 bytes --]
diff --git a/audio/a2dp.c b/audio/a2dp.c
index b1e94d9..b46cef1 100644
--- a/audio/a2dp.c
+++ b/audio/a2dp.c
@@ -1097,6 +1097,9 @@ static void close_cfm(struct avdtp *session, struct avdtp_local_sep *sep,
return;
}
+ if (!setup->rsep)
+ setup->rsep = avdtp_stream_get_remote_sep(stream);
+
if (setup->reconfigure)
g_timeout_add(RECONFIGURE_TIMEOUT, a2dp_reconfigure, setup);
}
diff --git a/audio/avdtp.c b/audio/avdtp.c
index 1683e7c..33178c3 100644
--- a/audio/avdtp.c
+++ b/audio/avdtp.c
@@ -3133,6 +3133,12 @@ gboolean avdtp_stream_has_capabilities(struct avdtp_stream *stream,
return TRUE;
}
+struct avdtp_remote_sep *avdtp_stream_get_remote_sep(
+ struct avdtp_stream *stream)
+{
+ return avdtp_get_remote_sep(stream->session, stream->rseid);
+}
+
gboolean avdtp_stream_get_transport(struct avdtp_stream *stream, int *sock,
uint16_t *imtu, uint16_t *omtu,
GSList **caps)
diff --git a/audio/avdtp.h b/audio/avdtp.h
index 9406fa7..5f37dc3 100644
--- a/audio/avdtp.h
+++ b/audio/avdtp.h
@@ -257,6 +257,8 @@ gboolean avdtp_stream_has_capability(struct avdtp_stream *stream,
struct avdtp_service_capability *cap);
gboolean avdtp_stream_has_capabilities(struct avdtp_stream *stream,
GSList *caps);
+struct avdtp_remote_sep *avdtp_stream_get_remote_sep(
+ struct avdtp_stream *stream);
unsigned int avdtp_add_state_cb(avdtp_session_state_cb cb, void *user_data);
^ permalink raw reply related
* Re: [PATCH] Initial draft of Application registration API
From: Luiz Augusto von Dentz @ 2010-12-10 10:31 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1291954417-18138-1-git-send-email-claudio.takahasi@openbossa.org>
Hi,
On Fri, Dec 10, 2010 at 6:13 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> doc/attribute-api.txt | 44 +++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 43 insertions(+), 1 deletions(-)
>
> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
> index 23808e6..ab62313 100644
> --- a/doc/attribute-api.txt
> +++ b/doc/attribute-api.txt
> @@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
> A service consists of some generic service information and a set of
> characteristics. All characteristic are presented as object path as well.
>
> -
> Local Service hierarchy
> =======================
>
> @@ -37,6 +36,35 @@ Methods
> Properties
>
>
> +Adapter Application Attribute hierarchy
> +=======================================
> +
> +Service org.bluez
> +Interface org.bluez.Attrib
> +Object path [variable prefix]/{hci0,hci1,...}
> +
> +Methods void RegisterApplication(array{string} uuids, dict settings)
> +
> + Method to allow applications to control automatic
> + connections to known devices.
> +
> + "settings" dictionary defines the wanted application
> + connection parameters. Defined values:
> + - Latency: low, medium and high
> + - BandWidth: TBD
> + - AutoConnect: boolean
> +
> + Latency parameter controls the scan and connect
> + interval. AutoConnect parameter controls automatic
> + connections if a bonded device emits a connectable
> + advertising report.
> +
> + void UnregisterApplication(array{string} uuids)
> +
> + Unregister a previously registered application.
> + Remotes are automatically disconnected if no more
> + applications are interested in the given services.
> +
> Device Service hierarchy
> ========================
>
> @@ -154,3 +182,17 @@ Object path freely definable
> Methods void ValueChanged(object characteristic, array{byte})
>
> New raw value of the Characteristic Value attribute.
> +
> +Adapter Application Agent hierarchy
> +====================================
> +
> +Service unique name
> +Interface org.bluez.Application
> +Object path freely definable
> +
> +Methods void Connected(object device, array{object} services)
> +
> + Indication that a given remote device was found
> + and the connection has been established. service
> + object represents an instance of a primary service
> + that the application is interested in.
It seems it is missing the object path on RegisterAplication to be
used to call Connected, also I could see some use of this Application
Agent for regular (non-LE) profiles, but of course the settings would
have a bit different purpose for those.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: Luiz Augusto von Dentz @ 2010-12-10 9:51 UTC (permalink / raw)
To: roystonr, linux-bluetooth, skrovvid, rshaffer
In-Reply-To: <20101209144103.GA30557@jh-x301>
Hi,
On Thu, Dec 9, 2010 at 4:41 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Royston,
>
> On Thu, Dec 09, 2010, roystonr@codeaurora.org wrote:
>> Change expected:
>> avdtp_get_seps should be able to provide the SEP of the one used in the
>> AVDTP_CLOSE previously. But there weren't any previously closed streams
>> then provide the SEP which is not in use (as done currently).
>>
>> Kindly let us know whether our understanding is right and can this be a
>> suspected cause of the issue seen. Correct if mistaken.
>
> Sounds like that might be the cause. Have you experimented with patching
> the bluez code to reuse the same SEP as was used for the Close? If not
> I'd advice you to do that so we can be sure that a change to the ACP SEP
> selection logic makes sense.
>
> Right now the reconfiguration happens in audio/a2dp.c where there's a
> setup->reconfigure flag to track if a new stream should be configured
> after receiving close_ind. The a2dp_reconfigure function in a2dp.c is
> responsible for selecting the remote SEP. Could you try the attached
> (completely untested) patch to see if it helps? It stores the old remote
> SEP in the setup structure when starting the Close procedure in which
> case a2dp_reconfigure() shouldn't try to reselect a new remote SEP but
> use the stored one instead.
I guess it would be better to have the call to
avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
there and less code too, but the fix is probably right.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 1/1] bluetooth: Fix NULL pointer dereference issue
From: Ville Tervo @ 2010-12-10 7:17 UTC (permalink / raw)
To: Yuri Ershov
Cc: ext Gustavo F. Padovan, andrei.emeltchenko,
linux-bluetooth@vger.kernel.org
In-Reply-To: <4CFF6359.7000305@nokia.com>
Hi Yuri,
On Wed, Dec 08, 2010 at 01:52:09PM +0300, Yuri Ershov wrote:
> >>>So in which situations (n == p), or (p == p->next)? That should happen only
> >>>when p is the only element in the list, then p == head, right?
> >>The (n == p) is in situation, when sk is unlinked by task
> >>responsible for handling connect/disconnect requests while the
> >>"bt_accept_dequeue". This condition is indirect checking of sk
> >>validity.
> >
> >Why not using a list lock here instead? Fits a way better.
> >
> Yes, it's better. I tried to use the locks in this function, but it
> slows down the task handling connect/disconnect/etc. events and the
> task skips some events from fast clients.
>
What kind of problems you exactly got with locks? Maybe they should be fixed
also.
--
Ville
^ permalink raw reply
* Re: [PATCH] Initial draft of Application registration API
From: Claudio Takahasi @ 2010-12-10 5:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1291954417-18138-1-git-send-email-claudio.takahasi@openbossa.org>
Hi,
It should be a RFC instead of PATCH in the subject prefix.
On Fri, Dec 10, 2010 at 1:13 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Add new methods to allow automatic connection when a known remote device
> which supports the wanted services is found.
>
> Overview: RegisterApplication method allows a given application to
> controls the connection establishment procedure for bonded devices.
> StartDiscovery() implements an interleaved discovery, switching between
> inquiry and LE active scanning. For single mode devices found, an
> application can call CreateDevice or CreatePairedDevice, these methods
> will trigger the Discover All Primary Services and SSP(if applied).
Please read SMP instead of SSP for CreatePairedDevice. GATT/ATT
implements a per attribute permission, for BlueZ we are planning to
use CreatePairedDevice to trigger the SMP/key distribution. SMP
negotiation is being implemented completely in the kernel, but at the
moment there isn't key storage and management interface between the
kernel and the userspace to notify the keys. SMP just works method
will be triggered when the client access the first attribute which
requires encryption or when a encrypted link is created.
IMHO, automatic connections needs to be restricted to bonded devices.
If necessary, we can also use the Trusted property.
Claudio
^ permalink raw reply
* Re: RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE
From: Suraj Sumangala @ 2010-12-10 4:25 UTC (permalink / raw)
To: Nick Pelly
Cc: Andrei Emeltchenko, Luiz Augusto von Dentz, Marcel Holtmann,
linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTinbaqh_vXsNUHR4-XKfP-50dbmvNxM3QkZvnFjv@mail.gmail.com>
Hi,
On 12/9/2010 10:25 PM, Nick Pelly wrote:
> On Thu, Dec 9, 2010 at 2:37 AM, Andrei Emeltchenko
> <andrei.emeltchenko.news@gmail.com> wrote:
>>
>> Hi All,
>>
>> On Wed, Jun 16, 2010 at 5:15 PM, Nick Pelly<npelly@google.com> wrote:
>>> On Wed, Jun 16, 2010 at 4:40 AM, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Mar 9, 2010 at 11:45 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
>>>>> Hi Nick,
>>>>>
>>>>>>>>>>> Right now Bluez always requests flushable ACL packets (but does not
>>>>>>>>>>> set a flush timeout, so effectively they are non-flushable):
>>>>>>>>>>>
>>>>>>>>>>> However it is desirable to use an ACL flush timeout on A2DP packets so
>>>>>>>>>>> that if the ACL packets block for some reason then the LM can flush
>>>>>>>>>>> them to make room for newer packets.
>>>>>>>>>>>
>>>>>>>>>>> Is it reasonable for Bluez to use the 0x00 ACL packet boundary flag by
>>>>>>>>>>> default (non-flushable packet), and let userspace request flushable
>>>>>>>>>>> packets on A2DP L2CAP sockets with the socket option
>>>>>>>>>>> L2CAP_LM_RELIABLE.
>>>>>>>>>>
>>>>>>>>>> the reliable option has a different meaning. It comes back from the old
>>>>>>>>>> Bluetooth 1.1 qualification days where we had to tests on L2CAP that had
>>>>>>>>>> to confirm that we can detect malformed packets and report them. These
>>>>>>>>>> days it is just fine to drop them.
>>>>>>>>>
>>>>>>>>> Got it, how about introducing
>>>>>>>>>
>>>>>>>>> #define L2CAP_LM_FLUSHABLE 0x0040
>>>>>>>>
>>>>>>>> that l2cap_sock_setsockopt_old() sets this didn't give you a hint that
>>>>>>>> we might wanna deprecate this socket options ;)
>>>>>>>>
>>>>>>>> I need to read up on the flushable stuff, but in the end it deserves its
>>>>>>>> own socket option. Also an ioctl() to actually trigger Enhanced flush
>>>>>>>> might be needed.
>>>>>>>>
>>>>>>>>> struct l2cap_pinfo {
>>>>>>>>> ...
>>>>>>>>> __u8 flushable;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Sure. In the long run we need to turn this into a bitmask. We are just
>>>>>>>> wasting memory here.
>>>>>>>
>>>>>>> Attached is an updated patch, that checks the LMP features bitmask
>>>>>>> before using the new non-flushable packet type.
>>>>>>>
>>>>>>> I am still using L2CAP_LM_FLUSHABLE socket option in
>>>>>>> l2cap_sock_setsockopt_old(), which I don't think you are happy with.
>>>>>>> So how about a new option:
>>>>>>>
>>>>>>> SOL_L2CAP, L2CAP_ACL_FLUSH
>>>>>>> which has a default value of 0, and can be set to 1 to make the ACL
>>>>>>> data sent by this L2CAP socket flushable.
>>>>>>>
>>>>>>> In a later commit we would then add
>>>>>>> SOL_ACL, ACL_FLUSH_TIMEOUT
>>>>>>> That is used to set an automatic flush timeout for the ACL link on a
>>>>>>> L2CAP socket. Note that SOL_ACL is new.
>>>>>>>
>>>>>>> But maybe this is not what you had in mind, so I'm looking for your
>>>>>>> advice before I implement this.
>>>>>>
>>>>>> Attached an updated patch for 2.6.32 kernel. We've been using this
>>>>>> patch successfully on production devices.
>>>>>
>>>>> can see anything wrong with that patch. However we need to use
>>>>> SOL_BLUETOOTH for it of course. So we need to come up with something to
>>>>> make this simple.
>>
>> Nick are you going to take Marcel comments? Otherwise I could take
>> care about the patch as it seems that it might help in some
>> situations.
>
> I'm not actively working on this patch.
>
>>>>> An additional change I like to see is to use flags for booleans like
>>>>> flushable in the structures. Can you work on changing that.
>>>>>
>>>>> Also do we have decoding support for this in hcidump. It might be nice
>>>>> to include some really simple examples in the commit message.
>>
>> At least wireshark which I use understands those packets.
>>
>>>> I would like to play a little bit with this, so is there any missing updates?
>>>
>>> Nope, that is our most recent version.
>>
>> Nick, do you know headset which could help to hear the real
>> difference? I was trying to use Sony DR-BT22 headset which has some
>> issues with A2DP but the solution did not help much.
>
> It becomes essential in non-ideal radio bandwidth conditions such as
> single antenna wifi co-existence. We also had some headsets that
> exacerbated the problem (presumably they had less logic to 'catch-up'
> through late packets) but I can't remember off hand.
I think you should be able to reproduce the same issue using any A2DP
headset.
Use a CSR dongle as local controller and start streaming A2DP data.
Parallel to that initiate an FTP connection to another device.
Take the headset out of range, or keep it in a shield box.
You should be able to see that the FTP link also stalls as the A2DP
packets are stalled in controller without getting flushed.
>
> Nick
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards
Suraj
^ permalink raw reply
* [PATCH] Initial draft of Application registration API
From: Claudio Takahasi @ 2010-12-10 4:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
Add new methods to allow automatic connection when a known remote device
which supports the wanted services is found.
Overview: RegisterApplication method allows a given application to
controls the connection establishment procedure for bonded devices.
StartDiscovery() implements an interleaved discovery, switching between
inquiry and LE active scanning. For single mode devices found, an
application can call CreateDevice or CreatePairedDevice, these methods
will trigger the Discover All Primary Services and SSP(if applied).
Characteristics will be fetched on demand to avoid unnecessary data
transfers.
The Generic attribute API exposes methods to applications to read and
write characteristics. Implement profile specific API will be avoided.
For example, Proximity Monitor may need a BlueZ plugin to monitor the
path loss however additional method specific to this profile doesn't
need to be exposed. The Generic API can expose all the characteristic
necessary to a Proximity client application.
Characteristic Watchers allow the applications to monitor(passively)
characteristics changes for a given primary service. It doesn't control
or trigger any connection establishment.
Register application will act as an advertising monitor, allowing
external applications to control passive scanning and automatic
connections(for bonded devices).
Open: Define the necessary parameters for RegisterApplication, support
for GAP Broadcaster/Observer, define if RegisterApplication needs to
support BR/EDR connections, maybe merge Watchers and Application
interfaces.
---
doc/attribute-api.txt | 44 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 23808e6..ab62313 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
A service consists of some generic service information and a set of
characteristics. All characteristic are presented as object path as well.
-
Local Service hierarchy
=======================
@@ -37,6 +36,35 @@ Methods
Properties
+Adapter Application Attribute hierarchy
+=======================================
+
+Service org.bluez
+Interface org.bluez.Attrib
+Object path [variable prefix]/{hci0,hci1,...}
+
+Methods void RegisterApplication(array{string} uuids, dict settings)
+
+ Method to allow applications to control automatic
+ connections to known devices.
+
+ "settings" dictionary defines the wanted application
+ connection parameters. Defined values:
+ - Latency: low, medium and high
+ - BandWidth: TBD
+ - AutoConnect: boolean
+
+ Latency parameter controls the scan and connect
+ interval. AutoConnect parameter controls automatic
+ connections if a bonded device emits a connectable
+ advertising report.
+
+ void UnregisterApplication(array{string} uuids)
+
+ Unregister a previously registered application.
+ Remotes are automatically disconnected if no more
+ applications are interested in the given services.
+
Device Service hierarchy
========================
@@ -154,3 +182,17 @@ Object path freely definable
Methods void ValueChanged(object characteristic, array{byte})
New raw value of the Characteristic Value attribute.
+
+Adapter Application Agent hierarchy
+====================================
+
+Service unique name
+Interface org.bluez.Application
+Object path freely definable
+
+Methods void Connected(object device, array{object} services)
+
+ Indication that a given remote device was found
+ and the connection has been established. service
+ object represents an instance of a primary service
+ that the application is interested in.
--
1.7.3.3
^ permalink raw reply related
* Re: compat-wireless-2.6.37-rc5 released
From: Luis R. Rodriguez @ 2010-12-10 1:08 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTim5HQGNL-vSapeQw_-dJue89pYz7zc8eiShma8j@mail.gmail.com>
On Wed, Dec 8, 2010 at 4:15 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> In later releases we will have to consider if we want to cherry pick
> anything extra or leave them as is. These few patches seem tempting to
> suck in:
>
> 01-ath9k-OTP.patch
> 03-ath9k-no-aggr-VO.patch
> 04-mac80211-no-aggr-VO.patch
> 05-ath9k-Reintroduce-modparam-to-enable-btcoex.patch
> 06-ath9k_hw-fix-A-MPDU-key-search-issues-on-AR9003.patch
>
> Particularly it is now known AR9003 devices will only ship with OTP
> so..
So it turns out this is inaccurate, AR9003 devices can ship with
EEPROM only or with OTP, it will vary, so while 2.6.36 and 2.6.37 will
not support only OTP based devices 2.6.38 will support both. What we
can do is cherry pick the OTP patches to the 2.6.36 and 2.6.37
compat-wireless releases but those two older stock kernels won't have
support for these.
Luis
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Luis R. Rodriguez @ 2010-12-09 22:39 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-wireless, linux-kernel, linux-bluetooth
In-Reply-To: <alpine.LNX.2.00.1012092329480.25880@swampdragon.chaosbits.net>
On Thu, Dec 9, 2010 at 2:31 PM, Jesper Juhl <jj@chaosbits.net> wrote:
> On Thu, 9 Dec 2010, Luis R. Rodriguez wrote:
>
>> I'm going to start dropping PCMCIA stuff from compat-wireless as I
>> don't think we have any users of it nor interest to keep backporting
>> it. This entails dropping drivers like orinoco, b43 PCMCIA support,
>> libertas, as well as bluetooth bluecard_cs, bluecard_cs, dtl1_cs,
>> bt3c_cs and of course CONFIG_SSB_PCMCIAHOST. If you are a user please
>> yell now.
>>
> Yelling.
> While I'm not personally a user, my mother is. She still has an old IBM
> Thinkpad 600 laptop with a PCMCIA card in it that uses the orinoco driver.
And you have your mother using compat-wireless?
Luis
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Jesper Juhl @ 2010-12-09 22:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTikc_u4NhxdGzwQMjbEe12qYmhq481amazTK-JRc@mail.gmail.com>
On Thu, 9 Dec 2010, Luis R. Rodriguez wrote:
> On Thu, Dec 9, 2010 at 2:31 PM, Jesper Juhl <jj@chaosbits.net> wrote:
> > On Thu, 9 Dec 2010, Luis R. Rodriguez wrote:
> >
> >> I'm going to start dropping PCMCIA stuff from compat-wireless as I
> >> don't think we have any users of it nor interest to keep backporting
> >> it. This entails dropping drivers like orinoco, b43 PCMCIA support,
> >> libertas, as well as bluetooth bluecard_cs, bluecard_cs, dtl1_cs,
> >> bt3c_cs and of course CONFIG_SSB_PCMCIAHOST. If you are a user please
> >> yell now.
> >>
> > Yelling.
> > While I'm not personally a user, my mother is. She still has an old IBM
> > Thinkpad 600 laptop with a PCMCIA card in it that uses the orinoco driver.
>
> And you have your mother using compat-wireless?
>
Yes, as a matter of fact I do.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Jesper Juhl @ 2010-12-09 22:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTik4W+UxgyPjVyHDeEFTRCkXdDBQ9obgPkpnhzGW@mail.gmail.com>
On Thu, 9 Dec 2010, Luis R. Rodriguez wrote:
> I'm going to start dropping PCMCIA stuff from compat-wireless as I
> don't think we have any users of it nor interest to keep backporting
> it. This entails dropping drivers like orinoco, b43 PCMCIA support,
> libertas, as well as bluetooth bluecard_cs, bluecard_cs, dtl1_cs,
> bt3c_cs and of course CONFIG_SSB_PCMCIAHOST. If you are a user please
> yell now.
>
Yelling.
While I'm not personally a user, my mother is. She still has an old IBM
Thinkpad 600 laptop with a PCMCIA card in it that uses the orinoco driver.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Luis R. Rodriguez @ 2010-12-09 22:27 UTC (permalink / raw)
To: linux-wireless, linux-kernel; +Cc: linux-bluetooth
In-Reply-To: <AANLkTik4W+UxgyPjVyHDeEFTRCkXdDBQ9obgPkpnhzGW@mail.gmail.com>
On Thu, Dec 9, 2010 at 2:20 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> I'm going to start dropping PCMCIA stuff from compat-wireless as I
> don't think we have any users of it nor interest to keep backporting
> it. This entails dropping drivers like orinoco, b43 PCMCIA support,
> libertas, as well as bluetooth bluecard_cs, bluecard_cs, dtl1_cs,
> bt3c_cs and of course CONFIG_SSB_PCMCIAHOST. If you are a user please
> yell now.
Well Haukes just sent me a patch to update some stuff so PCMCIA is
saved until further notice :)
Luis
^ permalink raw reply
* Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Luis R. Rodriguez @ 2010-12-09 22:20 UTC (permalink / raw)
To: linux-wireless, linux-kernel; +Cc: linux-bluetooth
I'm going to start dropping PCMCIA stuff from compat-wireless as I
don't think we have any users of it nor interest to keep backporting
it. This entails dropping drivers like orinoco, b43 PCMCIA support,
libertas, as well as bluetooth bluecard_cs, bluecard_cs, dtl1_cs,
bt3c_cs and of course CONFIG_SSB_PCMCIAHOST. If you are a user please
yell now.
Luis
^ permalink raw reply
* Re: [PATCH] Convert CreateDevice on test-device script to an asynchronous call
From: Johan Hedberg @ 2010-12-09 20:09 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1291923734-30979-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Dec 09, 2010, Claudio Takahasi wrote:
> Change required to test the scenario when the sender of a CreateDevice
> request disconnects from the system bus. Current implementation is
> blocking and it doesn't allow the user to cancel a request.
> ---
> test/test-device | 22 +++++++++++++++++++---
> 1 files changed, 19 insertions(+), 3 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Convert CreateDevice on test-device script to an asynchronous call
From: Claudio Takahasi @ 2010-12-09 19:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1291923166-30880-1-git-send-email-claudio.takahasi@openbossa.org>
Change required to test the scenario when the sender of a CreateDevice
request disconnects from the system bus. Current implementation is
blocking and it doesn't allow the user to cancel a request.
---
test/test-device | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/test/test-device b/test/test-device
index a04ff35..828349c 100755
--- a/test/test-device
+++ b/test/test-device
@@ -1,11 +1,16 @@
#!/usr/bin/python
+import gobject
+
import sys
import dbus
+import dbus.mainloop.glib
import re
from optparse import OptionParser, make_option
+dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
+mainloop = gobject.MainLoop()
manager = dbus.Interface(bus.get_object("org.bluez", "/"), "org.bluez.Manager")
@@ -48,13 +53,24 @@ if (args[0] == "list"):
sys.exit(0)
+def create_device_reply(device):
+ print "New device (%s)" % device
+ mainloop.quit()
+ sys.exit(0)
+
+def create_device_error(error):
+ print "Creating device failed: %s" % error
+ mainloop.quit()
+ sys.exit(1)
+
if (args[0] == "create"):
if (len(args) < 2):
print "Need address parameter"
else:
- device = adapter.CreateDevice(args[1])
- print device
- sys.exit(0)
+ adapter.CreateDevice(args[1],
+ reply_handler=create_device_reply,
+ error_handler=create_device_error)
+ mainloop.run()
if (args[0] == "remove"):
if (len(args) < 2):
--
1.7.3.3
^ permalink raw reply related
* [PATCH] Convert CreateDevice on test-device script to an asynchronous call
From: Claudio Takahasi @ 2010-12-09 19:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
Change required to test the scenario when the sender of a CreateDevice
or CreatePairedDevice request disconnects from the system bus.
---
test/test-device | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/test/test-device b/test/test-device
index a04ff35..828349c 100755
--- a/test/test-device
+++ b/test/test-device
@@ -1,11 +1,16 @@
#!/usr/bin/python
+import gobject
+
import sys
import dbus
+import dbus.mainloop.glib
import re
from optparse import OptionParser, make_option
+dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
+mainloop = gobject.MainLoop()
manager = dbus.Interface(bus.get_object("org.bluez", "/"), "org.bluez.Manager")
@@ -48,13 +53,24 @@ if (args[0] == "list"):
sys.exit(0)
+def create_device_reply(device):
+ print "New device (%s)" % device
+ mainloop.quit()
+ sys.exit(0)
+
+def create_device_error(error):
+ print "Creating device failed: %s" % error
+ mainloop.quit()
+ sys.exit(1)
+
if (args[0] == "create"):
if (len(args) < 2):
print "Need address parameter"
else:
- device = adapter.CreateDevice(args[1])
- print device
- sys.exit(0)
+ adapter.CreateDevice(args[1],
+ reply_handler=create_device_reply,
+ error_handler=create_device_error)
+ mainloop.run()
if (args[0] == "remove"):
if (len(args) < 2):
--
1.7.3.3
^ permalink raw reply related
* Re: [PATCH] btusb: Fix log spamming due to autosuspend
From: Stefan Seyfried @ 2010-12-09 19:16 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-bluetooth, Marcel Holtmann, gregkh, Stefan Seyfried,
Oliver Neukum
In-Reply-To: <20101201174910.GA16125@vigoh>
Hi all,
On Wed, 1 Dec 2010 15:49:10 -0200
"Gustavo F. Padovan" <padovan@profusion.mobi> wrote:
> Hi Stefan,
>
> * Stefan Seyfried <stefan.seyfried@googlemail.com> [2010-12-01 15:47:14 +0100]:
> > > > If a device is autosuspended an inability to resubmit URBs is
> > > > to be expected. Check the error code and only log real errors.
> > > > (Now that autosuspend is default enabled for btusb, those log
> > > > messages were happening all the time e.g. with a BT mouse)
> > > >
> > > > Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
> > > > Signed-off-by: Oliver Neukum <oneukum@suse.de>
> > >
> > > we had a similar one some time ago, but I am fine with this one as well.
> > > Actually this one might be a bit better since it still keeps some
> > > errors.
> > >
> > > Acked-by: Marcel Holtmann <marcel@holtmann.org>
> >
> > Could you (or Gustavo) send it to Linus? It's pretty trivial, but the
> > messages are annoying and users will complain if they are still in 2.6.37
> > final.
>
> I'll send it, applied to bluetooth-2.6 tree. Thanks.
unfortunately, it does not seem to make it into 2.6.37?
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
^ permalink raw reply
* Re: RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE
From: Nick Pelly @ 2010-12-09 16:55 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Luiz Augusto von Dentz, Marcel Holtmann, linux-bluetooth
In-Reply-To: <AANLkTimPNHrnY4Xn-oqsOQac45Z_rSr1SZtV90cna+ey@mail.gmail.com>
On Thu, Dec 9, 2010 at 2:37 AM, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
>
> Hi All,
>
> On Wed, Jun 16, 2010 at 5:15 PM, Nick Pelly <npelly@google.com> wrote:
> > On Wed, Jun 16, 2010 at 4:40 AM, Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> >> Hi,
> >>
> >> On Tue, Mar 9, 2010 at 11:45 PM, Marcel Holtmann <marcel@holtmann.org>=
wrote:
> >>> Hi Nick,
> >>>
> >>>> >>> >> Right now Bluez always requests flushable ACL packets (but do=
es not
> >>>> >>> >> set a flush timeout, so effectively they are non-flushable):
> >>>> >>> >>
> >>>> >>> >> However it is desirable to use an ACL flush timeout on A2DP p=
ackets so
> >>>> >>> >> that if the ACL packets block for some reason then the LM can=
flush
> >>>> >>> >> them to make room for newer packets.
> >>>> >>> >>
> >>>> >>> >> Is it reasonable for Bluez to use the 0x00 ACL packet boundar=
y flag by
> >>>> >>> >> default (non-flushable packet), and let userspace request flu=
shable
> >>>> >>> >> packets on A2DP L2CAP sockets with the socket option
> >>>> >>> >> L2CAP_LM_RELIABLE.
> >>>> >>> >
> >>>> >>> > the reliable option has a different meaning. It comes back fro=
m the old
> >>>> >>> > Bluetooth 1.1 qualification days where we had to tests on L2CA=
P that had
> >>>> >>> > to confirm that we can detect malformed packets and report the=
m. These
> >>>> >>> > days it is just fine to drop them.
> >>>> >>>
> >>>> >>> Got it, how about introducing
> >>>> >>>
> >>>> >>> #define L2CAP_LM_FLUSHABLE 0x0040
> >>>> >>
> >>>> >> that l2cap_sock_setsockopt_old() sets this didn't give you a hint=
that
> >>>> >> we might wanna deprecate this socket options ;)
> >>>> >>
> >>>> >> I need to read up on the flushable stuff, but in the end it deser=
ves its
> >>>> >> own socket option. Also an ioctl() to actually trigger Enhanced f=
lush
> >>>> >> might be needed.
> >>>> >>
> >>>> >>> struct l2cap_pinfo {
> >>>> >>> =A0 =A0...
> >>>> >>> =A0 =A0__u8 flushable;
> >>>> >>> }
> >>>> >>
> >>>> >> Sure. In the long run we need to turn this into a bitmask. We are=
just
> >>>> >> wasting memory here.
> >>>> >
> >>>> > Attached is an updated patch, that checks the LMP features bitmask
> >>>> > before using the new non-flushable packet type.
> >>>> >
> >>>> > I am still using L2CAP_LM_FLUSHABLE socket option in
> >>>> > l2cap_sock_setsockopt_old(), which I don't think you are happy wit=
h.
> >>>> > So how about a new option:
> >>>> >
> >>>> > SOL_L2CAP, L2CAP_ACL_FLUSH
> >>>> > which has a default value of 0, and can be set to 1 to make the AC=
L
> >>>> > data sent by this L2CAP socket flushable.
> >>>> >
> >>>> > In a later commit we would then add
> >>>> > SOL_ACL, ACL_FLUSH_TIMEOUT
> >>>> > That is used to set an automatic flush timeout for the ACL link on=
a
> >>>> > L2CAP socket. Note that SOL_ACL is new.
> >>>> >
> >>>> > But maybe this is not what you had in mind, so I'm looking for you=
r
> >>>> > advice before I implement this.
> >>>>
> >>>> Attached an updated patch for 2.6.32 kernel. We've been using this
> >>>> patch successfully on production devices.
> >>>
> >>> can see anything wrong with that patch. However we need to use
> >>> SOL_BLUETOOTH for it of course. So we need to come up with something =
to
> >>> make this simple.
>
> Nick are you going to take Marcel comments? Otherwise I could take
> care about the patch as it seems that it might help in some
> situations.
I'm not actively working on this patch.
> >>> An additional change I like to see is to use flags for booleans like
> >>> flushable in the structures. Can you work on changing that.
> >>>
> >>> Also do we have decoding support for this in hcidump. It might be nic=
e
> >>> to include some really simple examples in the commit message.
>
> At least wireshark which I use understands those packets.
>
> >> I would like to play a little bit with this, so is there any missing u=
pdates?
> >
> > Nope, that is our most recent version.
>
> Nick, do you know headset which could help to hear the real
> difference? I was trying to use Sony DR-BT22 headset which has some
> issues with A2DP but the solution did not help much.
It becomes essential in non-ideal radio bandwidth conditions such as
single antenna wifi co-existence. We also had some headsets that
exacerbated the problem (presumably they had less logic to 'catch-up'
through late packets) but I can't remember off hand.
Nick
^ permalink raw reply
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: Johan Hedberg @ 2010-12-09 14:41 UTC (permalink / raw)
To: roystonr; +Cc: linux-bluetooth, skrovvid, rshaffer
In-Reply-To: <3b53a90114d801b0adba526895deed74.squirrel@www.codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
Hi Royston,
On Thu, Dec 09, 2010, roystonr@codeaurora.org wrote:
> Change expected:
> avdtp_get_seps should be able to provide the SEP of the one used in the
> AVDTP_CLOSE previously. But there weren't any previously closed streams
> then provide the SEP which is not in use (as done currently).
>
> Kindly let us know whether our understanding is right and can this be a
> suspected cause of the issue seen. Correct if mistaken.
Sounds like that might be the cause. Have you experimented with patching
the bluez code to reuse the same SEP as was used for the Close? If not
I'd advice you to do that so we can be sure that a change to the ACP SEP
selection logic makes sense.
Right now the reconfiguration happens in audio/a2dp.c where there's a
setup->reconfigure flag to track if a new stream should be configured
after receiving close_ind. The a2dp_reconfigure function in a2dp.c is
responsible for selecting the remote SEP. Could you try the attached
(completely untested) patch to see if it helps? It stores the old remote
SEP in the setup structure when starting the Close procedure in which
case a2dp_reconfigure() shouldn't try to reselect a new remote SEP but
use the stored one instead.
Johan
[-- Attachment #2: acp_sep_selection.patch --]
[-- Type: text/x-diff, Size: 1602 bytes --]
diff --git a/audio/a2dp.c b/audio/a2dp.c
index b1e94d9..7ed84e9 100644
--- a/audio/a2dp.c
+++ b/audio/a2dp.c
@@ -2032,6 +2032,7 @@ unsigned int a2dp_config(struct avdtp *session, struct a2dp_sep *sep,
error("avdtp_close failed");
goto failed;
}
+ setup->rsep = avdtp_stream_get_remote_sep(tmp->stream);
break;
}
@@ -2061,6 +2062,7 @@ unsigned int a2dp_config(struct avdtp *session, struct a2dp_sep *sep,
error("avdtp_close failed");
goto failed;
}
+ setup->rsep = avdtp_stream_get_remote_sep(sep->stream);
}
break;
default:
diff --git a/audio/avdtp.c b/audio/avdtp.c
index 1683e7c..33178c3 100644
--- a/audio/avdtp.c
+++ b/audio/avdtp.c
@@ -3133,6 +3133,12 @@ gboolean avdtp_stream_has_capabilities(struct avdtp_stream *stream,
return TRUE;
}
+struct avdtp_remote_sep *avdtp_stream_get_remote_sep(
+ struct avdtp_stream *stream)
+{
+ return avdtp_get_remote_sep(stream->session, stream->rseid);
+}
+
gboolean avdtp_stream_get_transport(struct avdtp_stream *stream, int *sock,
uint16_t *imtu, uint16_t *omtu,
GSList **caps)
diff --git a/audio/avdtp.h b/audio/avdtp.h
index 9406fa7..5f37dc3 100644
--- a/audio/avdtp.h
+++ b/audio/avdtp.h
@@ -257,6 +257,8 @@ gboolean avdtp_stream_has_capability(struct avdtp_stream *stream,
struct avdtp_service_capability *cap);
gboolean avdtp_stream_has_capabilities(struct avdtp_stream *stream,
GSList *caps);
+struct avdtp_remote_sep *avdtp_stream_get_remote_sep(
+ struct avdtp_stream *stream);
unsigned int avdtp_add_state_cb(avdtp_session_state_cb cb, void *user_data);
^ permalink raw reply related
* Re: [PATCH v2] Fix compiler flags when CFLAGS is set in the environment
From: Johan Hedberg @ 2010-12-09 14:01 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1291902098-20765-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Dec 09, 2010, Luiz Augusto von Dentz wrote:
> D_FILE_OFFSET_BITS need to be set even if CFLAGS is not empty
> ---
> Makefile.am | 2 +-
> acinclude.m4 | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
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