public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)
@ 2008-07-03  0:37 Malte J. Wetz
  2008-07-04  4:27 ` jayjwa
  0 siblings, 1 reply; 8+ messages in thread
From: Malte J. Wetz @ 2008-07-03  0:37 UTC (permalink / raw)
  To: bluez-users

Am Montag, 30. Juni 2008 schrieb Martin Mueller:
> I have the same dongle and it's incorrctly indentified as "peagsus
> 100Mbit/s Ethernet". Just add the line:
>
> blacklist pegasus

Thanks for that info. It brought me one step closer to getting the stick to =

work. Now, everything appears to work. But the Belkin dongle behaves =

exactly like the MSI dongle: It does not record or playback anything when =

paired with my bluetooth headset (Jabra BT 205).

With my old Logitech MX 900, I used btsco which emulates a soundcard and =

everthing was fine. With the MSI or Belkin dongles, neither btsco nor the =

newer alsa plugin method work.


Ok, first the "deprecated" method with btsco (with correct BT address of =

course):


root@triton:~# btsco -v -r XX:XX:XX:XX:XX:XX
btsco v0.42
Device is 2:0
Voice setting: 0x0060
RFCOMM channel 1 connected
Using interface hci0

Then I start audacity, select =BBALSA: BT Headset: BT SCO PCM (hw:2,0)=AB a=
ls =

input source. I set the project frequency to 8000 Hz and hit the "Record" =

button. I new audio track appears, but the marker indicating the current =

position does not move. It just stays frozen at 0.0 on the timeline.
The btsco-Output is full of connection timeouts:

i/o needed: connecting sco...
Can't connect SCO audio channel
: Connection timed out
speaker volume: 11 mic volume: 14
recieved AT+VGS=3D11
Sending up speaker change 11
speaker volume: 11 mic volume: 14
i/o needed: connecting sco...
Can't connect SCO audio channel
: Connection timed out
speaker volume: 11 mic volume: 14

The syslog says:

Jul  2 15:49:31 triton kernel: hci_scodata_packet: hci0 SCO packet for =

unknown connection handle 1
Jul  2 15:50:01 triton last message repeated 9996 times


Now the "new" method via alsa:

This is my ~/.asoundrc:

pcm.headset { =

        type bluetooth
        device XX:XX:XX:XX:XX:XX
        profile "sco"
} =

 =

ctl.headset { =

        type bluetooth =

} =


I also tried "auto" as profile above, doesn't change anything. Now, I want =

to use mplayer to play back a mp3 file using the headset.

mjw@triton:~$ mplayer -ao 'alsa:device=3Dheadset' test.mp3                 =
       =

MPlayer 1.0rc2-4.2.3 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6400+ (Family: 15, Model: 67, =

Stepping: 3)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote =

control.

Playing test.mp3.
Audio file file format detected.
Clip info:
 Title: =

 Artist: =

 Album: =

 Year: 0
 Comment: =

 Track: =

 Genre: Unknown
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Forced audio codec: mad
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


And there it remains without anything happening. As you might have guessed, =

the syslog looks similar:

Jul  2 15:53:20 triton kernel: hci_scodata_packet: hci0 SCO packet for =

unknown connection handle 1
Jul  2 15:53:40 triton last message repeated 6565 times
Jul  2 15:53:40 triton kernel: hcid[2999]: segfault at 8 ip b7db5e0e sp =

bfae8090 error 6 in libaudio.so[b7dae000+19000]
Jul  2 15:53:40 triton kernel: hci_scodata_packet: hci0 SCO packet for =

unknown connection handle 1


I checked both dongles under Windows XP. The MSI dongle comes with the =

BlueSoleil stack, the Belkin dongle with the Widcomm stack. Both work =

perfectly. So I think there's nothing wrong with the hardware itself.

I googled for the syslog error above and found this patch: =

http://lkml.org/lkml/2008/2/27/105
It does fix the error message itself, but the headset still does not work. =


Last lines of mplayer-Output:

AO: [alsa] 8000Hz 1ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A:   1.0 (01.0) of 293.0 (04:53.0)  0.9%

And there it freezes. This time, syslog says for btsco:

Jul  2 16:10:18 triton kernel: snd-bt-sco revision 1.19 $
Jul  2 16:10:18 triton kernel: snd-bt-sco: snd-bt-scod thread starting
Jul  2 16:10:22 triton hcid[6279]: link_key_request (sba=3DYY:YY:YY:YY:YY:Y=
Y, =

dba=3DXX:XX:XX:XX:XX:XX)
Jul  2 16:10:34 triton hcid[6279]: Audio API: received =

BT_GETCAPABILITIES_REQ
Jul  2 16:10:53 triton hcid[6279]: Audio API: sending BT_GETCAPABILITIES_RSP
Jul  2 16:10:53 triton hcid[6279]: Audio API: received =

BT_SETCONFIGURATION_REQ
Jul  2 16:10:53 triton hcid[6279]: config sco - device =3D XX:XX:XX:XX:XX:X=
X =

access_mode =3D 2
Jul  2 16:11:01 triton ntpd[4908]: synchronized to 192.168.0.1, stratum 2
Jul  2 16:11:01 triton ntpd[4908]: kernel time sync status change 0001
Jul  2 16:11:36 triton kernel: snd-bt-sco: playback_open
Jul  2 16:11:36 triton kernel: snd-bt-sco: prepare ok bps: 16000 size: 3276=
8 =

count: 2048
Jul  2 16:11:36 triton kernel: Bluetooth: SCO (Voice Link) ver 0.5
Jul  2 16:11:36 triton kernel: Bluetooth: SCO socket layer initialized
Jul  2 16:11:36 triton kernel: snd-bt-sco: playback_trigger 1
Jul  2 16:11:36 triton kernel: snd-bt-sco: setting playback to bspcm
Jul  2 16:12:38 triton kernel: snd-bt-sco: playback_trigger 0
Jul  2 16:12:38 triton kernel: snd-bt-sco: setting playback to NULL
Jul  2 16:12:38 triton kernel: snd-bt-sco: Disposing of previous socket =

count 3
Jul  2 16:12:38 triton kernel: snd-bt-sco: file_count is 1 (expected 3)


And for the ALSA plugin:

Jul  2 16:16:02 triton hcid[9056]: Audio API: received =

BT_GETCAPABILITIES_REQ
Jul  2 16:16:02 triton hcid[9056]: Audio API: sending BT_GETCAPABILITIES_RSP
Jul  2 16:16:02 triton hcid[9056]: Audio API: received =

BT_SETCONFIGURATION_REQ
Jul  2 16:16:02 triton hcid[9056]: config sco - device =3D XX:XX:XX:XX:XX:X=
X =

access_mode =3D 2
Jul  2 16:16:05 triton hcid[9056]: link_key_request (sba=3DYY:YY:YY:YY:YY:Y=
Y, =

dba=3DXX:XX:XX:XX:XX:XX)
Jul  2 16:16:08 triton hcid[9056]: SCO fd=3D25
Jul  2 16:16:08 triton hcid[9056]: Audio API: sending =

BT_SETCONFIGURATION_RSP
Jul  2 16:16:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul  2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul  2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
Jul  2 16:17:28 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul  2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul  2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
Jul  2 16:18:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul  2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul  2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
Jul  2 16:18:48 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul  2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul  2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND

Note that in the last section, there are always three messages grouped =

together. Everytime one of these triplets is logged, mplayer advances a =

little bit on the playback (steps: 0.1%, 1.2%, 2.4%, and so on) and then =

blocks again until the next triplet shows up.


I would really like to get at least one method working but I don't even hav=
e =

an error message to feed to google. Any ideas on this one?

-- =

Malte J. Wetz  <mail@malte-wetz.de>
Homepage: www.malte-wetz.de (PGP/GPG Keys available on homepage)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)
  2008-07-03  0:37 [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem) Malte J. Wetz
@ 2008-07-04  4:27 ` jayjwa
  2008-07-04 14:17   ` Michael Domann
  0 siblings, 1 reply; 8+ messages in thread
From: jayjwa @ 2008-07-04  4:27 UTC (permalink / raw)
  To: BlueZ users



On Thu, 3 Jul 2008, Malte J. Wetz wrote:

-> Thanks for that info. It brought me one step closer to getting the stick to 
-> work. Now, everything appears to work. But the Belkin dongle behaves 
-> exactly like the MSI dongle: It does not record or playback anything when 
-> paired with my bluetooth headset (Jabra BT 205).

I think these are older bluetooth hardware that you will need the kernel patch 
for. Mine needs it. Patch kernel & recompile/reinstall modules as it seems 
like you already did below.

-> With my old Logitech MX 900, I used btsco which emulates a soundcard and 
-> everthing was fine. With the MSI or Belkin dongles, neither btsco nor the 
-> newer alsa plugin method work.
-> 
-> 
-> Ok, first the "deprecated" method with btsco (with correct BT address of 
-> course):

This method is old and my not even work anymore with modern bluez, I don't 
know. Try current bluez-utils/libs and current Alsa w/current kernel for best 
results.


-> Jul  2 15:53:20 triton kernel: hci_scodata_packet: hci0 SCO packet for 
-> unknown connection handle 1
-> Jul  2 15:53:40 triton last message repeated 6565 times

This looks like what happens when you don't use the patch when you need it. 
Look at the device and see:

# hcitool info 00:1A:45:01:F9:42

Requesting information ...
         BD Address:  00:1A:45:01:F9:42
         OUI Company: GN Netcom as (00-1A-45)
         LMP Version: 2.0 (0x3) LMP Subversion: 0xbfa
         Manufacturer: Cambridge Silicon Radio (10)
         Features: 0xfc 0xfe 0x0b 0x00 0x08 0x08 0x00 0x00
                 <encryption> <slot offset> <timing accuracy> <role switch>
                 <hold mode> <sniff mode> <RSSI> <channel quality> <SCO link>
                 <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
                 <paging scheme> <transparent SCO> <AFH cap. slave>
                 <AFH cap. master>


When it only says "SCO", you'll need the patch. Never saw an ESCO headset 
because I don't own one, but I'd guess it shows things like <eSCO link>?

-> Jul  2 15:53:40 triton kernel: hcid[2999]: segfault at 8 ip b7db5e0e sp 
-> bfae8090 error 6 in libaudio.so[b7dae000+19000]


That might be the segfault I hit awhile back and posted about. It's the same 
solib, libaudio.so

-> Jul  2 15:53:40 triton kernel: hci_scodata_packet: hci0 SCO packet for 
-> unknown connection handle 1


-> Jul  2 16:16:02 triton hcid[9056]: Audio API: received 
-> BT_GETCAPABILITIES_REQ
-> Jul  2 16:16:02 triton hcid[9056]: Audio API: sending BT_GETCAPABILITIES_RSP
-> Jul  2 16:16:02 triton hcid[9056]: Audio API: received 
-> BT_SETCONFIGURATION_REQ
-> Jul  2 16:16:02 triton hcid[9056]: config sco - device = XX:XX:XX:XX:XX:XX 
-> access_mode = 2
-> Jul  2 16:16:05 triton hcid[9056]: link_key_request (sba=YY:YY:YY:YY:YY:YY, 
-> dba=XX:XX:XX:XX:XX:XX)
-> Jul  2 16:16:08 triton hcid[9056]: SCO fd=25
-> Jul  2 16:16:08 triton hcid[9056]: Audio API: sending 
-> BT_SETCONFIGURATION_RSP
-> Jul  2 16:16:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul  2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul  2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
-> Jul  2 16:17:28 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul  2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul  2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
-> Jul  2 16:18:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul  2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul  2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
-> Jul  2 16:18:48 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul  2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul  2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND


Last things are the SCO MTU...

# hciconfig -a

hci0:   Type: USB
         BD Address: 00:0A:3A:7C:5C:74 ACL MTU: 1017:8 SCO MTU: 64:8
         UP RUNNING PSCAN ISCAN
         RX bytes:4448653 acl:123 sco:87104 events:179 errors:0
         TX bytes:4496843 acl:98 sco:88120 commands:80 errors:0
         Features: 0xff 0xff 0x8d 0xfe 0x9b 0xf9 0x00 0x80
         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
         Link policy: RSWITCH HOLD SNIFF PARK
         Link mode: SLAVE ACCEPT
 	Name: '[vdrl] / BT Device 0'
         Class: 0x1a0108
         Service Classes: Networking, Capturing, Object Transfer
         Device Class: Computer, Server
         HCI Ver: 2.0 (0x3) HCI Rev: 0x4107 LMP Ver: 2.0 (0x3) LMP Subver: 0x430e
         Manufacturer: Broadcom Corporation (15)


If the SCO MTU: 64:8 part has zero's there, it won't work. Mine will do this 
without the hci_usb force sco fix param set:

# modinfo hci_usb

filename:       /lib/modules/2.6.25.9/kernel/drivers/bluetooth/hci_usb.ko.gz
license:        GPL
version:        2.9
description:    Bluetooth HCI USB driver ver 2.9
author:         Maxim Krasnyansky <maxk@qualcomm.com>, Marcel Holtmann 
<marcel@holtmann.org>
srcversion:     DACD9DA7C0F1ECE25CC71EB
alias:          usb:v0C10p0000d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDBp1002d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v044Ep3002d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v044Ep3001d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v04BFp030Ad*dc*dsc*dp*ic*isc*ip*
alias:          usb:v057Cp3800d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v*p*d*dcE0dsc01dp01ic*isc*ip*
depends:        bluetooth
vermagic:       2.6.25.9 mod_unload PENTIUM4
parm:           ignore:Ignore devices from the matching table (bool)
parm:           ignore_dga:Ignore devices with id 08fd:0001 (bool)
parm:           ignore_csr:Ignore devices with id 0a12:0001 (bool)
parm:           ignore_sniffer:Ignore devices with id 0a12:0002 (bool)
parm:           disable_scofix:Disable fixup of wrong SCO buffer size (bool)
parm:           force_scofix:Force fixup of wrong SCO buffers size (bool)
parm:           reset:Send HCI reset command on initialization (bool)
parm:           isoc:Set isochronous transfers for SCO over HCI support (int)


Try one of two things if you have this problem:

1.) have no mention of hci_usb any place in modprobe.conf, then manually 
insert the module (remove first if needed) with the param on:

modprobe -r hci_usb
sleep 1
modprobe hci_usb force_scofix=1

(then start the bluetooth stuff)

2.) put this in modprobe.conf. Mine is at /etc/modprobe.conf

options hci_usb force_scofix=1

...and refresh the modules (depmod -e -F /boot/System.map). It must point to 
the current System.map

Make sure the module is out:

modprobe -r hci_usb

Then start bluetooth stuff as usual and modprobe will handle the param for you 
for now on so you can forget about it after this if you go this route.


Also make sure the right files are installed for alsa-lib to do bluetooth 
(there's a few extra in my setup, like the speex ones):

/usr/lib/alsa-lib:

# ls -1

libasound_module_ctl_bluetooth.so*
libasound_module_ctl_dsp_ctl.so*
libasound_module_ctl_oss.so*
libasound_module_pcm_alsa_dsp.so*
libasound_module_pcm_bluetooth.so*
libasound_module_pcm_oss.so*
libasound_module_pcm_upmix.so*
libasound_module_pcm_vdownmix.so*
libasound_module_rate_speexrate_best.so@
libasound_module_rate_speexrate_medium.so@
libasound_module_rate_speexrate.so*
smixer/

-> I would really like to get at least one method working but I don't even have 
-> an error message to feed to google. Any ideas on this one?
->

>>From the start w/above fixes in mind:

Some headsets like mine won't show themselves unless they are put in visible 
mode. On this one, that is turn it off, then back on, holding the button 
awhile. The light stays lit and you can scan it. If you know its address 
already you don't need to do that.

# hcitool scan

Scanning ...
         00:1A:45:01:F9:42       Jabra BT135


# cat /etc/asound.conf

## Alsa Sound Config
##
## Extra configurations for Alsa
## (/usr/share/alsa/alsa.conf)
##

pcm.oss {
         type oss
         device /dev/dsp
}

pcm.bluetooth {
         type bluetooth
         device "00:1A:45:01:F9:42"
         profile "auto"
}

ctl.bluetooth {
         type bluetooth
         device "00:1A:45:01:F9:42"
}

pcm.bt_slave {
         type plug
         slave {
                 pcm "bluetooth"
         }
}



You don't need the first and last stanzas, they are for other stuff.

/usr/bin/dbus-daemon --system
hcid -s -f /etc/bluetooth/hcid.conf

Some times removing the persistant info in /var/lib/bluetooth/* helps clear up 
odd errors. Your dir may be in another place.

passkey-agent --default 0000 00:1A:45:01:F9:42 & (passkey-agent --default <PIN> <Remote BT address> 
auth-agent &  (or whatever you are using to pair with)


Turn on the headset. Mine looks for the computer and connects to it, not the 
other way around. When nothings being sent it disconnects. You don't have to 
worry about manually connecting it. Pressing the button on the side of it 
makes it do the same. Mine is the same company as yours, similar model so they 
might work similarly.

If you built your kernel with auto kmod load you don't need to worry about 
loading modules outside of the hci_usb thing above because of the special 
parameter.

Send some sound. Not all players I've tried work, but I know sox does. And the 
standard Alsa stuff.

sox -t ogg ./sound_file.ogg -t alsa pcm.bluetooth  <-- Name in asound.conf


That should be it. Recording I've done w/sox the same way, just opposite 
direction. You may see a few errors in syslog but it should work.

linux-2.6.25.9
alsa-*-1.0.16
bluez-utils-3.34
bluez-libs-3.34
sox-14.0.1


I posted a few times on headsets. You might look in the list archive for some 
older posts.



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)
  2008-07-04  4:27 ` jayjwa
@ 2008-07-04 14:17   ` Michael Domann
  2008-07-04 16:33     ` Martin Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Michael Domann @ 2008-07-04 14:17 UTC (permalink / raw)
  To: bluez-users

Hi,

sorry for kidnapping your thread. i have also a jabra bt 135

sysiphus:/home/profbunny/source/deluge# hcitool info 00:1A:45:6E:D5:23
Requesting information ...
        BD Address:  00:1A:45:6E:D5:23
        LMP Version: 2.0 (0x3) LMP Subversion: 0x978
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xfc 0xfe 0x0b 0x00 0x08 0x08 0x00 0x00
                <encryption> <slot offset> <timing accuracy> <role switch> 
                <hold mode> <sniff mode> <RSSI> <channel quality> <SCO link> 
                <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> 
                <paging scheme> <transparent SCO> <AFH cap. slave> 
                <AFH cap. master> 

if i understand it right, i need the patch, but i don't know how can i get the patch. do you have a link for me?

thanks micha

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)
  2008-07-04 14:17   ` Michael Domann
@ 2008-07-04 16:33     ` Martin Mueller
  2008-07-06 11:35       ` jayjwa
  0 siblings, 1 reply; 8+ messages in thread
From: Martin Mueller @ 2008-07-04 16:33 UTC (permalink / raw)
  To: BlueZ users

Moin,

On Fri, Jul 04, 2008 at 04:17:18PM +0200, Michael Domann wrote:
> 
> if i understand it right, i need the patch, but i don't know how can i get the patch. do you have a link for me?

You can get the patch from:

http://bluetooth-alsa.cvs.sourceforge.net/*checkout*/bluetooth-alsa/plugz/patches/sco-flowcontrol-v4.4.diff?revision=1.1

But the following section doesn't apply anymore to my 2.6.25 debian
kernel maybe someone knows how to fix it:

diff -ru linux-2.6.22-mh3/net/bluetooth/hci_conn.c linux-2.6.22-mh3-sco-flowcontrol/net/bluetooth/hci_conn.c
--- linux-2.6.22-mh3/net/bluetooth/hci_conn.c	2007-10-10 15:12:04.000000000 +0200
+++ linux-2.6.22-mh3-sco-flowcontrol/net/bluetooth/hci_conn.c	2007-10-10 14:31:19.000000000 +0200

@@ -208,6 +228,11 @@
 
        skb_queue_head_init(&conn->data_q);
 
+       hrtimer_init(&conn->tx_timer, CLOCK_MONOTONIC, HRTIMER_NORESTART);
+
+       if(type == SCO_LINK)
+               conn->tx_timer.function = hci_sco_tx_timer;
+
        init_timer(&conn->disc_timer);
        conn->disc_timer.function = hci_conn_timeout;
        conn->disc_timer.data = (unsigned long) conn;
@@ -217,6 +242,7 @@

bye
  MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)
  2008-07-04 16:33     ` Martin Mueller
@ 2008-07-06 11:35       ` jayjwa
  2008-07-07 10:55         ` [Bluez-users] Headset not working Malte J. Wetz
  0 siblings, 1 reply; 8+ messages in thread
From: jayjwa @ 2008-07-06 11:35 UTC (permalink / raw)
  To: BlueZ users

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2713 bytes --]



On Fri, 4 Jul 2008, Martin Mueller wrote:

-> > if i understand it right, i need the patch, but i don't know how can i get the patch. do you have a link for me?
-> 
-> You can get the patch from:
-> 
-> http://bluetooth-alsa.cvs.sourceforge.net/*checkout*/bluetooth-alsa/plugz/patches/sco-flowcontrol-v4.4.diff?revision=1.1
-> 
-> But the following section doesn't apply anymore to my 2.6.25 debian
-> kernel maybe someone knows how to fix it:
-> 
-> diff -ru linux-2.6.22-mh3/net/bluetooth/hci_conn.c linux-2.6.22-mh3-sco-flowcontrol/net/bluetooth/hci_conn.c
-> --- linux-2.6.22-mh3/net/bluetooth/hci_conn.c	2007-10-10 15:12:04.000000000 +0200
-> +++ linux-2.6.22-mh3-sco-flowcontrol/net/bluetooth/hci_conn.c	2007-10-10 14:31:19.000000000 +0200
-> 
-> @@ -208,6 +228,11 @@
-> 
->         skb_queue_head_init(&conn->data_q);
-> 
-> +       hrtimer_init(&conn->tx_timer, CLOCK_MONOTONIC, HRTIMER_NORESTART);
-> +
-> +       if(type == SCO_LINK)
-> +               conn->tx_timer.function = hci_sco_tx_timer;
-> +
->         init_timer(&conn->disc_timer);
->         conn->disc_timer.function = hci_conn_timeout;
->         conn->disc_timer.data = (unsigned long) conn;
-> @@ -217,6 +242,7 @@
->


We seem to be talking about different patches. I am refering to the one needed 
to allow older bluetooth (I think it's 1.2?) headsets to work with newer 
kernels, that deals with SCO/ESCO. The one above modifies another file. Below 
is the one I use, and it's working now even on linux-2.6.25.9 (kernel.org) 
that I'm currently using.


--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-26 12:46:36.000000000 
+0900
+++ linux-2.6.23/net/bluetooth/hci_event.c      2008-02-26 12:47:23.000000000 
+0900
@@ -1313,8 +1313,15 @@
         hci_dev_lock(hdev);

         conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
-       if (!conn)
-               goto unlock;
+       if (!conn) {
+               __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK : 
ESCO_LINK;
+
+               conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+               if (conn)
+                       conn->type = ev->link_type;
+               else
+                       goto unlock;
+       }

         if (!ev->status) {
                 conn->handle = __le16_to_cpu(ev->handle);




The email clients will probably mangle it (wrap), so I'll try to attach a 
gzipped version. If that doesn't work for some reason, I also have it on my 
ftp server 
ftp://atr2.ath.cx/pub/linux/patches/linux-kernel-bluetooth-1.2-headset-sco.patch.gz

or you can probably find it on the Web by searching for the file name 
(hci_event.c) if my server's being naughty with MSIE or curl's "@example.com" 
login.

[-- Attachment #2: linux-kernel-bluetooth-1.2-headset-sco.patch.gz --]
[-- Type: APPLICATION/x-gzip, Size: 348 bytes --]

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working
  2008-07-06 11:35       ` jayjwa
@ 2008-07-07 10:55         ` Malte J. Wetz
  2008-07-07 11:32           ` Martin Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Malte J. Wetz @ 2008-07-07 10:55 UTC (permalink / raw)
  To: BlueZ users

Am Sonntag, 6. Juli 2008 schrieb jayjwa:
> On Fri, 4 Jul 2008, Martin Mueller wrote:
> -> You can get the patch from:
> http://bluetooth-alsa.cvs.sourceforge.net/*checkout*/bluetooth-alsa/plugz
>/patches/sco-flowcontrol-v4.4.diff?revision=3D1.1 ->
>
> We seem to be talking about different patches. I am refering to the one
> needed to allow older bluetooth (I think it's 1.2?) headsets to work with
> newer kernels, that deals with SCO/ESCO. The one above modifies another
> file. Below is the one I use, and it's working now even on linux-2.6.25.9
> (kernel.org) that I'm currently using.

Well, as I wrote before, I'm already using the SCO/ESCO patch and it does =

not work.

The patch proposed by Martin does apply to current kernel (you just have to =

add =BB-F10=AB to your patch command as some line have moved beyond the def=
ault =

fuzz). But it does no good. Now, whenever I play back something via the =

headset, the entire kernel freezes and even Magic SysRq won't anymore. Only =

a hard reset gets me out of there.

Log files is insuspicous:

Jul  7 12:41:37 triton hcid[8053]: Audio API: received =

BT_GETCAPABILITIES_REQ
Jul  7 12:41:37 triton hcid[8053]: Audio API: sending BT_GETCAPABILITIES_RSP
Jul  7 12:41:37 triton hcid[8053]: Audio API: received =

BT_SETCONFIGURATION_REQ
Jul  7 12:41:37 triton hcid[8053]: config sco - device =3D 00:13:17:CF:C3:D=
5 =

access_mode =3D 2
Jul  7 12:41:40 triton hcid[8053]: pin_code_request (sba=3D00:0A:3A:81:33:1=
C, =

dba=3D00:13:17:CF:C3:D5)
<freeze here>


hci_usb is loaded with force_scofix=3D1. I cannot see any differences.

Still confused,
  Malte

-- =

Malte J. Wetz  <mail@malte-wetz.de>
Homepage: www.malte-wetz.de (PGP/GPG Keys available on homepage)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working
  2008-07-07 10:55         ` [Bluez-users] Headset not working Malte J. Wetz
@ 2008-07-07 11:32           ` Martin Mueller
  2008-07-07 12:15             ` Malte J. Wetz
  0 siblings, 1 reply; 8+ messages in thread
From: Martin Mueller @ 2008-07-07 11:32 UTC (permalink / raw)
  To: BlueZ users

Hi,

On Mon, Jul 07, 2008 at 12:55:06PM +0200, Malte J. Wetz wrote:
>
> Well, as I wrote before, I'm already using the SCO/ESCO patch and it
> does not work.

Hmm, do you have the bluetooth dongle connected via an USB-hub? If
yes, try plugging the dongle directly into the mainboard. In my setup
I can't use bt-dongles connected to hub for SCO, even though the rest
like rfcomm, l2ping, etc work.

> The patch proposed by Martin does apply to current kernel (you just
> have to add =BB-F10=AB to your patch command as some line have moved
> beyond the default fuzz). But it does no good. Now, whenever I play
> back something via the headset, the entire kernel freezes and even
> Magic SysRq won't anymore. Only a hard reset gets me out of there.

What a luck I wasn't able to apply it. ;-)

bye
  MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bluez-users] Headset not working
  2008-07-07 11:32           ` Martin Mueller
@ 2008-07-07 12:15             ` Malte J. Wetz
  0 siblings, 0 replies; 8+ messages in thread
From: Malte J. Wetz @ 2008-07-07 12:15 UTC (permalink / raw)
  To: BlueZ users

Am Montag, 7. Juli 2008 schrieb Martin Mueller:
> Hmm, do you have the bluetooth dongle connected via an USB-hub?

Currently, the Belkin dongle is connected directly to my mainboard. But I =

also tried my USB-Hub (active powered). Either way, it does not work.

-- =

Malte J. Wetz  <mail@malte-wetz.de>
Homepage: www.malte-wetz.de (PGP/GPG Keys available on homepage)

Verhandle nur, wenn Du in jedem Fall Profit davontr=E4gst!
                                        -- Ferengi-Erwerbsregel Nr. 42

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-07-07 12:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-03  0:37 [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem) Malte J. Wetz
2008-07-04  4:27 ` jayjwa
2008-07-04 14:17   ` Michael Domann
2008-07-04 16:33     ` Martin Mueller
2008-07-06 11:35       ` jayjwa
2008-07-07 10:55         ` [Bluez-users] Headset not working Malte J. Wetz
2008-07-07 11:32           ` Martin Mueller
2008-07-07 12:15             ` Malte J. Wetz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox