* Re: linux-next: Tree for March 1 (bluetooth/hci_sysfs)
From: Marcel Holtmann @ 2010-03-03 1:23 UTC (permalink / raw)
To: David Miller
Cc: sfr, randy.dunlap, linux-next, linux-kernel, linux-bluetooth,
netdev
In-Reply-To: <20100301.181415.266447389.davem@davemloft.net>
Hi Dave,
> >> static ssize_t inquiry_cache_read(struct file *file, char __user *userbuf,
> >> size_t count, loff_t *ppos)
> >> {
> >> struct hci_dev *hdev = file->private_data;
> >> struct inquiry_cache *cache = &hdev->inq_cache;
> >> struct inquiry_entry *e;
> >> char buf[4096]; // <<<<<<<<<<<<<<<<<<<<<<<<<<< huh? don't do that on stack.
> >> int n = 0;
> >
> > Dave Miller is following up on that.
>
> This looks like a job for.... SEQ FILE! :-)
>
> I'm testing the following fix.
I have a working and tested patch that uses single_open(). Will send a
patch with commit message and everything in a bit so you can apply it.
Regards
Marcel
^ permalink raw reply
* Re: question about 'read' system call of sco socket
From: Zhu Yanhai @ 2010-03-03 2:42 UTC (permalink / raw)
To: liu yang; +Cc: linux-bluetooth, Tan Miaoqing, Valerio Valerio
In-Reply-To: <55d43d1d1003020628l543e9af6o535d6fd256c58cb0@mail.gmail.com>
On 03/02/2010 10:28 PM, liu yang wrote:
> Hi experts,
> I have one question about 'read' system call of sco socket. I'm using
> an open source library which implements bluetooth handfree profile on
> linux platform. About our use case, cell phone works as audio gateway
> that all audio received on cell phone will be streamed to linux PC,
> and vice versa. Everything works just fine of audio streaming above
> bluetooth channel. But our special application is very sensitive on
> timing that we need send/receive bluetooth audio frame every 20ms.
> Regarding sending direction, I can tweak MTU of bluetooth donglel
> installed on my linux PC. Let's say, MTU is set to 320 bytes, so every
> 20ms 'send' system call only needs be called one time. ( the audio
> frame conveyed aboved bluetooth is of signed linear 16bit per sample,
> 8K sampling-rate ) But this does not affect receiving direction that
> every 'read' system call on sco socket returns exact 48 bytes. Also I
> find such 'read' event on linux 'poll' is triggered every 10ms. Every
> 10ms, such 'read' action is invoked, but it takes 3 or 4 times
> invokation ( sometimes 3 , sometimes 4) of 'read' to consume this
> 'read' event, which results in 'EAGAIN'. So every 20ms, I get 288
> (48*6) or 336 (48*7) bytes, not exact 320 I expect.
>
> Shortly, my question is how to receive ( 'read' system call ) exact
> 320 bytes every 20ms.
>
> Thanks
>
> Kandy
> --
> 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
>
Hi Yang,
I'm not a expert at this. IIRC SCO connection is designed to carry fixed
rated data, which is 64kbps[1]. In your case, you are expecting about
16bit*8K = 128kbps, which is beyond of SCO's capability. Maybe you can
consider creating two SCO links (the upper limit is 3 between two
Bluetooth devices) to carry your data or maybe you could consider using
a eSCO link?
Again, I'm not good at this, just saying...
Regards,
Zhu Yanhai
[1] Bluetooth specification Version 2.1, Vol 1, Page 44,
3.5.5 Synchronous connection-oriented (SCO)
^ permalink raw reply
* Re: [PATCH] Fix using invalid data from previous headset connection
From: Johan Hedberg @ 2010-03-03 3:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <2d5a2c101003021309o34b63249ub5940f67112eab6a@mail.gmail.com>
Hi Luiz,
On Tue, Mar 02, 2010, Luiz Augusto von Dentz wrote:
> Data notiated in a session should be reset once disconnected, to fix
> this a new structure is introduced called headset_session is
> introduced to hold the session data which is freed when disconnected.
In general the idea of the patch is good, but there are a few things
that need some further thinking.
First of all could we just call a "session" what the HFP spec calls it,
i.e. a Service Level Connection, e.g. hs->slc? Or do you have some
better suggestion?
Secondly you need to be careful when doing one-to-one replacements of
existing hs->foo statements with hs->session->foo statements. What if
hs->session is NULL? Are there some valid use cases when a function that
can access hs->session could get called while hs->session is NULL?
Johan
^ permalink raw reply
* Re: [PATCH] Fix using invalid data from previous headset connection
From: Luiz Augusto von Dentz @ 2010-03-03 8:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20100303033233.GA20411@jh-x301>
Hi,
On Wed, Mar 3, 2010 at 5:32 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Luiz,
>
> On Tue, Mar 02, 2010, Luiz Augusto von Dentz wrote:
>> Data notiated in a session should be reset once disconnected, to fix
>> this a new structure is introduced called headset_session is
>> introduced to hold the session data which is freed when disconnected.
>
> In general the idea of the patch is good, but there are a few things
> that need some further thinking.
>
> First of all could we just call a "session" what the HFP spec calls it,
> i.e. a Service Level Connection, e.g. hs->slc? Or do you have some
> better suggestion?
I suggested session since it represents the connection itself, even
the at comands buffer is in the new structure so I guess it doesn't
really represents slc, maybe connection is more suitable since there
could be only one.
> Secondly you need to be careful when doing one-to-one replacements of
> existing hs->foo statements with hs->session->foo statements. What if
> hs->session is NULL? Are there some valid use cases when a function that
> can access hs->session could get called while hs->session is NULL?
Afaik no there aren't, the session represent the lifetime of the
rfcomm connection and the only thing that are accessible are the gains
via dbus interface but we protect them by checking the state and if by
some reason we don't have a session then there is probably a bug so
checking hs->session would probably hide those.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH 1/3] Bluetooth: decode btmrvl MODULE_BRINGUP_REG response correctly
From: Bing Zhao @ 2010-03-03 22:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bing Zhao
btmrvl MODULE_BRINGUP_REQ command response returns success with
either 0x00 or 0x0c.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/bluetooth/btmrvl_drv.h | 5 ++++-
drivers/bluetooth/btmrvl_main.c | 6 ++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index 523d197..bdf5187 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -87,8 +87,11 @@ struct btmrvl_private {
#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
#define BT_CMD_MODULE_CFG_REQ 0x5B
-/* Sub-commands: Module Bringup/Shutdown Request */
+/* Sub-commands: Module Bringup/Shutdown Request/Response */
#define MODULE_BRINGUP_REQ 0xF1
+#define MODULE_BROUGHT_UP 0x00
+#define MODULE_ALREADY_UP 0x0C
+
#define MODULE_SHUTDOWN_REQ 0xF2
#define BT_EVENT_POWER_STATE 0x20
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 53a43ad..31e7412 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -112,8 +112,10 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
case BT_CMD_MODULE_CFG_REQ:
if (priv->btmrvl_dev.sendcmdflag &&
event->data[1] == MODULE_BRINGUP_REQ) {
- BT_DBG("EVENT:%s", (event->data[2]) ?
- "Bring-up failed" : "Bring-up succeed");
+ BT_DBG("EVENT:%s",
+ ((event->data[2] == MODULE_BROUGHT_UP) ||
+ (event->data[2] == MODULE_ALREADY_UP)) ?
+ "Bring-up succeed" : "Bring-up failed");
} else if (priv->btmrvl_dev.sendcmdflag &&
event->data[1] == MODULE_SHUTDOWN_REQ) {
BT_DBG("EVENT:%s", (event->data[2]) ?
--
1.5.3.6
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: separate btmrvl_register_hdev() from btmrvl_add_card()
From: Bing Zhao @ 2010-03-03 22:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bing Zhao
In-Reply-To: <1267655857-10171-1-git-send-email-bzhao@marvell.com>
Move btmrvl hdev registration code out of btmrvl_add_card().
New function btmrvl_register_hdev() is added.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/bluetooth/btmrvl_drv.h | 1 +
drivers/bluetooth/btmrvl_main.c | 75 ++++++++++++++++++++++----------------
drivers/bluetooth/btmrvl_sdio.c | 7 +++-
3 files changed, 50 insertions(+), 33 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index bdf5187..ec8ac5e 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -125,6 +125,7 @@ struct btmrvl_event {
/* Prototype of global function */
+int btmrvl_register_hdev(struct btmrvl_private *priv);
struct btmrvl_private *btmrvl_add_card(void *card);
int btmrvl_remove_card(struct btmrvl_private *priv);
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 31e7412..277cb10 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -524,47 +524,20 @@ static int btmrvl_service_main_thread(void *data)
return 0;
}
-struct btmrvl_private *btmrvl_add_card(void *card)
+int btmrvl_register_hdev(struct btmrvl_private *priv)
{
struct hci_dev *hdev = NULL;
- struct btmrvl_private *priv;
int ret;
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- BT_ERR("Can not allocate priv");
- goto err_priv;
- }
-
- priv->adapter = kzalloc(sizeof(*priv->adapter), GFP_KERNEL);
- if (!priv->adapter) {
- BT_ERR("Allocate buffer for btmrvl_adapter failed!");
- goto err_adapter;
- }
-
- btmrvl_init_adapter(priv);
-
hdev = hci_alloc_dev();
if (!hdev) {
BT_ERR("Can not allocate HCI device");
goto err_hdev;
}
- BT_DBG("Starting kthread...");
- priv->main_thread.priv = priv;
- spin_lock_init(&priv->driver_lock);
-
- init_waitqueue_head(&priv->main_thread.wait_q);
- priv->main_thread.task = kthread_run(btmrvl_service_main_thread,
- &priv->main_thread, "btmrvl_main_service");
-
priv->btmrvl_dev.hcidev = hdev;
- priv->btmrvl_dev.card = card;
-
hdev->driver_data = priv;
- priv->btmrvl_dev.tx_dnld_rdy = true;
-
hdev->bus = HCI_SDIO;
hdev->open = btmrvl_open;
hdev->close = btmrvl_close;
@@ -574,6 +547,8 @@ struct btmrvl_private *btmrvl_add_card(void *card)
hdev->ioctl = btmrvl_ioctl;
hdev->owner = THIS_MODULE;
+ btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
+
ret = hci_register_dev(hdev);
if (ret < 0) {
BT_ERR("Can not register HCI device");
@@ -584,16 +559,52 @@ struct btmrvl_private *btmrvl_add_card(void *card)
btmrvl_debugfs_init(hdev);
#endif
- return priv;
+ return 0;
err_hci_register_dev:
- /* Stop the thread servicing the interrupts */
- kthread_stop(priv->main_thread.task);
-
hci_free_dev(hdev);
err_hdev:
+ /* Stop the thread servicing the interrupts */
+ kthread_stop(priv->main_thread.task);
+
btmrvl_free_adapter(priv);
+ kfree(priv);
+
+ return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(btmrvl_register_hdev);
+
+struct btmrvl_private *btmrvl_add_card(void *card)
+{
+ struct btmrvl_private *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ BT_ERR("Can not allocate priv");
+ goto err_priv;
+ }
+
+ priv->adapter = kzalloc(sizeof(*priv->adapter), GFP_KERNEL);
+ if (!priv->adapter) {
+ BT_ERR("Allocate buffer for btmrvl_adapter failed!");
+ goto err_adapter;
+ }
+
+ btmrvl_init_adapter(priv);
+
+ BT_DBG("Starting kthread...");
+ priv->main_thread.priv = priv;
+ spin_lock_init(&priv->driver_lock);
+
+ init_waitqueue_head(&priv->main_thread.wait_q);
+ priv->main_thread.task = kthread_run(btmrvl_service_main_thread,
+ &priv->main_thread, "btmrvl_main_service");
+
+ priv->btmrvl_dev.card = card;
+ priv->btmrvl_dev.tx_dnld_rdy = true;
+
+ return priv;
err_adapter:
kfree(priv);
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 94f1f55..874a5e8 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -930,7 +930,12 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
priv->hw_host_to_card = btmrvl_sdio_host_to_card;
priv->hw_wakeup_firmware = btmrvl_sdio_wakeup_fw;
- btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
+ if (btmrvl_register_hdev(priv)) {
+ BT_ERR("Register hdev failed!");
+ ret = -ENODEV;
+ goto disable_host_int;
+ }
+
priv->btmrvl_dev.psmode = 1;
btmrvl_enable_ps(priv);
--
1.5.3.6
^ permalink raw reply related
* [PATCH 3/3] Bluetooth: set hdev->dev_type based on Marvell device type
From: Bing Zhao @ 2010-03-03 22:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bing Zhao
In-Reply-To: <1267655857-10171-1-git-send-email-bzhao@marvell.com>
Get the device type from MODULE_BRINGUP_REQ command response.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/bluetooth/btmrvl_drv.h | 2 ++
drivers/bluetooth/btmrvl_main.c | 9 +++++++++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index ec8ac5e..bd91652 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -41,6 +41,8 @@ struct btmrvl_device {
void *card;
struct hci_dev *hcidev;
+ u8 dev_type;
+
u8 tx_dnld_rdy;
u8 psmode;
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 277cb10..956f40c 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -116,6 +116,13 @@ int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb)
((event->data[2] == MODULE_BROUGHT_UP) ||
(event->data[2] == MODULE_ALREADY_UP)) ?
"Bring-up succeed" : "Bring-up failed");
+
+ if (event->length > 3)
+ priv->btmrvl_dev.dev_type = event->data[3];
+ else
+ priv->btmrvl_dev.dev_type = HCI_BREDR;
+
+ BT_DBG("dev_type: %d", priv->btmrvl_dev.dev_type);
} else if (priv->btmrvl_dev.sendcmdflag &&
event->data[1] == MODULE_SHUTDOWN_REQ) {
BT_DBG("EVENT:%s", (event->data[2]) ?
@@ -549,6 +556,8 @@ int btmrvl_register_hdev(struct btmrvl_private *priv)
btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
+ hdev->dev_type = priv->btmrvl_dev.dev_type;
+
ret = hci_register_dev(hdev);
if (ret < 0) {
BT_ERR("Can not register HCI device");
--
1.5.3.6
^ permalink raw reply related
* Linux Bluetooth Coexistence documentation in general and for ath9k
From: Luis R. Rodriguez @ 2010-03-04 0:43 UTC (permalink / raw)
To: linux-wireless
Cc: linux-bluetooth, linux-kernel,
Kevin Hayes" <kevin@atheros.com>, "Dan Tian"
Marcel, a question for you below.
The question of Bluetooth coexistence pops up here, on IRC and on bug
reports quite too often so I've stuffed what I could onto a page with
a few references / code and about ath9k's schemes for BT coexistence,
feel free to extend or correct:
http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
http://wireless.kernel.org/en/users/Drivers/ath9k/btcoex
I'm still not sure if "2-wire" and "3-wire" are generic terms and if
someone owns a trademark on them or what, but looking down the road I
think it would be nice to export this information through nl80211, if
a device supports any of these BT-coex schemes and if so, perhaps
display the current signal status of:
* WLAN_ACTIVE
* BT_PRIORITY
* BT_STATE
I do wonder if this could be useful to network applets like network
manager/connman. The other BT coex schemes are BT specific it seems
and not sure if those devices can expose that information out and
inform userspace of certain events.
Marcel, does the BlueZ support exporting if certain bt-coex schemes
are supported like AFH, channel skipping, TDM, and also if they are
being used and details of that?
Luis
^ permalink raw reply
* Re: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Bastien Nocera @ 2010-03-04 0:59 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-bluetooth, linux-kernel,
Kevin Hayes" <kevin@atheros.com>, "Dan Tian"
In-Reply-To: <43e72e891003031643u353c72dcj23bf429363a16ec8@mail.gmail.com>
On Wed, 2010-03-03 at 16:43 -0800, Luis R. Rodriguez wrote:
> Marcel, a question for you below.
>
> The question of Bluetooth coexistence pops up here, on IRC and on bug
> reports quite too often so I've stuffed what I could onto a page with
> a few references / code and about ath9k's schemes for BT coexistence,
> feel free to extend or correct:
<snip>
> I do wonder if this could be useful to network applets like network
> manager/connman.
Not really. To me, it sounds like a "make it work" button. The kernel
bits of Bluetooth should already have an idea of when a device is
connected, so the kernel should be able to "do the right thing".
Having options over what "the right thing" is is probably a good idea
whilst the kinks are worked out from the default behaviour, but this is
not something that should be advertised to users.
> The other BT coex schemes are BT specific it seems
> and not sure if those devices can expose that information out and
> inform userspace of certain events.
Cheers
^ permalink raw reply
* Re: [PATCH] Fix using invalid data from previous headset connection
From: Johan Hedberg @ 2010-03-04 3:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <2d5a2c101003030025v40b2ca4ma985e5a544d7e707@mail.gmail.com>
Hi Luiz,
On Wed, Mar 03, 2010, Luiz Augusto von Dentz wrote:
> > First of all could we just call a "session" what the HFP spec calls it,
> > i.e. a Service Level Connection, e.g. hs->slc? Or do you have some
> > better suggestion?
>
> I suggested session since it represents the connection itself, even
> the at comands buffer is in the new structure so I guess it doesn't
> really represents slc, maybe connection is more suitable since there
> could be only one.
True, though "connection" is longer than "session" and we should try to
use something that's short and clean. IMHO "slc" isn't totally bad even
though the data is already used before the SLC establishment is fully
completed. You could think of it as "data needed for SLC establishment
and state handling" in which case the name would be kind of justified.
> > Secondly you need to be careful when doing one-to-one replacements of
> > existing hs->foo statements with hs->session->foo statements. What if
> > hs->session is NULL? Are there some valid use cases when a function that
> > can access hs->session could get called while hs->session is NULL?
>
> Afaik no there aren't, the session represent the lifetime of the
> rfcomm connection and the only thing that are accessible are the gains
> via dbus interface but we protect them by checking the state and if by
> some reason we don't have a session then there is probably a bug so
> checking hs->session would probably hide those.
There's also the telephony driver that can call into headset.c. However,
I suppose that case could also be considered a bug in the driver if it
does these calls while there's no connection. It's probably still a good
idea to check if the current drivers (particularly telephony-maemo.c) do
anything like this.
Johan
^ permalink raw reply
* Re: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Luis R. Rodriguez @ 2010-03-04 5:09 UTC (permalink / raw)
To: Bastien Nocera
Cc: linux-wireless, linux-bluetooth, linux-kernel,
Kevin Hayes" <kevin@atheros.com>, "Dan Tian"
In-Reply-To: <1267664353.10407.1960.camel@localhost.localdomain>
On Wed, Mar 3, 2010 at 4:59 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Wed, 2010-03-03 at 16:43 -0800, Luis R. Rodriguez wrote:
>> Marcel, a question for you below.
>>
>> The question of Bluetooth coexistence pops up here, on IRC and on bug
>> reports quite too often so I've stuffed what I could onto a page with
>> a few references / code and about ath9k's schemes for BT coexistence,
>> feel free to extend or correct:
> <snip>
>> I do wonder if this could be useful to network applets like network
>> manager/connman.
>
> Not really. To me, it sounds like a "make it work" button. The kernel
> bits of Bluetooth should already have an idea of when a device is
> connected, so the kernel should be able to "do the right thing".
>
> Having options over what "the right thing" is is probably a good idea
> whilst the kinks are worked out from the default behaviour, but this is
> not something that should be advertised to users.
I wasn't really thinking of buttons for BT coex, but instead just
information exposed out and making it available. Reason for this is
users tend to be blind about btcoex stuff and it would be nice if we
had a way to inform the user of the btcoex mechanisms that actually
are being used. Does that change your answer?
Luis
^ permalink raw reply
* Re: [PATCH] Fix using invalid data from previous headset connection
From: Luiz Augusto von Dentz @ 2010-03-04 8:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20100304035014.GA26956@jh-x301>
Hi Johan,
On Thu, Mar 4, 2010 at 5:50 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Luiz,
>
> On Wed, Mar 03, 2010, Luiz Augusto von Dentz wrote:
>> > First of all could we just call a "session" what the HFP spec calls it,
>> > i.e. a Service Level Connection, e.g. hs->slc? Or do you have some
>> > better suggestion?
>>
>> I suggested session since it represents the connection itself, even
>> the at comands buffer is in the new structure so I guess it doesn't
>> really represents slc, maybe connection is more suitable since there
>> could be only one.
>
> True, though "connection" is longer than "session" and we should try to
> use something that's short and clean. IMHO "slc" isn't totally bad even
> though the data is already used before the SLC establishment is fully
> completed. You could think of it as "data needed for SLC establishment
> and state handling" in which case the name would be kind of justified.
Yep, I will update the name to slc.
>> > Secondly you need to be careful when doing one-to-one replacements of
>> > existing hs->foo statements with hs->session->foo statements. What if
>> > hs->session is NULL? Are there some valid use cases when a function that
>> > can access hs->session could get called while hs->session is NULL?
>>
>> Afaik no there aren't, the session represent the lifetime of the
>> rfcomm connection and the only thing that are accessible are the gains
>> via dbus interface but we protect them by checking the state and if by
>> some reason we don't have a session then there is probably a bug so
>> checking hs->session would probably hide those.
>
> There's also the telephony driver that can call into headset.c. However,
> I suppose that case could also be considered a bug in the driver if it
> does these calls while there's no connection. It's probably still a good
> idea to check if the current drivers (particularly telephony-maemo.c) do
> anything like this.
I will give telephony-maemo a try, so far I didn't experience any problem.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Pacho Ramos @ 2010-03-04 8:37 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
Hello
bluez installs stuff into /etc/alsa and it seems wrong since default
location for alsa stuff seems to be /usr/share/alsa instead. You can
also see that this is been workarounded in ubuntu, gentoo (and probably
debian also).
Any reason why using /etc/alsa instead?
Thanks a lot
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Bastien Nocera @ 2010-03-04 10:18 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-bluetooth, linux-kernel,
Kevin Hayes" <kevin@atheros.com>, "Dan Tian"
In-Reply-To: <43e72e891003032109v59f1ff52odb60de6111cfec53@mail.gmail.com>
On Wed, 2010-03-03 at 21:09 -0800, Luis R. Rodriguez wrote:
> On Wed, Mar 3, 2010 at 4:59 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Wed, 2010-03-03 at 16:43 -0800, Luis R. Rodriguez wrote:
> >> Marcel, a question for you below.
> >>
> >> The question of Bluetooth coexistence pops up here, on IRC and on bug
> >> reports quite too often so I've stuffed what I could onto a page with
> >> a few references / code and about ath9k's schemes for BT coexistence,
> >> feel free to extend or correct:
> > <snip>
> >> I do wonder if this could be useful to network applets like network
> >> manager/connman.
> >
> > Not really. To me, it sounds like a "make it work" button. The kernel
> > bits of Bluetooth should already have an idea of when a device is
> > connected, so the kernel should be able to "do the right thing".
> >
> > Having options over what "the right thing" is is probably a good idea
> > whilst the kinks are worked out from the default behaviour, but this is
> > not something that should be advertised to users.
>
> I wasn't really thinking of buttons for BT coex, but instead just
> information exposed out and making it available. Reason for this is
> users tend to be blind about btcoex stuff and it would be nice if we
> had a way to inform the user of the btcoex mechanisms that actually
> are being used. Does that change your answer?
No, not really. It could be useful as a debugging statement in the
kernel, or in bluetoothd might be helpful, but I'm not sure why users
would need to be told about the BT coex support, or what type is being
used.
It's probably too much information for the users. Though if it's
available in the kernel, one could get it fairly easily if enquiring.
Cheers
^ permalink raw reply
* Re: [PATCH] Fix using invalid data from previous headset connection
From: Luiz Augusto von Dentz @ 2010-03-04 14:29 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <2d5a2c101003040032g70434725ne3ad56042a080ed9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]
Hi Johan,
On Thu, Mar 4, 2010 at 10:32 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Johan,
>
> On Thu, Mar 4, 2010 at 5:50 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi Luiz,
>>
>> On Wed, Mar 03, 2010, Luiz Augusto von Dentz wrote:
>>> > First of all could we just call a "session" what the HFP spec calls it,
>>> > i.e. a Service Level Connection, e.g. hs->slc? Or do you have some
>>> > better suggestion?
>>>
>>> I suggested session since it represents the connection itself, even
>>> the at comands buffer is in the new structure so I guess it doesn't
>>> really represents slc, maybe connection is more suitable since there
>>> could be only one.
>>
>> True, though "connection" is longer than "session" and we should try to
>> use something that's short and clean. IMHO "slc" isn't totally bad even
>> though the data is already used before the SLC establishment is fully
>> completed. You could think of it as "data needed for SLC establishment
>> and state handling" in which case the name would be kind of justified.
>
> Yep, I will update the name to slc.
>
>>> > Secondly you need to be careful when doing one-to-one replacements of
>>> > existing hs->foo statements with hs->session->foo statements. What if
>>> > hs->session is NULL? Are there some valid use cases when a function that
>>> > can access hs->session could get called while hs->session is NULL?
>>>
>>> Afaik no there aren't, the session represent the lifetime of the
>>> rfcomm connection and the only thing that are accessible are the gains
>>> via dbus interface but we protect them by checking the state and if by
>>> some reason we don't have a session then there is probably a bug so
>>> checking hs->session would probably hide those.
>>
>> There's also the telephony driver that can call into headset.c. However,
>> I suppose that case could also be considered a bug in the driver if it
>> does these calls while there's no connection. It's probably still a good
>> idea to check if the current drivers (particularly telephony-maemo.c) do
>> anything like this.
>
> I will give telephony-maemo a try, so far I didn't experience any problem.
Attached is a new version no using slc instead of session, so far no
problem with any telephony driver.
--
Luiz Augusto von Dentz
Computer Engineer
[-- Attachment #2: 0010-Fix-using-invalid-data-from-previous-headset-connect.patch --]
[-- Type: text/x-patch, Size: 17535 bytes --]
From 841c29dfadd5e7c8f66e82669bb6c9a4f1714cc7 Mon Sep 17 00:00:00 2001
From: Luiz Augusto Von Dentz <luiz.dentz-von@nokia.com>
Date: Thu, 4 Mar 2010 10:45:13 +0200
Subject: [PATCH 10/11] Fix using invalid data from previous headset connection
Data from previous connection should be reset once disconnected, to fix
this a new structure is introduced called headset_slc which represents
the Service Level Connection and hold the connection data which is freed
when disconnected.
---
audio/headset.c | 187 +++++++++++++++++++++++++++++++------------------------
1 files changed, 106 insertions(+), 81 deletions(-)
diff --git a/audio/headset.c b/audio/headset.c
index 7002a3a..15d3672 100644
--- a/audio/headset.c
+++ b/audio/headset.c
@@ -128,6 +128,25 @@ struct pending_connect {
uint16_t svclass;
};
+struct headset_slc {
+ char buf[BUF_SIZE];
+ int data_start;
+ int data_length;
+
+ gboolean cli_active;
+ gboolean cme_enabled;
+ gboolean cwa_enabled;
+ gboolean pending_ring;
+ gboolean inband_ring;
+ gboolean nrec;
+ gboolean nrec_req;
+
+ int sp_gain;
+ int mic_gain;
+
+ unsigned int hf_features;
+};
+
struct headset {
uint32_t hsp_handle;
uint32_t hfp_handle;
@@ -144,28 +163,14 @@ struct headset {
guint dc_timer;
- char buf[BUF_SIZE];
- int data_start;
- int data_length;
-
gboolean hfp_active;
gboolean search_hfp;
- gboolean cli_active;
- gboolean cme_enabled;
- gboolean cwa_enabled;
- gboolean pending_ring;
- gboolean inband_ring;
- gboolean nrec;
- gboolean nrec_req;
headset_state_t state;
struct pending_connect *pending;
- int sp_gain;
- int mic_gain;
-
- unsigned int hf_features;
headset_lock_t lock;
+ struct headset_slc *slc;
};
struct event {
@@ -338,14 +343,15 @@ static int headset_send(struct headset *hs, char *format, ...)
static int supported_features(struct audio_device *device, const char *buf)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
int err;
if (strlen(buf) < 9)
return -EINVAL;
- hs->hf_features = strtoul(&buf[8], NULL, 10);
+ slc->hf_features = strtoul(&buf[8], NULL, 10);
- print_hf_features(hs->hf_features);
+ print_hf_features(slc->hf_features);
err = headset_send(hs, "\r\n+BRSF: %u\r\n", ag.features);
if (err < 0)
@@ -534,10 +540,12 @@ static void send_foreach_headset(GSList *devices,
static int cli_cmp(struct headset *hs)
{
+ struct headset_slc *slc = hs->slc;
+
if (!hs->hfp_active)
return -1;
- if (hs->cli_active)
+ if (slc->cli_active)
return 0;
else
return -1;
@@ -560,6 +568,7 @@ static void sco_connect_cb(GIOChannel *chan, GError *err, gpointer user_data)
int sk;
struct audio_device *dev = user_data;
struct headset *hs = dev->headset;
+ struct headset_slc *slc = hs->slc;
struct pending_connect *p = hs->pending;
if (err) {
@@ -599,12 +608,12 @@ static void sco_connect_cb(GIOChannel *chan, GError *err, gpointer user_data)
headset_set_state(dev, HEADSET_STATE_PLAYING);
- if (hs->pending_ring) {
+ if (slc->pending_ring) {
ring_timer_cb(NULL);
ag.ring_timer = g_timeout_add_seconds(RING_INTERVAL,
ring_timer_cb,
NULL);
- hs->pending_ring = FALSE;
+ slc->pending_ring = FALSE;
}
}
@@ -684,9 +693,10 @@ static void hfp_slc_complete(struct audio_device *dev)
static int telephony_generic_rsp(struct audio_device *device, cme_error_t err)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
if (err != CME_ERROR_NONE) {
- if (hs->cme_enabled)
+ if (slc->cme_enabled)
return headset_send(hs, "\r\n+CME ERROR: %d\r\n", err);
else
return headset_send(hs, "\r\nERROR\r\n");
@@ -699,6 +709,7 @@ int telephony_event_reporting_rsp(void *telephony_device, cme_error_t err)
{
struct audio_device *device = telephony_device;
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
int ret;
if (err != CME_ERROR_NONE)
@@ -711,7 +722,7 @@ int telephony_event_reporting_rsp(void *telephony_device, cme_error_t err)
if (hs->state != HEADSET_STATE_CONNECTING)
return 0;
- if (hs->hf_features & HF_FEATURE_CALL_WAITING_AND_3WAY &&
+ if (slc->hf_features & HF_FEATURE_CALL_WAITING_AND_3WAY &&
ag.features & AG_FEATURE_THREE_WAY_CALLING)
return 0;
@@ -865,11 +876,12 @@ static int terminate_call(struct audio_device *device, const char *buf)
static int cli_notification(struct audio_device *device, const char *buf)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
if (strlen(buf) < 9)
return -EINVAL;
- hs->cli_active = buf[8] == '1' ? TRUE : FALSE;
+ slc->cli_active = buf[8] == '1' ? TRUE : FALSE;
return headset_send(hs, "\r\nOK\r\n");
}
@@ -937,6 +949,7 @@ static int dial_number(struct audio_device *device, const char *buf)
static int signal_gain_setting(struct audio_device *device, const char *buf)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
const char *property;
const char *name;
dbus_uint16_t gain;
@@ -955,18 +968,18 @@ static int signal_gain_setting(struct audio_device *device, const char *buf)
switch (buf[5]) {
case HEADSET_GAIN_SPEAKER:
- if (hs->sp_gain == gain)
+ if (slc->sp_gain == gain)
goto ok;
name = "SpeakerGainChanged";
property = "SpeakerGain";
- hs->sp_gain = gain;
+ slc->sp_gain = gain;
break;
case HEADSET_GAIN_MICROPHONE:
- if (hs->mic_gain == gain)
+ if (slc->mic_gain == gain)
goto ok;
name = "MicrophoneGainChanged";
property = "MicrophoneGain";
- hs->mic_gain = gain;
+ slc->mic_gain = gain;
break;
default:
error("Unknown gain setting");
@@ -1030,15 +1043,16 @@ static int list_current_calls(struct audio_device *device, const char *buf)
static int extended_errors(struct audio_device *device, const char *buf)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
if (strlen(buf) < 9)
return -EINVAL;
if (buf[8] == '1') {
- hs->cme_enabled = TRUE;
+ slc->cme_enabled = TRUE;
debug("CME errors enabled for headset %p", hs);
} else {
- hs->cme_enabled = FALSE;
+ slc->cme_enabled = FALSE;
debug("CME errors disabled for headset %p", hs);
}
@@ -1048,15 +1062,16 @@ static int extended_errors(struct audio_device *device, const char *buf)
static int call_waiting_notify(struct audio_device *device, const char *buf)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
if (strlen(buf) < 9)
return -EINVAL;
if (buf[8] == '1') {
- hs->cwa_enabled = TRUE;
+ slc->cwa_enabled = TRUE;
debug("Call waiting notification enabled for headset %p", hs);
} else {
- hs->cwa_enabled = FALSE;
+ slc->cwa_enabled = FALSE;
debug("Call waiting notification disabled for headset %p", hs);
}
@@ -1077,9 +1092,10 @@ int telephony_nr_and_ec_rsp(void *telephony_device, cme_error_t err)
{
struct audio_device *device = telephony_device;
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
if (err == CME_ERROR_NONE)
- hs->nrec = hs->nrec_req;
+ slc->nrec = hs->slc->nrec_req;
return telephony_generic_rsp(telephony_device, err);
}
@@ -1123,16 +1139,17 @@ static int operator_selection(struct audio_device *device, const char *buf)
static int nr_and_ec(struct audio_device *device, const char *buf)
{
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
if (strlen(buf) < 9)
return -EINVAL;
if (buf[8] == '0')
- hs->nrec_req = FALSE;
+ slc->nrec_req = FALSE;
else
- hs->nrec_req = TRUE;
+ slc->nrec_req = TRUE;
- telephony_nr_and_ec_req(device, hs->nrec_req);
+ telephony_nr_and_ec_req(device, slc->nrec_req);
return 0;
}
@@ -1214,6 +1231,7 @@ static gboolean rfcomm_io_cb(GIOChannel *chan, GIOCondition cond,
struct audio_device *device)
{
struct headset *hs;
+ struct headset_slc *slc;
unsigned char buf[BUF_SIZE];
gsize bytes_read = 0;
gsize free_space;
@@ -1222,6 +1240,7 @@ static gboolean rfcomm_io_cb(GIOChannel *chan, GIOCondition cond,
return FALSE;
hs = device->headset;
+ slc = hs->slc;
if (cond & (G_IO_ERR | G_IO_HUP)) {
debug("ERR or HUP on RFCOMM socket");
@@ -1232,7 +1251,8 @@ static gboolean rfcomm_io_cb(GIOChannel *chan, GIOCondition cond,
&bytes_read) != G_IO_ERROR_NONE)
return TRUE;
- free_space = sizeof(hs->buf) - hs->data_start - hs->data_length - 1;
+ free_space = sizeof(slc->buf) - slc->data_start -
+ slc->data_length - 1;
if (free_space < bytes_read) {
/* Very likely that the HS is sending us garbage so
@@ -1241,45 +1261,45 @@ static gboolean rfcomm_io_cb(GIOChannel *chan, GIOCondition cond,
goto failed;
}
- memcpy(&hs->buf[hs->data_start], buf, bytes_read);
- hs->data_length += bytes_read;
+ memcpy(&slc->buf[slc->data_start], buf, bytes_read);
+ slc->data_length += bytes_read;
/* Make sure the data is null terminated so we can use string
* functions */
- hs->buf[hs->data_start + hs->data_length] = '\0';
+ slc->buf[slc->data_start + slc->data_length] = '\0';
- while (hs->data_length > 0) {
+ while (slc->data_length > 0) {
char *cr;
int err;
off_t cmd_len;
- cr = strchr(&hs->buf[hs->data_start], '\r');
+ cr = strchr(&slc->buf[slc->data_start], '\r');
if (!cr)
break;
- cmd_len = 1 + (off_t) cr - (off_t) &hs->buf[hs->data_start];
+ cmd_len = 1 + (off_t) cr - (off_t) &slc->buf[slc->data_start];
*cr = '\0';
if (cmd_len > 1)
- err = handle_event(device, &hs->buf[hs->data_start]);
+ err = handle_event(device, &slc->buf[slc->data_start]);
else
/* Silently skip empty commands */
err = 0;
if (err == -EINVAL) {
error("Badly formated or unrecognized command: %s",
- &hs->buf[hs->data_start]);
+ &slc->buf[slc->data_start]);
err = headset_send(hs, "\r\nERROR\r\n");
} else if (err < 0)
error("Error handling command %s: %s (%d)",
- &hs->buf[hs->data_start],
+ &slc->buf[slc->data_start],
strerror(-err), -err);
- hs->data_start += cmd_len;
- hs->data_length -= cmd_len;
+ slc->data_start += cmd_len;
+ slc->data_length -= cmd_len;
- if (!hs->data_length)
- hs->data_start = 0;
+ if (!slc->data_length)
+ slc->data_start = 0;
}
return TRUE;
@@ -1337,6 +1357,9 @@ void headset_connect_cb(GIOChannel *chan, GError *err, gpointer user_data)
debug("%s: Connected to %s", dev->path, hs_address);
+ hs->slc = g_new0(struct headset_slc, 1);
+ hs->slc->nrec = TRUE;
+
/* In HFP mode wait for Service Level Connection */
if (hs->hfp_active)
return;
@@ -1811,10 +1834,11 @@ static DBusMessage *hs_get_speaker_gain(DBusConnection *conn,
{
struct audio_device *device = data;
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
DBusMessage *reply;
dbus_uint16_t gain;
- if (hs->state < HEADSET_STATE_CONNECTED || hs->sp_gain < 0)
+ if (hs->state < HEADSET_STATE_CONNECTED)
return g_dbus_create_error(msg, ERROR_INTERFACE ".NotAvailable",
"Operation not Available");
@@ -1822,7 +1846,7 @@ static DBusMessage *hs_get_speaker_gain(DBusConnection *conn,
if (!reply)
return NULL;
- gain = (dbus_uint16_t) hs->sp_gain;
+ gain = (dbus_uint16_t) slc->sp_gain;
dbus_message_append_args(reply, DBUS_TYPE_UINT16, &gain,
DBUS_TYPE_INVALID);
@@ -1836,10 +1860,11 @@ static DBusMessage *hs_get_mic_gain(DBusConnection *conn,
{
struct audio_device *device = data;
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
DBusMessage *reply;
dbus_uint16_t gain;
- if (hs->state < HEADSET_STATE_CONNECTED || hs->mic_gain < 0)
+ if (hs->state < HEADSET_STATE_CONNECTED || slc == NULL)
return g_dbus_create_error(msg, ERROR_INTERFACE ".NotAvailable",
"Operation not Available");
@@ -1847,7 +1872,7 @@ static DBusMessage *hs_get_mic_gain(DBusConnection *conn,
if (!reply)
return NULL;
- gain = (dbus_uint16_t) hs->mic_gain;
+ gain = (dbus_uint16_t) slc->mic_gain;
dbus_message_append_args(reply, DBUS_TYPE_UINT16, &gain,
DBUS_TYPE_INVALID);
@@ -1862,6 +1887,7 @@ static DBusMessage *hs_set_gain(DBusConnection *conn,
{
struct audio_device *device = data;
struct headset *hs = device->headset;
+ struct headset_slc *slc = hs->slc;
DBusMessage *reply;
int err;
@@ -1891,14 +1917,14 @@ static DBusMessage *hs_set_gain(DBusConnection *conn,
done:
if (type == HEADSET_GAIN_SPEAKER) {
- hs->sp_gain = gain;
+ slc->sp_gain = gain;
g_dbus_emit_signal(conn, device->path,
AUDIO_HEADSET_INTERFACE,
"SpeakerGainChanged",
DBUS_TYPE_UINT16, &gain,
DBUS_TYPE_INVALID);
} else {
- hs->mic_gain = gain;
+ slc->mic_gain = gain;
g_dbus_emit_signal(conn, device->path,
AUDIO_HEADSET_INTERFACE,
"MicrophoneGainChanged",
@@ -1975,11 +2001,13 @@ static DBusMessage *hs_get_properties(DBusConnection *conn,
/* SpeakerGain */
dict_append_entry(&dict, "SpeakerGain",
- DBUS_TYPE_UINT16, &device->headset->sp_gain);
+ DBUS_TYPE_UINT16,
+ &device->headset->slc->sp_gain);
/* MicrophoneGain */
dict_append_entry(&dict, "MicrophoneGain",
- DBUS_TYPE_UINT16, &device->headset->mic_gain);
+ DBUS_TYPE_UINT16,
+ &device->headset->slc->mic_gain);
done:
dbus_message_iter_close_container(&iter, &dict);
@@ -2118,10 +2146,8 @@ static int headset_close_rfcomm(struct audio_device *dev)
hs->rfcomm = NULL;
}
- hs->data_start = 0;
- hs->data_length = 0;
-
- hs->nrec = TRUE;
+ g_free(hs->slc);
+ hs->slc = NULL;
return 0;
}
@@ -2176,12 +2202,7 @@ struct headset *headset_init(struct audio_device *dev, uint16_t svc,
hs = g_new0(struct headset, 1);
hs->rfcomm_ch = -1;
- hs->sp_gain = -1;
- hs->mic_gain = -1;
hs->search_hfp = server_is_enabled(&dev->src, HANDSFREE_SVCLASS_ID);
- hs->hfp_active = FALSE;
- hs->cli_active = FALSE;
- hs->nrec = TRUE;
record = btd_device_get_record(dev->btd_dev, uuidstr);
if (!record)
@@ -2424,18 +2445,19 @@ int headset_connect_rfcomm(struct audio_device *dev, GIOChannel *io)
int headset_connect_sco(struct audio_device *dev, GIOChannel *io)
{
struct headset *hs = dev->headset;
+ struct headset_slc *slc = hs->slc;
if (hs->sco)
return -EISCONN;
hs->sco = g_io_channel_ref(io);
- if (hs->pending_ring) {
+ if (slc->pending_ring) {
ring_timer_cb(NULL);
ag.ring_timer = g_timeout_add_seconds(RING_INTERVAL,
ring_timer_cb,
NULL);
- hs->pending_ring = FALSE;
+ slc->pending_ring = FALSE;
}
return 0;
@@ -2454,6 +2476,7 @@ static void disconnect_cb(struct btd_device *btd_dev, gboolean removal,
void headset_set_state(struct audio_device *dev, headset_state_t state)
{
struct headset *hs = dev->headset;
+ struct headset_slc *slc = hs->slc;
gboolean value;
const char *state_str;
headset_state_t old_state = hs->state;
@@ -2499,9 +2522,9 @@ void headset_set_state(struct audio_device *dev, headset_state_t state)
DBUS_TYPE_STRING, &state_str);
if (hs->state < state) {
if (ag.features & AG_FEATURE_INBAND_RINGTONE)
- hs->inband_ring = TRUE;
+ slc->inband_ring = TRUE;
else
- hs->inband_ring = FALSE;
+ slc->inband_ring = FALSE;
g_dbus_emit_signal(dev->conn, dev->path,
AUDIO_HEADSET_INTERFACE,
"Connected",
@@ -2546,10 +2569,10 @@ void headset_set_state(struct audio_device *dev, headset_state_t state)
AUDIO_HEADSET_INTERFACE, "Playing",
DBUS_TYPE_BOOLEAN, &value);
- if (hs->sp_gain >= 0)
- headset_send(hs, "\r\n+VGS=%u\r\n", hs->sp_gain);
- if (hs->mic_gain >= 0)
- headset_send(hs, "\r\n+VGM=%u\r\n", hs->mic_gain);
+ if (slc->sp_gain >= 0)
+ headset_send(hs, "\r\n+VGS=%u\r\n", slc->sp_gain);
+ if (slc->mic_gain >= 0)
+ headset_send(hs, "\r\n+VGM=%u\r\n", slc->mic_gain);
break;
}
@@ -2658,7 +2681,7 @@ gboolean headset_get_nrec(struct audio_device *dev)
{
struct headset *hs = dev->headset;
- return hs->nrec;
+ return hs->slc->nrec;
}
gboolean headset_get_sco_hci(struct audio_device *dev)
@@ -2715,6 +2738,7 @@ int telephony_incoming_call_ind(const char *number, int type)
{
struct audio_device *dev;
struct headset *hs;
+ struct headset_slc *slc;
if (!active_devices)
return -ENODEV;
@@ -2722,6 +2746,7 @@ int telephony_incoming_call_ind(const char *number, int type)
/* Get the latest connected device */
dev = active_devices->data;
hs = dev->headset;
+ slc = hs->slc;
if (ag.ring_timer) {
debug("telephony_incoming_call_ind: already calling");
@@ -2730,16 +2755,16 @@ int telephony_incoming_call_ind(const char *number, int type)
/* With HSP 1.2 the RING messages should *not* be sent if inband
* ringtone is being used */
- if (!hs->hfp_active && hs->inband_ring)
+ if (!hs->hfp_active && slc->inband_ring)
return 0;
g_free(ag.number);
ag.number = g_strdup(number);
ag.number_type = type;
- if (hs->inband_ring && hs->hfp_active &&
+ if (slc->inband_ring && hs->hfp_active &&
hs->state != HEADSET_STATE_PLAYING) {
- hs->pending_ring = TRUE;
+ slc->pending_ring = TRUE;
return 0;
}
@@ -2765,10 +2790,10 @@ int telephony_calling_stopped_ind(void)
/* In case SCO isn't fully up yet */
dev = active_devices->data;
- if (!dev->headset->pending_ring && !ag.ring_timer)
+ if (!dev->headset->slc->pending_ring && !ag.ring_timer)
return -EINVAL;
- dev->headset->pending_ring = FALSE;
+ dev->headset->slc->pending_ring = FALSE;
return 0;
}
@@ -2826,7 +2851,7 @@ static int cwa_cmp(struct headset *hs)
if (!hs->hfp_active)
return -1;
- if (hs->cwa_enabled)
+ if (hs->slc->cwa_enabled)
return 0;
else
return -1;
--
1.6.3.3
^ permalink raw reply related
* Re: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Marcel Holtmann @ 2010-03-04 15:10 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-bluetooth, linux-kernel,
Kevin Hayes" <kevin@atheros.com>, "Dan Tian"
In-Reply-To: <43e72e891003031643u353c72dcj23bf429363a16ec8@mail.gmail.com>
Hi Luis,
> The question of Bluetooth coexistence pops up here, on IRC and on bug
> reports quite too often so I've stuffed what I could onto a page with
> a few references / code and about ath9k's schemes for BT coexistence,
> feel free to extend or correct:
>
> http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
> http://wireless.kernel.org/en/users/Drivers/ath9k/btcoex
>
> I'm still not sure if "2-wire" and "3-wire" are generic terms and if
> someone owns a trademark on them or what, but looking down the road I
> think it would be nice to export this information through nl80211, if
> a device supports any of these BT-coex schemes and if so, perhaps
> display the current signal status of:
>
> * WLAN_ACTIVE
> * BT_PRIORITY
> * BT_STATE
>
> I do wonder if this could be useful to network applets like network
> manager/connman. The other BT coex schemes are BT specific it seems
> and not sure if those devices can expose that information out and
> inform userspace of certain events.
>
> Marcel, does the BlueZ support exporting if certain bt-coex schemes
> are supported like AFH, channel skipping, TDM, and also if they are
> being used and details of that?
the only thing the host has control over is AFH channel map, and even
modifying that is not really needed. The Bluetooth controller will do
AFH automatically and it is on by default. We never switch that off
actually.
Normally the co-ex stuff is hard-wired between the Bluetooth and WiFi
and thus out of control to the host OS.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Fix using invalid data from previous headset connection
From: Johan Hedberg @ 2010-03-04 20:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <2d5a2c101003040629m39a89b32he5112bcf6e0d2047@mail.gmail.com>
Hi Luiz,
On Thu, Mar 04, 2010, Luiz Augusto von Dentz wrote:
> Attached is a new version no using slc instead of session,
Thanks. The patch is now pushed upstream.
> so far no problem with any telephony driver.
Ok, good. I think that we're protected by this thanks to the
"if (!active_devices)" check in most telephony*_ind functions.
Johan
^ permalink raw reply
* RFC: QuIC's AMP + eL2CAP Technical Plans
From: tmonahan @ 2010-03-04 22:49 UTC (permalink / raw)
To: linux-bluetooth
QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora Forum)
is planning an implementation of AMP for BlueZ. Here are some details of
our technical approach. We are interested in comments from the BlueZ
development community on validity and whether there are areas we have
missed.
Features:
- Completion of L2CAP with ERTM
- Addition of L2CAP Channel Management and AMP Manager
- DBUS support to access AMP features, control AMP settings, etc.
- Updates to Test Programs (hcidump, hciemu, l2test, ...)
- Creation of a Fake PAL to facilitate desktop development using wired TCP
- Legacy L2CAP sockets take advantage of AMP, if so enabled using new
controls (sockopts or DBUS)
- Key Management extended for AMP Controller Keys
L2CAP and ERTM
--------------
A prerequisite for AMP support is a fully functional L2CAP ERTM
implementation, including optional L2CAP features not currently included
in BlueZ.
Our overall approach is to build on the existing ERTM code in the
bluetooth-testing tree, extending the present socket interfaces that are
visible to userspace. The extensions we foresee are sockopt configuration
of MPS (max PDU size), TX window size (currently hard coded), and a simple
AMP control policy ("BR/EDR only", "initiate on or move to AMP", or
"initiate on or move to BR/EDR, allow incoming move").
There are a few protocol-level enhancements required. One is to support
L2CAP lockstep configuration, in addition to the present standard
configuration process. Another addition is support for the extended TX
window option.
Core ERTM functionality (without the proposed additional features) is
still a work in progress, and the main area that needs attention is the
implementation of the transmitter (XMIT and WAIT_F) and receiver (RECV and
SREJ_SENT) state tables as defined in the ERTM spec.
L2CAP and Channel Management for AMP
------------------------------------
Once ERTM is working without AMP, the state machine will have to be
extended to account for the extra demands of creating channels directly on
an AMP controller and AMP channel moves. L2CAP will have to deal with two
controllers (BR/EDR and AMP) while the channel move is taking place, and
correctly handle lockstep reconfiguration of the L2CAP channel when the
move is completing.
To enable AMP, L2CAP itself will need to be enhanced to support the A2MP
fixed channel and to use the AMP Manager to create/disconnect physical and
logical links on an AMP controller. Additionally L2CAP will need to
manage channels according to the new AMP control, moving them as
appropriate and handling remote move requests.
The AMP Manager function will need to be created. It will support
signaling on the A2MP channel and the create/disconnect of AMP physical
and logical links.
HCI will need to be extended to support data-block-based flow control. AMP
Controllers will be presented to BlueZ as HCI devices of a new type.
DBUS Additions (bluetoothd)
---------------------------
org.bluez.Adapter : A new property is added, containing a list of the
associated org.bluez.AmpAdapter objects ("/org/bluez/amp{0, 1, 2, ...}").
Associating a given AmpAdapter to a parent BR/EDR device
("/org/bluez/hci{n}") is one method of org.bluez.AmpAdapter . AmpAdapter
has other methods to obtain the local controller's type and status, and
the number of physical links it carries, and to mark whether it is
available for use by the Amp Manager.
org.bluez.Device : A new method begins the AMP Discovery procedure for
that Device; an alternative would be to add the procedure to what
DiscoverServices() does. A new property contains the cached remote AMP
Device list.
Request for Comment
-------------------
Comments, omissions and suggestions for improvement are invited.
Regards,
Tim Monahan-Mitchell | Qualcomm Innovation Center, Inc |
tmonahan@codeaurora.org
^ permalink raw reply
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: Marcel Holtmann @ 2010-03-05 1:41 UTC (permalink / raw)
To: tmonahan; +Cc: linux-bluetooth
In-Reply-To: <5a628eb7dc7c4773fbc9478499fde70b.squirrel@www.codeaurora.org>
Hi Tim,
> QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora Forum)
> is planning an implementation of AMP for BlueZ. Here are some details of
> our technical approach. We are interested in comments from the BlueZ
> development community on validity and whether there are areas we have
> missed.
>
> Features:
> - Completion of L2CAP with ERTM
>
> - Addition of L2CAP Channel Management and AMP Manager
>
> - DBUS support to access AMP features, control AMP settings, etc.
>
> - Updates to Test Programs (hcidump, hciemu, l2test, ...)
>
> - Creation of a Fake PAL to facilitate desktop development using wired TCP
>
> - Legacy L2CAP sockets take advantage of AMP, if so enabled using new
> controls (sockopts or DBUS)
>
> - Key Management extended for AMP Controller Keys
>
>
> L2CAP and ERTM
> --------------
>
> A prerequisite for AMP support is a fully functional L2CAP ERTM
> implementation, including optional L2CAP features not currently included
> in BlueZ.
>
> Our overall approach is to build on the existing ERTM code in the
> bluetooth-testing tree, extending the present socket interfaces that are
> visible to userspace. The extensions we foresee are sockopt configuration
> of MPS (max PDU size), TX window size (currently hard coded), and a simple
> AMP control policy ("BR/EDR only", "initiate on or move to AMP", or
> "initiate on or move to BR/EDR, allow incoming move").
I was under the impression it is best to match the MPS with the ACL MTU
from the controller? So do we need really an option less. Less options
are less confusing for users.
> There are a few protocol-level enhancements required. One is to support
> L2CAP lockstep configuration, in addition to the present standard
> configuration process. Another addition is support for the extended TX
> window option.
>
> Core ERTM functionality (without the proposed additional features) is
> still a work in progress, and the main area that needs attention is the
> implementation of the transmitter (XMIT and WAIT_F) and receiver (RECV and
> SREJ_SENT) state tables as defined in the ERTM spec.
>
>
> L2CAP and Channel Management for AMP
> ------------------------------------
>
> Once ERTM is working without AMP, the state machine will have to be
> extended to account for the extra demands of creating channels directly on
> an AMP controller and AMP channel moves. L2CAP will have to deal with two
> controllers (BR/EDR and AMP) while the channel move is taking place, and
> correctly handle lockstep reconfiguration of the L2CAP channel when the
> move is completing.
>
> To enable AMP, L2CAP itself will need to be enhanced to support the A2MP
> fixed channel and to use the AMP Manager to create/disconnect physical and
> logical links on an AMP controller. Additionally L2CAP will need to
> manage channels according to the new AMP control, moving them as
> appropriate and handling remote move requests.
>
> The AMP Manager function will need to be created. It will support
> signaling on the A2MP channel and the create/disconnect of AMP physical
> and logical links.
>
> HCI will need to be extended to support data-block-based flow control. AMP
> Controllers will be presented to BlueZ as HCI devices of a new type.
The block-based flow control is a missing piece, but the AMP type
extension has been merged upstream. We can create HCI_BREDR and
HCI_80211 controllers now. The AMP controllers are for now forced to be
raw devices, but that can be changed easily once we have the controller
init for AMP up and ready.
> DBUS Additions (bluetoothd)
> ---------------------------
>
> org.bluez.Adapter : A new property is added, containing a list of the
> associated org.bluez.AmpAdapter objects ("/org/bluez/amp{0, 1, 2, ...}").
> Associating a given AmpAdapter to a parent BR/EDR device
> ("/org/bluez/hci{n}") is one method of org.bluez.AmpAdapter . AmpAdapter
> has other methods to obtain the local controller's type and status, and
> the number of physical links it carries, and to mark whether it is
> available for use by the Amp Manager.
>
> org.bluez.Device : A new method begins the AMP Discovery procedure for
> that Device; an alternative would be to add the procedure to what
> DiscoverServices() does. A new property contains the cached remote AMP
> Device list.
I have to reject this. I don't seen any need to expose this. We could
just do this all internally inside the kernel. The AMP policy should
trigger these automatically and if AMP usage is allowed, we just pick
the right AMP. Involving the user in AMP discovery makes no sense and
complicates the user cases.
Regards
Marcel
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Marcel Holtmann @ 2010-03-05 1:42 UTC (permalink / raw)
To: pacho; +Cc: linux-bluetooth
In-Reply-To: <1267691859.10782.14.camel@localhost.localdomain>
Hi Pacho,
> bluez installs stuff into /etc/alsa and it seems wrong since default
> location for alsa stuff seems to be /usr/share/alsa instead. You can
> also see that this is been workarounded in ubuntu, gentoo (and probably
> debian also).
>
> Any reason why using /etc/alsa instead?
I thought that is the default location. If that is wrong, then please
quote the ALSA documentation and send a patch to fix it.
Regards
Marcel
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Pacho Ramos @ 2010-03-05 9:11 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1267753367.29510.26.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
El jue, 04-03-2010 a las 17:42 -0800, Marcel Holtmann escribió:
> Hi Pacho,
>
> > bluez installs stuff into /etc/alsa and it seems wrong since default
> > location for alsa stuff seems to be /usr/share/alsa instead. You can
> > also see that this is been workarounded in ubuntu, gentoo (and probably
> > debian also).
> >
> > Any reason why using /etc/alsa instead?
>
> I thought that is the default location. If that is wrong, then please
> quote the ALSA documentation and send a patch to fix it.
>
> Regards
>
> Marcel
alsa-lib configure.in seems to indicate that /usr/share/alsa is the
default one:
dnl ALSA configuration directory
AC_ARG_WITH(configdir,
AS_HELP_STRING([--with-configdir=dir],
[path where ALSA config files are stored]),
confdir="$withval", confdir="")
if test -z "$confdir"; then
eval dir="$datadir"
case "$dir" in
/*) ;;
*) dir="$prefix/share"
esac
confdir="$dir/alsa"
fi
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Pacho Ramos @ 2010-03-05 9:24 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1267780295.6970.5.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1135 bytes --]
El vie, 05-03-2010 a las 10:11 +0100, Pacho Ramos escribió:
> El jue, 04-03-2010 a las 17:42 -0800, Marcel Holtmann escribió:
> > Hi Pacho,
> >
> > > bluez installs stuff into /etc/alsa and it seems wrong since default
> > > location for alsa stuff seems to be /usr/share/alsa instead. You can
> > > also see that this is been workarounded in ubuntu, gentoo (and probably
> > > debian also).
> > >
> > > Any reason why using /etc/alsa instead?
> >
> > I thought that is the default location. If that is wrong, then please
> > quote the ALSA documentation and send a patch to fix it.
> >
> > Regards
> >
> > Marcel
>
> alsa-lib configure.in seems to indicate that /usr/share/alsa is the
> default one:
> dnl ALSA configuration directory
> AC_ARG_WITH(configdir,
> AS_HELP_STRING([--with-configdir=dir],
> [path where ALSA config files are stored]),
> confdir="$withval", confdir="")
> if test -z "$confdir"; then
> eval dir="$datadir"
> case "$dir" in
> /*) ;;
> *) dir="$prefix/share"
> esac
> confdir="$dir/alsa"
> fi
>
I forgot the patch, sorry
[-- Attachment #1.2: bluez-4.61-alsa.patch --]
[-- Type: text/x-patch, Size: 330 bytes --]
--- Makefile.am~ 2010-02-12 20:26:48.000000000 +0100
+++ Makefile.am 2010-03-05 10:17:15.000000000 +0100
@@ -241,7 +241,7 @@
audio_libasound_module_ctl_bluetooth_la_CFLAGS = @ALSA_CFLAGS@
if CONFIGFILES
-alsaconfdir = $(sysconfdir)/alsa
+alsaconfdir = $(datadir)/alsa
alsaconf_DATA = audio/bluetooth.conf
endif
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Bluetooth SPP on Nokia N900 (Maemo 5)
From: Henry Owens @ 2010-03-05 10:52 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: linux-bluetooth
In-Reply-To: <2a9506371003020914q3786eb70k57f5b1adda62c05@mail.gmail.com>
Vinicius,
Many thanks for your help - I used the example script, and it is now
connecting correctly to my device.
I am having a slight issue, however, with the fact that the
"SetSerialParameters" method is experimental, and thus I can not use
it - could anyone point me to where I can set the parameters correctly
so that it can receive packets from the device?
FYI, the device is simplex - it sends a packet once per second, and
ignores any commands, so I simply want to receive the packets and
parse them.
At present, when I use the code below, I do not get any output, which
I assume is because my serial settings are incorrect.
Many thanks again for your help,
Henry.
test.py:
import sys
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object("org.bluez", "/"),
"org.bluez.Manager")
adapter = dbus.Interface(bus.get_object("org.bluez", manager.DefaultAdapter()),
"org.bluez.Adapter")
address = "00:07:80:88:F4:E9"
service = "spp"
path = adapter.FindDevice(address)
serial = dbus.Interface(bus.get_object("org.bluez", path),
"org.bluez.Serial")
node = serial.Connect(service)
print "Connected %s to %s" % (node, address)
print "Press CTRL-C to disconnect"
a = open("/dev/rfcomm0","r")
w = a.readline()
print w
serial.Disconnect(node)
On Tue, Mar 2, 2010 at 5:14 PM, Vinicius Gomes
<vinicius.gomes@openbossa.org> wrote:
> Hi Henry,
>
> On Tue, Mar 2, 2010 at 1:26 PM, Henry Owens <owens.henry@googlemail.com> wrote:
>> Hi All,
>>
>> My first mail to this list. I am currently trying to get a bluetooth
>> SPP connection going on my Nokia N900, but I'm having some
>> difficulties using the examples on the HOWTO Wiki.
>>
>> Specifically, I get an error related to the ActivateService call in
>> the example - I have seen reference to this being obselete in Bluez
>> 4.x, is this the problem in the example code?
>>
>
> Yeah, the example code in the wiki is outdated, take a look at the
> example in the sources [1],
> for a working one.
>
> Also, in that same directory there are a few more examples that could be useful.
>
>
> Cheers,
> --
> Vinicius Gomes
> INdT - Instituto Nokia de Tecnologia
>
> [1] http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=test/test-serial;hb=HEAD
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] Allow disable park state in main.conf
From: Liang Bao @ 2010-03-05 12:23 UTC (permalink / raw)
To: Johan Hedberg, marcel; +Cc: linux-bluetooth
In-Reply-To: <4b87e4aa.1408c00a.502e.056f@mx.google.com>
We've changed to a hex value as "DefaultLinkPolicy" as following:
diff --git a/src/main.conf b/src/main.conf
index b03e169..196d703 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -50,3 +50,10 @@ ReverseServiceDiscovery = true
# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
NameResolving = true
+
+# The link policy for connections. By default it's set to 0x000f which is
+# a bitwise OR of role switch(0x0001), hold mode(0x0002), sniff mode(0x0004)
+# and park state(0x0008) are all enabled. However, some devices have
+# connection stability issue or fail to setup SCO when the link is in park
+# state, which requires park state bit cleared.
+DefaultLinkPolicy = 0x000f
Does this look better? If yes I can re-generate a patch and send in a
separate thread.
^ permalink raw reply related
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: Luiz Augusto von Dentz @ 2010-03-05 12:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: tmonahan, linux-bluetooth
In-Reply-To: <1267753300.29510.25.camel@localhost.localdomain>
Hi,
On Fri, Mar 5, 2010 at 3:41 AM, Marcel Holtmann <marcel@holtmann.org> wrote=
:
> Hi Tim,
>
>> QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora Foru=
m)
>> is planning an implementation of AMP for BlueZ. =A0Here are some details=
of
>> our technical approach. =A0We are interested in comments from the BlueZ
>> development community on validity and whether there are areas we have
>> missed.
>>
>> Features:
>> - Completion of L2CAP with ERTM
>>
>> - Addition of L2CAP Channel Management and AMP Manager
>>
>> - DBUS support to access AMP features, control AMP settings, etc.
>>
>> - Updates to Test Programs (hcidump, hciemu, l2test, ...)
>>
>> - Creation of a Fake PAL to facilitate desktop development using wired T=
CP
>>
>> - Legacy L2CAP sockets take advantage of AMP, if so enabled using new
>> controls (sockopts or DBUS)
>>
>> - Key Management extended for AMP Controller Keys
>>
>>
>> L2CAP and ERTM
>> --------------
>>
>> A prerequisite for AMP support is a fully functional L2CAP ERTM
>> implementation, including optional L2CAP features not currently included
>> in BlueZ.
>>
>> Our overall approach is to build on the existing ERTM code in the
>> bluetooth-testing tree, extending the present socket interfaces that are
>> visible to userspace. =A0The extensions we foresee are sockopt configura=
tion
>> of MPS (max PDU size), TX window size (currently hard coded), and a simp=
le
>> AMP control policy ("BR/EDR only", "initiate on or move to AMP", or
>> "initiate on or move to BR/EDR, allow incoming move").
>
> I was under the impression it is best to match the MPS with the ACL MTU
> from the controller? So do we need really an option less. Less options
> are less confusing for users.
>
>> There are a few protocol-level enhancements required. =A0One is to suppo=
rt
>> L2CAP lockstep configuration, in addition to the present standard
>> configuration process. =A0Another addition is support for the extended T=
X
>> window option.
>>
>> Core ERTM functionality (without the proposed additional features) is
>> still a work in progress, and the main area that needs attention is the
>> implementation of the transmitter (XMIT and WAIT_F) and receiver (RECV a=
nd
>> SREJ_SENT) state tables as defined in the ERTM spec.
>>
>>
>> L2CAP and Channel Management for AMP
>> ------------------------------------
>>
>> Once ERTM is working without AMP, the state machine will have to be
>> extended to account for the extra demands of creating channels directly =
on
>> an AMP controller and AMP channel moves. =A0L2CAP will have to deal with=
two
>> controllers (BR/EDR and AMP) while the channel move is taking place, and
>> correctly handle lockstep reconfiguration of the L2CAP channel when the
>> move is completing.
>>
>> To enable AMP, L2CAP itself will need to be enhanced to support the A2MP
>> fixed channel and to use the AMP Manager to create/disconnect physical a=
nd
>> logical links on an AMP controller. =A0Additionally L2CAP will need to
>> manage channels according to the new AMP control, moving them as
>> appropriate and handling remote move requests.
>>
>> The AMP Manager function will need to be created. It will support
>> signaling on the A2MP channel and the create/disconnect of AMP physical
>> and logical links.
>>
>> HCI will need to be extended to support data-block-based flow control. A=
MP
>> Controllers will be presented to BlueZ as HCI devices of a new type.
>
> The block-based flow control is a missing piece, but the AMP type
> extension has been merged upstream. We can create HCI_BREDR and
> HCI_80211 controllers now. The AMP controllers are for now forced to be
> raw devices, but that can be changed easily once we have the controller
> init for AMP up and ready.
>
>> DBUS Additions (bluetoothd)
>> ---------------------------
>>
>> org.bluez.Adapter : A new property is added, containing a list of the
>> associated org.bluez.AmpAdapter objects ("/org/bluez/amp{0, 1, 2, ...}")=
.
>> Associating a given AmpAdapter to a parent BR/EDR device
>> ("/org/bluez/hci{n}") is one method of org.bluez.AmpAdapter . AmpAdapter
>> has other methods to obtain the local controller's type and status, and
>> the number of physical links it carries, and to mark whether it is
>> available for use by the Amp Manager.
>>
>> org.bluez.Device : A new method begins the AMP Discovery procedure for
>> that Device; an alternative would be to add the procedure to what
>> DiscoverServices() does. A new property contains the cached remote AMP
>> Device list.
>
> I have to reject this. I don't seen any need to expose this. We could
> just do this all internally inside the kernel. The AMP policy should
> trigger these automatically and if AMP usage is allowed, we just pick
> the right AMP. Involving the user in AMP discovery makes no sense and
> complicates the user cases.
I have to agree with Marcel on this, we probably don't really need any
AMP adapter exposed in BlueZ, perhaps we can have a property in the
adapter saying if the adapter has AMP capability or not, but even
that I guess is too soon to evaluate so lets first concentrate in
kernel only leaving DBus for latter.
--=20
Luiz Augusto von Dentz
Computer Engineer
^ 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