diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/include/net/bluetooth/hci_core.h linux-2.6.26+mh3+fch/include/net/bluetooth/hci_core.h
--- linux-2.6.26/include/net/bluetooth/hci_core.h 2008-09-01 17:06:22.000000000 +0200
+++ linux-2.6.26+mh3+fch/include/net/bluetooth/hci_core.h 2008-09-01 12:22:36.000000000 +0200
@@ -170,6 +170,7 @@
__u32 link_mode;
__u8 auth_type;
__u8 power_save;
+ __u8 force_active_mode;
unsigned long pend;
unsigned int sent;
diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/include/net/bluetooth/l2cap.h linux-2.6.26+mh3+fch/include/net/bluetooth/l2cap.h
--- linux-2.6.26/include/net/bluetooth/l2cap.h 2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.26+mh3+fch/include/net/bluetooth/l2cap.h 2008-09-01 16:20:17.000000000 +0200
@@ -62,6 +62,8 @@
#define L2CAP_LM_RELIABLE 0x0010
#define L2CAP_LM_SECURE 0x0020
+#define L2CAP_FORCE_ACTIVE_MODE 0x04
+
/* L2CAP command codes */
#define L2CAP_COMMAND_REJ 0x01
#define L2CAP_CONN_REQ 0x02
Seulement dans linux-2.6.26+mh3+fch/kernel: bounds.s
Seulement dans linux-2.6.26+mh3+fch/kernel: timeconst.h
Seulement dans linux-2.6.26+mh3+fch/lib: crc32table.h
Seulement dans linux-2.6.26+mh3+fch/lib: gen_crc32table
Seulement dans linux-2.6.26+mh3+fch/: Module.symvers
diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/net/bluetooth/hci_conn.c linux-2.6.26+mh3+fch/net/bluetooth/hci_conn.c
--- linux-2.6.26/net/bluetooth/hci_conn.c 2008-09-01 17:06:22.000000000 +0200
+++ linux-2.6.26+mh3+fch/net/bluetooth/hci_conn.c 2008-09-01 16:16:33.000000000 +0200
@@ -214,6 +214,7 @@
conn->state = BT_OPEN;
conn->power_save = 1;
+ conn->force_active_mode = 0;
switch (type) {
case ACL_LINK:
@@ -464,7 +465,10 @@
if (test_bit(HCI_RAW, &hdev->flags))
return;
- if (conn->mode != HCI_CM_SNIFF || !conn->power_save)
+ if (conn->mode != HCI_CM_SNIFF)
+ goto timer;
+
+ if (!conn->power_save && !conn->force_active_mode)
goto timer;
if (!test_and_set_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend)) {
diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/net/bluetooth/l2cap.c linux-2.6.26+mh3+fch/net/bluetooth/l2cap.c
--- linux-2.6.26/net/bluetooth/l2cap.c 2008-09-01 17:06:22.000000000 +0200
+++ linux-2.6.26+mh3+fch/net/bluetooth/l2cap.c 2008-09-01 17:18:23.000000000 +0200
@@ -1133,6 +1133,20 @@
l2cap_pi(sk)->link_mode = opt;
break;
+ case L2CAP_FORCE_ACTIVE_MODE:
+ if (sk->sk_state != BT_CONNECTED) {
+ err = -ENOTCONN;
+ break;
+ }
+
+ if (get_user(opt, (u32 __user *) optval)) {
+ err = -EFAULT;
+ break;
+ }
+
+ l2cap_pi(sk)->conn->hcon->force_active_mode = opt;
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -1189,6 +1203,17 @@
break;
+ case L2CAP_FORCE_ACTIVE_MODE:
+ if (sk->sk_state != BT_CONNECTED) {
+ err = -ENOTCONN;
+ break;
+ }
+
+ if (put_user(l2cap_pi(sk)->conn->hcon->force_active_mode,
+ (u32 __user *) optval))
+ err = -EFAULT;
+ break;
+
default:
err = -ENOPROTOOPT;
break;
Hi Marcel,
>>>> Here are patches against 2.6.27-rc6 and latest bluez git that add
>>>> support for point 1 below.
>>> problem with these patches is that they are a layer violation between
>>> L2CAP and HCI.
>> Yes that is true but that is nothing that isn't already existing. Same
>> trick is used for L2CAP_CONNINFO.
>
> no they don't. Look at the code. It is nicely abstracted on how we
> handle the two layers.
Having a closer look to the code, it looks that only write access to HCI
layer variables is forbidden. There are numerous places in the code
where L2CAP for instance goes and peeks some HCI values. I think i
skipped that distinction in my first understanding of the code.
Anyway, i'm gonna stop chatting and starting to fix that too :-).
>
>>> It should also work on incoming and outgoing connections
>>> the same way.
>> I'm not following you there...
>
> We wanna be able to set this on a server socket and also enforce it on a
> connection we created.
>
>>> Also when using socket options, I prefer that we set them
>>> and store the value and the execute it once the connections is up.
>> Agreed. I was just too lazy to do that :-)
>
> Lazy doesn't get it upstream :)
lol :-)
>
>>> Personally I prefer if we would enhance hci_send_acl() to indicate that
>>> we expect it got get out of any power state before processing this data
>>> packet.
>>>
That sounds reasonable...
>>> And of course this socket option also has to work for RFCOMM.
>> That's pretty much useless as i don't know if that will ever get used.
>> However that's not much work, i can do it if that makes you happy. ;-)
>
> I treat RFCOMM and L2CAP the same. If we implement something for one
> protocol, we do have to do the same for the other.
>
>> Do you have any comments on the user-land side or is it how you see things ?
>
> Actually I do have to figure out the exact naming, but it is basically
> set this option once approach. And the kernel will do the rest.
>
Agreed.
So i'm gonna start coding now to see of things are going...
Cheers,
Fabien
Hi Fabien,
> >> Here are patches against 2.6.27-rc6 and latest bluez git that add
> >> support for point 1 below.
> >
> > problem with these patches is that they are a layer violation between
> > L2CAP and HCI.
>
> Yes that is true but that is nothing that isn't already existing. Same
> trick is used for L2CAP_CONNINFO.
no they don't. Look at the code. It is nicely abstracted on how we
handle the two layers.
> > It should also work on incoming and outgoing connections
> > the same way.
>
> I'm not following you there...
We wanna be able to set this on a server socket and also enforce it on a
connection we created.
> > Also when using socket options, I prefer that we set them
> > and store the value and the execute it once the connections is up.
>
> Agreed. I was just too lazy to do that :-)
Lazy doesn't get it upstream :)
> > Personally I prefer if we would enhance hci_send_acl() to indicate that
> > we expect it got get out of any power state before processing this data
> > packet.
> >
> > And of course this socket option also has to work for RFCOMM.
>
> That's pretty much useless as i don't know if that will ever get used.
> However that's not much work, i can do it if that makes you happy. ;-)
I treat RFCOMM and L2CAP the same. If we implement something for one
protocol, we do have to do the same for the other.
> Do you have any comments on the user-land side or is it how you see things ?
Actually I do have to figure out the exact naming, but it is basically
set this option once approach. And the kernel will do the rest.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi Fabien,
>
>> Here are patches against 2.6.27-rc6 and latest bluez git that add
>> support for point 1 below.
>
> problem with these patches is that they are a layer violation between
> L2CAP and HCI.
Yes that is true but that is nothing that isn't already existing. Same
trick is used for L2CAP_CONNINFO.
I'm gonna try to improve that.
> It should also work on incoming and outgoing connections
> the same way.
I'm not following you there...
> Also when using socket options, I prefer that we set them
> and store the value and the execute it once the connections is up.
Agreed. I was just too lazy to do that :-)
>
> Personally I prefer if we would enhance hci_send_acl() to indicate that
> we expect it got get out of any power state before processing this data
> packet.
>
> And of course this socket option also has to work for RFCOMM.
That's pretty much useless as i don't know if that will ever get used.
However that's not much work, i can do it if that makes you happy. ;-)
Do you have any comments on the user-land side or is it how you see things ?
Cheers,
Fabien
Hi Fabien,
> Here are patches against 2.6.27-rc6 and latest bluez git that add
> support for point 1 below.
problem with these patches is that they are a layer violation between
L2CAP and HCI. It should also work on incoming and outgoing connections
the same way. Also when using socket options, I prefer that we set them
and store the value and the execute it once the connections is up.
Personally I prefer if we would enhance hci_send_acl() to indicate that
we expect it got get out of any power state before processing this data
packet.
And of course this socket option also has to work for RFCOMM.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Here are patches against 2.6.27-rc6 and latest bluez git that add
support for point 1 below.
Please tell me how you feel about them...
Cheers,
Fabien
>
> Also this is not BlueZ screwing anything up. Where is written that we
> have to get out of sniff mode before we can disconnect a link. What kind
> of hardware are you using? Does BlueZ always have to cleanup after
> broken hardware and f*cked up stacks?
>
>> Conclusion: to have those bloody Sony Erisson headsets working we have
>> to change two things in the kernel:
>> 1) Provide a way for a L2CAP socket user to alter sniff mode exit
>> behaviour
>> 2) Make sure we exit sniff mode before to disconnect
>>
>> Question 1: Are you interested in reviewing then merging my patches if i
>> try to fix thoses issues ?
>> Question 2: I have the gut feeling that we should change default
>> behaviour to the behaviour required by those headsets, and provide a
>> socket option for the bluetooth HID, rather than the other way round.
>> What do you think ?
>>
>> If we can come on an agreement on the proper way to fix this issue then
>> i should come with a patch in a 3-4 days timeframe.
>
> Make it two separate patches. We can send the exit sniff mode command
> that is not a problem. I still don't like it, because it is the job of
> the Link Manager to do this.
>
> For the sniff mode setting you have to use SOL_BLUETOOTH since I will
> remove all the other SOL_* and consolidate them.
>
> Regards
>
> Marcel
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
Hi Brian,
This headset is supposed to work, the issue is that sometimes it can be
very slow to connect...
Cheers,
Fabien
Brian Sammon wrote:
> No wonder I couldn't get my HBH-DS980 to work!
>
> This kind of information belongs on the wiki.
> I've created http://wiki.bluez.org/wiki/HardwareCompatibility
> and http://wiki.bluez.org/wiki/MotorolaHBHDS9x0 as a start, but I don't really
> understand the issue, so it would be good if someone who understands it better
> could flesh out the wiki article.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
No wonder I couldn't get my HBH-DS980 to work!
This kind of information belongs on the wiki.
I've created http://wiki.bluez.org/wiki/HardwareCompatibility
and http://wiki.bluez.org/wiki/MotorolaHBHDS9x0 as a start, but I don't really
understand the issue, so it would be good if someone who understands it better
could flesh out the wiki article.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel
>
>>>> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
>>>> the kernel version that counts.
>>> I'm gonna rebase on this one then.
>> The issue with sniff mode & disconnect has vanished with 2.6.27-rc5 :-)
>
> are you sure? I am not recalling that I fixed anything in this area. The
> ACL link setup has changed to do proper features retrieval before
> allowing L2CAP do get into it. However it cools down the phase for the
> first L2CAP package.
See previous e-mail, i screwed up, issue seems to come from ST chip. :-(
>
> Btw. report this bug to your hardware manufacturer, because they are not
> working according to the HCI specification. It is a bug if disconnect
> fails when they are in sniff mode.
>
Yep, i would definately report this... however don't have any support
anymore from ST :-(
Fabien
Hi Marcel
>> I never said that Bluez was screwing up anything.
>> But as usual, there are compromises to make between sticking close to
>> the standard and having good interoperability, which usually involves
>> some level of workaround :-)
>
> I am seriously sick of this f*cked up hardware. What is it? My guess
> would be a TI chip.
...and you won !!
>
>>> Make it two separate patches. We can send the exit sniff mode command
>>> that is not a problem. I still don't like it, because it is the job of
>>> the Link Manager to do this.
>> Will do.
>>
>> You didn't answer to question 2: what's your choice ? (btw to question 1
>> neither, but i guess that means a 'yes' :-)
>
> I would first have to know which host controller it is, before I
> actually think about adding something like this.
I dug deeper in this second problem.
In fact it has not been solved by the 2.6.17-rc5 kernel.
I misinterpreted the result as i inadvertedly changed bluetooth dongle
at the same time.
So issue with wrong pin code only arise whith Sony Erisson(TI) + ST + bluez.
Sony Erisson(TI) + BCM + bluez works.
As you said issue is clearly seems to come from the hardware (LMP).
>
>>> For the sniff mode setting you have to use SOL_BLUETOOTH since I will
>>> remove all the other SOL_* and consolidate them.
>> hmmm... not sure i really see what you mean. :-(
>
> Don't use SOL_L2CAP or SOL_RFCOMM anymore. They will be all
> SOL_BLUETOOTH since there are no different between the socket options
> itself.
Yeah sure but from the kernel point of view there is a a level parameter
passed to setsockopt/getsockopt which is already ignored... or maybe you
were just speeking about user space ?
Regards,
Fabien
Hi Fabien,
> >> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
> >> the kernel version that counts.
> >
> > I'm gonna rebase on this one then.
>
> The issue with sniff mode & disconnect has vanished with 2.6.27-rc5 :-)
are you sure? I am not recalling that I fixed anything in this area. The
ACL link setup has changed to do proper features retrieval before
allowing L2CAP do get into it. However it cools down the phase for the
first L2CAP package.
Btw. report this bug to your hardware manufacturer, because they are not
working according to the HCI specification. It is a bug if disconnect
fails when they are in sniff mode.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
> > Also this is not BlueZ screwing anything up. Where is written that we
> > have to get out of sniff mode before we can disconnect a link. What kind
> > of hardware are you using? Does BlueZ always have to cleanup after
> > broken hardware and f*cked up stacks?
>
> Lol :-)
> I never said that Bluez was screwing up anything.
> But as usual, there are compromises to make between sticking close to
> the standard and having good interoperability, which usually involves
> some level of workaround :-)
I am seriously sick of this f*cked up hardware. What is it? My guess
would be a TI chip.
> > Make it two separate patches. We can send the exit sniff mode command
> > that is not a problem. I still don't like it, because it is the job of
> > the Link Manager to do this.
>
> Will do.
>
> You didn't answer to question 2: what's your choice ? (btw to question 1
> neither, but i guess that means a 'yes' :-)
I would first have to know which host controller it is, before I
actually think about adding something like this.
> > For the sniff mode setting you have to use SOL_BLUETOOTH since I will
> > remove all the other SOL_* and consolidate them.
>
> hmmm... not sure i really see what you mean. :-(
Don't use SOL_L2CAP or SOL_RFCOMM anymore. They will be all
SOL_BLUETOOTH since there are no different between the socket options
itself.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> Hi Marcel,
>
>> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
>> the kernel version that counts.
>
> I'm gonna rebase on this one then.
The issue with sniff mode & disconnect has vanished with 2.6.27-rc5 :-)
It just remains one issue to be fixed then...
Fabien
Hi Marcel,
>
> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
> the kernel version that counts.
I'm gonna rebase on this one then.
>
> Also this is not BlueZ screwing anything up. Where is written that we
> have to get out of sniff mode before we can disconnect a link. What kind
> of hardware are you using? Does BlueZ always have to cleanup after
> broken hardware and f*cked up stacks?
Lol :-)
I never said that Bluez was screwing up anything.
But as usual, there are compromises to make between sticking close to
the standard and having good interoperability, which usually involves
some level of workaround :-)
>
>> Conclusion: to have those bloody Sony Erisson headsets working we have
>> to change two things in the kernel:
>> 1) Provide a way for a L2CAP socket user to alter sniff mode exit
>> behaviour
>> 2) Make sure we exit sniff mode before to disconnect
>>
>> Question 1: Are you interested in reviewing then merging my patches if i
>> try to fix thoses issues ?
>> Question 2: I have the gut feeling that we should change default
>> behaviour to the behaviour required by those headsets, and provide a
>> socket option for the bluetooth HID, rather than the other way round.
>> What do you think ?
>>
>> If we can come on an agreement on the proper way to fix this issue then
>> i should come with a patch in a 3-4 days timeframe.
>
> Make it two separate patches. We can send the exit sniff mode command
> that is not a problem. I still don't like it, because it is the job of
> the Link Manager to do this.
Will do.
You didn't answer to question 2: what's your choice ? (btw to question 1
neither, but i guess that means a 'yes' :-)
>
> For the sniff mode setting you have to use SOL_BLUETOOTH since I will
> remove all the other SOL_* and consolidate them.
hmmm... not sure i really see what you mean. :-(
Fabien
Hi Fabien,
> Due to job requirement, I recently fined tuned a kernel to work well
> with some Sony Erisson A2DP Headsets (namely Motorola HBH-DS970 and
> HBH-DS980): this means making sure to force the other side to exit sniff
> mode early on before the AVDTP signalling comes into play.
>
> If i remember well we had a talk a while ago about the way the sniff
> mode was handled by the kernel due to various issues with some bluetooth
> keyboards. The conclusion we had at that time, the best way to handle
> this issue was to add a socket option on an L2CAP channel to force the
> other side to exit sniff mode even if it was the one who initially
> entered the sniff mode.
>
> I used this approach and wrote & tested a patch against 2.6.26-mh3.
> Patch is attached and seems to solve the issue.
>
> *but*
>
> During validation testing we found yet another issue that seems to be
> related to the way we handle the sniff mode.
> The syndrom is that if the user screws up at enterring the pin code
> during pairing bluez fails to close the acl connection properly,
> which means subsequent attempts result in a "connection already exist"
> error. From the user point of view it is impossible to try to pair again
> to the same headset...which is quite annoying.
retest with 2.6.27-rc5 since that has full Simple Pairing support and is
the kernel version that counts.
Also this is not BlueZ screwing anything up. Where is written that we
have to get out of sniff mode before we can disconnect a link. What kind
of hardware are you using? Does BlueZ always have to cleanup after
broken hardware and f*cked up stacks?
> Conclusion: to have those bloody Sony Erisson headsets working we have
> to change two things in the kernel:
> 1) Provide a way for a L2CAP socket user to alter sniff mode exit
> behaviour
> 2) Make sure we exit sniff mode before to disconnect
>
> Question 1: Are you interested in reviewing then merging my patches if i
> try to fix thoses issues ?
> Question 2: I have the gut feeling that we should change default
> behaviour to the behaviour required by those headsets, and provide a
> socket option for the bluetooth HID, rather than the other way round.
> What do you think ?
>
> If we can come on an agreement on the proper way to fix this issue then
> i should come with a patch in a 3-4 days timeframe.
Make it two separate patches. We can send the exit sniff mode command
that is not a problem. I still don't like it, because it is the job of
the Link Manager to do this.
For the sniff mode setting you have to use SOL_BLUETOOTH since I will
remove all the other SOL_* and consolidate them.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel