kbluetooth4 for slackware 13-current

rworkman · 12-11-2009, 01:43 PM

Quote:

Originally Posted by drgr33n

@ JeanSimeoni
Are you using a usb device or is it built in ? If its built in hotplugging will not work for this device and you have to start the bluetooth services manually.

Interesting; that means we just might need an rc.bluetooth after all. More investigation needed, I guess. On that note, I downgraded to 4.56 here, and bluetoothd still doesn't start at boot, so now I'm thinking that I probably am misremembering. I hate when I do that.

Quote:

@ rworkman
It seems the I/O interference is down to blueman flooding udev ?? the trunk version of blueman seems to have solved this one ?

Maybe revision 206 from their bzr repo is the commit that addressed this.

Quote:

Sorry I haven't been keeping up but i have had two exams in the last 3 weeks and things have been hectic. I'l try to get some more done over the weekend.

No worries - I understand how that goes.

drgr33n · 12-11-2009, 10:14 PM

Hey guys,

I think I've got blueman and its dependents to a pretty stable state. More trials are needed I think, but so far so good. there are quite a lot of things needing updating though to get blueman running as it should.

I think we may still need rc.bluetooth for the moment as I think we may never get hotplugging working for internal bluetooth cards. maybe it will be fixed in a later version of bluez ?? I've tried bluez 4.56, *.58 and udev 141, 149 and still no difference.

I've been trying to get blueman to replicate the udev flood bug with the trunk version and so far so good, no out of the ordinary behavior. I will post everything that was needed tomorrow.

rworkman · 12-12-2009, 12:55 AM

Aha! I stumbled across an Ubuntu forum post that points out what is now rather obvious.
bluetoothd needs dbus to be running, but guess what's not running during early boot? :-)

There are at least two ways to fix this:

1) Make an /etc/rc.d/rc.bluetooth script that contains this:

Code:

  udevadm trigger --subsystem-match=bluetooth

2) Start dbus earlier in boot.

It *still* might not be possible to start dbus early enough, but that's my preferred approach regardless - I'd like to start dbus early in boot so that wicd users can depend on the network being up earlier.

At this point, assuming the blueman disk thrashing issue is truly resolved (and it seems that it is), I'm happy with the state of these packages. Unless there's a way to use konqueror or dolphin to browse obex:// links, there's not going to be a solution to that problem (unless you know something I don't). Either way, we can perhaps patch blueman/Constants.py.in to change OBEX_BROWSE_AVAILABLE to False, or we can change DEF_BROWSE_COMMAND to something besides nautilus (e.g. konqueror).

drgr33n · 12-12-2009, 11:18 AM

Hey Robby,

I've just emailed you about the konqueror problem buddy. I think I have a solution that will work. As for starting dbus earlier I don't think this will be possible. I did have an idea it was down to this, I think I may of said in an earlier post ?? And I did try to get dbus to start early enough but was unsuccessful. (Although I didn't spend to much time on this)

Cheers,

Zarren

rworkman · 12-12-2009, 11:52 PM

Quote:

Originally Posted by drgr33n

Hey Robby,

I've just emailed you about the konqueror problem buddy. I think I have a solution that will work.

Received and replied - thanks :-)

Quote:

As for starting dbus earlier I don't think this will be possible. I did have an idea it was down to this, I think I may of said in an earlier post ??

You probably did, and I probably overlooked it. I had "blinders" on for far too long with this issue :/

Quote:

And I did try to get dbus to start early enough but was unsuccessful. (Although I didn't spend to much time on this)

As I said in the reply mail, I don't think we'll be able to start dbus early enough for this, but there are other reasons to start it as early as possible anyway, even though the bluetooth issue will be fixed in another way.

uppman · 12-27-2009, 10:29 AM

I have been trying to get a BT headset to work for a couple of hours now. *pull hair*

It has been paired succesfully with blueman and below is some info about the headset.

Code:

root@localhost:/mnt/data/user1# hcitool info 00:1C:EF:34:82:DC
Requesting information ...
        BD Address:  00:1C:EF:34:82:DC
        Device Name: Nokia BH-101
        LMP Version: 2.0 (0x3) LMP Subversion: 0xbf9
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xbc 0xfe 0x0f 0x80 0x0b 0xe8 0x00 0x00
                <encryption> <slot offset> <timing accuracy> <role switch>
                <sniff mode> <RSSI> <channel quality> <SCO link> <HV2 packets>
                <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
                <power control> <transparent SCO> <extended SCO> <EV4 packets>
                <EV5 packets> <AFH cap. slave> <AFH cap. master>
                <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps> <3-slot EDR eSCO>

Every time I try to use the headset I only get some static noise and a strange message in the log:

hci_scodata_packet: hci0 SCO packet for unknown connection handle 45

The bluetoothd is running with debug and displays the following:

Code:

bluetoothd[6401]: Accepted new client connection on unix socket (fd=23)
bluetoothd[6401]: Audio API: BT_REQUEST <- BT_GET_CAPABILITIES
bluetoothd[6401]: Audio API: BT_RESPONSE -> BT_GET_CAPABILITIES
bluetoothd[6401]: Audio API: BT_REQUEST <- BT_OPEN
bluetoothd[6401]: open sco - object=ANY source=ANY destination=ANY lock=write
bluetoothd[6401]: Audio API: BT_RESPONSE -> BT_OPEN
bluetoothd[6401]: Audio API: BT_REQUEST <- BT_SET_CONFIGURATION
bluetoothd[6401]: Audio API: BT_RESPONSE -> BT_SET_CONFIGURATION
bluetoothd[6401]: Audio API: BT_REQUEST <- BT_START_STREAM
bluetoothd[6401]: State changed /org/bluez/6401/hci0/dev_00_1C_EF_34_82_DC: HEADSET_STATE_CONNECTED -> HEADSET_STATE_PLAY_IN_PROGRESS
bluetoothd[6401]: Unix client disconnected (fd=23)
bluetoothd[6401]: telephony-dummy: device 0xb7fffd58 disconnected
bluetoothd[6401]: State changed /org/bluez/6401/hci0/dev_00_1C_EF_34_82_DC: HEADSET_STATE_PLAY_IN_PROGRESS -> HEADSET_STATE_DISCONNECTED
bluetoothd[6401]: client_free(0xb7ffa8e0)
bluetoothd[6401]: No matching connection found for handle 45

I have done a *fair* amount of googling but have only found something about patching the kernel..

Any ideas?

TIA/Magnus