Thread (8 messages) flat view 8 messages, 4 authors, 2009-09-22

Re: can we disable/enable eSCO by using setsockopt of sco socket?

From: Marcel Holtmann <marcel@holtmann.org>
Date: 2009-09-14 13:32:34

Hi,
quoted hunk ↗ jump to hunk
When we connect a SCO socket, BlueZ decides whether to connect SCO or
eSCO type according to the remote feature. If the remote device
declares supporting eSCO in the remote feature, BlueZ will select eSCO
type to connect with it.

But in fact  there are some old carkits or headsets which are only
support SCO but wrongly declare to support eSCO, such as Motorola
HF850 and HS820 which use a very old CSR chip, so we have problem to
create sco connection with them.

We thought a method to resolve this issue, which is force to create
SCO type connection if we find the HFP version of one remote device is
less than 1.2. So we need a method to control the SCO type from user
space. We want to use setsockopt() functon to do that. The code change
in net/bluetooth/sco.c is like below,

@@ -653,12 +653,25 @@ static int sco_sock_setsockopt(struct socket *sock, int le
 {
       struct sock *sk = sock->sk;
       int err = 0;
+       u32 opt;

       BT_DBG("sk %p", sk);

       lock_sock(sk);

+       if (level != SOL_SCO) {
+               err = -ENOPROTOOPT;
+               return err;
+       }
+
       switch (optname) {
+       case BT_DISABLE_ESCO:
+               if (get_user(opt, (u32 __user *) optval)) {
+                       err = -EFAULT;
+                       break;
+               }
+               disable_esco = opt;
+               break;
       default:
               err = -ENOPROTOOPT;
               break;

Then, in the user space, we can call setsockopt(fd, SOL_SCO,
BT_DISABLE_ESCO, &disabled, sizeof(disabled)) to force to connect SCO.

Do you agree with this change?
I don't. You first have to prove to me that this change is needed at
all. Show me the hcidump -X -V connections attempts for these carkits.

Also your analysis is wrong. BlueZ doesn't care if the remote headset
supports eSCO or not. We just care about if our local controller has the
synchronous setup commands. It is the job of the link manager inside the
controller firmware to either establish SCO or eSCO. And we do retry
with SCO if eSCO fails. This sounds more like the case that you have an
outdated kernel.

Regards

Marcel

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help