**** BEGIN LOGGING AT Fri Jan 22 02:59:57 2010 Jan 22 18:33:43 denkenz: ping Jan 22 19:11:36 jhe: ping Jan 22 19:12:42 padovan: pong Jan 22 19:16:01 denkenz: on the AdapterRemoved signal I have to remove all modem from that devices. What do you suggest to trace which device belongs to the removed adapter? Jan 22 19:16:34 denkenz: and, when the playing signal should raise? Jan 22 19:17:14 worst case use a hash table for the device / adapter mapping Jan 22 19:18:06 and the best case? Jan 22 19:19:18 Look at how connman did it? :) Jan 22 19:20:51 Basically what you can do is HashTable for adapters -> data structure Jan 22 19:21:08 Then use a simple list of devices as what you store in the hash table Jan 22 19:21:38 When the adapter is removed, remove what is in the hash table and thus iterate over the list, removing the modems Jan 22 19:22:23 Sounds good. I'll do that. Jan 22 19:22:26 connman I think does something similar, but looking briefly over the code I think they got the adapter removed part wrong Jan 22 19:23:42 denkenz: and about the playing signal? Jan 22 19:24:34 jhe has to comment on that one, I presume Playing is emitted when the SCO link is established Jan 22 19:25:47 That's is what we are doing, but pulseaudio is drop the bluetooth audio after some seconds. Jan 22 19:26:16 sounds like a bug then Jan 22 19:27:50 yeah, but original zhenhua' patches was working with pulseaudio. I'm looking for the diferences in the audio part. Jan 22 19:28:38 Not sure what could really go wrong, both simply open SCO and hand it off to alsa/pulse Jan 22 19:29:15 run hcidump and see if you can glean anything from it? Jan 22 19:29:28 Maybe BlueZ is closing the SCO link for some reason? Jan 22 19:29:32 hum.. good idea. Jan 22 19:35:32 denkenz: just a I little doubt. The connected signal state is meant to raise when rfcomm is established, right? Jan 22 19:36:10 Yep Jan 22 19:36:44 It might need to be tweaked a little, e.g. when the HandsfreeAgent returns OK Jan 22 19:36:56 Then we know BRSF has been exchanged Jan 22 19:37:46 But all of this is complicated by in-band ring tones, etc. So for now ideally emit Connected when HF Agent returned OK Jan 22 19:39:35 Right. Jan 22 20:17:45 padovan: you shouldn't need to listen for AdapterRemoved. Instead, in that case bluetoothd should call Release() for any handsfree agent registered under that adapter. Jan 22 20:18:21 jhe: hum.. even better :) Jan 22 20:21:31 denkenz, padovan: bluez will only close the SCO if there's no external prosess that has requested it (e.g. pulseaudio). if pulseaudio has the SCO fd bluez won't close it. Jan 22 20:22:48 (or call shutdown() to be more precise since close() will not actually cause a disconnection but just decrease the kernel side refcount by one) Jan 22 20:25:51 jhe: so pulse should load module-bluetooth-device and try to get the fd just after the state property goes to 'playing', right? Jan 22 20:26:43 jprvita: actually the common case is that the SCO connection is triggered by pulse requesting a SCO fd. not the other way around. Jan 22 20:26:46 since in HFGW connected is related with the rfcomm link Jan 22 20:26:56 (at least for us being the AG) Jan 22 20:27:43 right, that's the way it is implemented for the case we are the AG connecting to a HS Jan 22 20:27:45 but with HF role it's different since it's usually the AG that initiates SCO Jan 22 20:28:00 yep Jan 22 20:28:32 I guess it completely depends on the code in audio/gateway.c since iirc the AG role timer is in audio/headset.c Jan 22 20:29:39 This should have been solved in the present gateway.c code Jan 22 20:30:25 what is your code doing that is different from the current upstream solution? Jan 22 20:30:41 I've been going to some problems with the link getting connected and then disconnected after a while Jan 22 20:30:55 I'm using current padovan's patches Jan 22 20:32:02 So does the code in bluez git today work? Jan 22 20:32:27 Since it also implements HF role Jan 22 20:33:07 I'm testing the AG and doing pulseaudio patches for that.. The HF worked without problems last time I tryed Jan 22 20:33:50 No, I mean the HeadsetGateway code from Forrest Jan 22 20:33:57 in audio/gateway.c Jan 22 20:35:51 I suspect the audio disconnect logic does not work for the HF role Jan 22 20:36:08 And that the current implementation relies on some external hack to make it work Jan 22 20:38:50 (e.g. like AudioManager pulse plugin calls the internal IPC when CallStarted is emitted) Jan 22 20:38:59 hum, I didn't look at that code.. But I think pulseaudio would need some love even for that case Jan 22 20:39:39 no doubt, I run away screaming every time I look into gateway.c/headset.c :) Jan 22 20:41:54 I'll have a look again on the plane, but if Zhenhua's code does indeed work, look into what the differences are Jan 22 20:42:00 hehehe Jan 22 20:42:02 It has to be something silly Jan 22 20:43:04 my patch does exactly the same thing zhenhua's one did, just adapted for the new interfaces and a little less hackish Jan 22 20:43:28 but the function is the same Jan 22 20:43:54 if that is the case, then either his doesn't work either or they're not the same Jan 22 20:45:06 so the problem could be in my gateway.c code. Jan 22 20:45:20 I'll compare that with zhenhua's code. Jan 22 20:45:28 at first I've been think of some difference on bluez part, because it was working against zhenhua's version of bluez and ofono patches too Jan 22 20:45:41 Yes, focus on the differences Jan 22 20:45:52 specially the signals Jan 22 20:46:22 zhenhua was using a CallStarted signal which was triggered by another signal coming from ofono Jan 22 20:46:48 Yes, the CallStarted bit was the 'external hack' part Jan 22 20:46:56 yep Jan 22 20:47:17 Again, I suspect we simply need to disable the timeout logic for HF role Jan 22 20:47:25 It works fine for AG role, but maybe not HF Jan 22 20:47:47 yes, that worth a try for sure Jan 22 20:47:55 Anyway I'm off to catch a plane Jan 22 20:50:39 jhe: btw, do you have any other comments on my code? Jan 22 20:59:02 padovan: did you already send another updated patch? iirc the latest one was still calling the state variable "i" instead of "state" in your state2str function. Jan 22 21:00:08 padovan: another thing that will need to be sorted out is ability to keep compiling against the current stable dbus branch. the patch wont go upstream without it. Jan 22 21:02:56 jhe: I did a #ifndef DBUS_TYPE_UNIX_FD for that Jan 22 21:04:15 But I don't know if it's the better solution. Jan 22 21:05:39 su Jan 22 21:05:51 whoops Jan 22 21:06:14 padovandenis s was suggesting some autotools magic to disable gateway.c compilation in that case Jan 22 21:06:30 padovan: but my initial proposal would also have been just a simple ifndef Jan 22 21:07:56 jhe: ok, I'll look to autotools, but only after finish the implementantion in gateway.c :) Jan 22 21:13:01 jhe: I guess you'll have to change your password from 'whoops' now, hehe Jan 22 21:13:11 hahah **** ENDING LOGGING AT Sat Jan 23 02:59:57 2010