**** BEGIN LOGGING AT Thu Nov 05 02:59:56 2009 Nov 05 03:00:14 i can try LG phone. is it related with CLCC query? i don't know Nov 05 03:00:27 But swapping the call before a dial is definitely OK according to the spec Nov 05 03:01:21 i don't try Nokia phone because i don't have one. i need borrow others. Nov 05 03:01:27 log it and send me a log too if you can with some explanations of whats going on Nov 05 03:01:39 afk for dinner Nov 05 03:02:08 sure Nov 05 06:38:40 morning Nov 05 13:50:31 holtmann, I do like the the API design of dataconnectmanager. It is consistent, minimal, and quite easy to use. Nov 05 13:54:15 holtmann, But it seems that the Packet Radio Service(network register) seldom success. It only worked one time here. Nov 05 13:54:58 holtmann, I ever thought it is my 3G network signal issue, but connman works quite well. Nov 05 13:55:52 holtmann, not sure whether I missed some operation or there is some potential issue. I need spend some effort to investigate on it. Nov 05 14:08:53 martin_home, what I mean is Packet Radio Service attach tends to fail. Nov 05 15:13:16 holtmann, I got the root cause of the issue, gprs_load_setting() will set the powered as True without sending attach command. So it can not attached anymore. The work round is to powered off and on Packet Radio Service. Nov 05 15:13:28 holtmann, I will try to work out a patch to fix it. Nov 05 16:03:21 denkenz: do I need zhenhua patch to work on the interface at the BlueZ side? Nov 05 16:03:29 or can I start without that? Nov 05 16:03:53 up to you Nov 05 16:16:05 denkenz: what do I need to learn to do that? Nov 05 16:20:51 padovan: Start with gateway.c in bluez/audio Nov 05 16:21:23 padovan: Refactor it to implement the new Gateway API and implement an adapter driver to do the HFP Agent registration Nov 05 16:22:41 padovan: Then when new connection arrives or connection established by us call into the Handsfree Agent Nov 05 16:23:45 padovan: I can only give general guidance on the BlueZ part though, jhe is probably better to ask there Nov 05 16:26:06 denkenz: Ok. I'll look to that and talk to jhe Nov 05 16:51:37 padovan: note that the actual server socket is in audio/manager.c and not audio/gateway.c Nov 05 16:52:51 padovan: looking at the code it seems it could use quite a bit of cleanup/fixing. E.g. I don't think that gateway_connect_rfcomm should be called before authorization has completed and gateway_start_service() is probably unnecessary. Nov 05 16:55:24 jhe: I've no idea how that code got past review stage :) Nov 05 16:58:44 jhe: I don't have too much idea about what I need to do. What the steps? Nov 05 16:59:53 git rm gateway.c ;) Nov 05 17:01:04 denkenz: This reminds me. We need the error reporting from NewConnection. Nov 05 17:01:19 holtmann: Ok, tell me Nov 05 17:01:28 Since bluetoothd has to keep the RFCOMM socket open, oFono just gets a copy of it. Nov 05 17:01:57 And it needs to know if something unexpected happened to do a clean shutdown of the socket and a potentially opened SCO connection, Nov 05 17:02:21 holtmann: Can't it run a g_io_watch for NVAL ? Nov 05 17:02:39 So if for some reason in the way of setting it up, oFono does close(), it doesn't mean that the connection should close. It means that oops, I can't do it. Please bluetoothd take care of it. Nov 05 17:03:18 Yes it can and it has to do that since oFono needs to call shutdown() since close() will just decrease the reference count and not really close the connection. Nov 05 17:04:09 We must ensure that once NewConnection() returns, we are either setup properly or failed. Nov 05 17:04:30 Remember that even NewConnection() is fully async and so we have time before we return. Nov 05 17:04:49 I still don't see why we should bother Nov 05 17:04:55 Also you need a Cancel() method there in case bluetoothd decides otherwise in the meantime. If oFono setup takes too long. Nov 05 17:04:59 If ofono calls shutdown, there's nothing else you can do Nov 05 17:05:29 Unless we have cascading agents Nov 05 17:06:04 You wanna do a proper cleanup here. All these Handsfree implementations are weird and get easily confused. Even the Qualification tests enforce a certain order for things. Nov 05 17:06:28 what is 'proper' cleanup? Nov 05 17:06:41 Also you might wanna consider allowing the any adapter path for agent registration. Nov 05 17:06:47 Just a thought. Nov 05 17:07:14 So that last argument I can buy :) Nov 05 17:07:48 Proper cleanup is whatever needs to be done. We can figure that out later, but you will need some sort of reporting what is going on. And it is implicit in the D-Bus method_call, method_return, error anyway. So it is there anyway. You just need to use it. Nov 05 17:08:13 Isn't closing the socket 'proper' cleanup? Nov 05 17:09:34 As I said, you would have to do shutdown, but that might not be right order. You might have to close the inband ring SCO socket first. There are so many variables with Handsfree. Nov 05 17:11:32 Anyway its fine with me since bluetoothd will have to handle async calls anyway Nov 05 17:11:53 Just seems overly complicated for the first cut Nov 05 17:12:30 Leave it out then. You just assume right now it always succeeds. Adding error codes later is not a problem either. Nov 05 17:12:39 So, add Cancel() method and possible errors to HandsfreeAgent Nov 05 17:13:20 Add the errors when you cross that bridge and have a working implementation. I am pretty sure the error case come all by themself once it is implemented. Nov 05 17:13:52 For Cancel(), yes, we need to cancel the NewConnection() if it takes longer and in between the connection died or something else happened. Nov 05 17:14:05 holtmann: so you're saying NewConnection shouldn't return before the SLC init is complete? (the few mandatory AT commands that always get sent)? Nov 05 17:14:29 That would be my assumption right now. Nov 05 17:14:35 holtmann: I was thinking of having a separate notification from ofono to bluetoothd for when the SLC is ready but I guess we can do it as part of NewConnection too Nov 05 17:15:11 Cancel() leads to fun race conditions btw Nov 05 17:15:45 What kind of fun race conditions. We have been using this semantic for while now? Nov 05 17:16:03 Problem is, for pairing bluetoothd always controls it Nov 05 17:16:14 Here, the BRSF exchange is done on the oFono side Nov 05 17:16:27 so oFono might receive cancel when it has already sent out the method return Nov 05 17:19:14 Fair enough. Then we might should go with the separate notification. Nov 05 17:20:44 Do we really need the cancel btw? Nov 05 17:21:03 If bluetoothd determines that it is taking too long, it should forcefully disconnect the socket Nov 05 17:21:21 And assume that oFono side will detect that Nov 05 17:21:57 We can still have NewConnection return from method_call when BRSF exchange has occurred Nov 05 17:26:59 jhe: denkenz: gateway.c is AG code, I didn't understand one thing: why will we change AG code to do the HF side? Nov 05 17:28:30 padovan: no, audio/headset.c is AG code Nov 05 17:29:30 hmm. ok Nov 05 17:30:33 padovan: historically we started off with doing headset profile support and the initial code went into headset.c (even though our role in this case was AG). Everything else (HFP profile & HF/HS role) has been named based on that constraint. Nov 05 17:33:34 ok. Nov 05 17:35:28 holtmann, jhe: So what is the consensus, Cancel() method or no? Nov 05 17:35:44 jhe: so let me understand. what's the with the today gateway.c? why we need a new interface? Nov 05 17:36:03 Leave Cancel() out. We add it when we need it. Nov 05 17:36:25 holtmann: Ok, do you want me to post hfp-api.txt to bluez-devel and ofono? Nov 05 17:36:52 I don't care, but linux-bluetooth might be better since its its API. Nov 05 17:37:03 yep ok Nov 05 17:43:31 Ok on the list now Nov 05 18:04:07 jhe: after refactor will we need a Handset manager/adapter too? Nov 05 18:27:31 padovan: Handset? Nov 05 18:31:44 jhe: does today gateway.c do HS role? Where will be HS after refactor? Nov 05 18:32:07 padovan: we're just foccusing on HFP Nov 05 18:32:20 padovan: i.e. you don't need to worry about HSP headset role support Nov 05 18:32:27 jhe: ok Nov 05 18:33:48 jhe: having HF-role audio part implemented, doesnt we get HS-role for free? Nov 05 18:34:12 jprvita: not quite Nov 05 18:34:43 jprvita: e.g. ofono would need to know whether to start sending HFP SLC init commands or not when it gets a fd from bluetoothd Nov 05 18:34:47 we can do it, but definitely not 'for free' Nov 05 18:35:43 jprvita: furthermore, there's neither telephony control nor state monitoring in HSP which is kind of a basic assumption for ofono Nov 05 18:36:22 jhe: but it seems that we could have a lot shared code, at least in bluez, right? or this is a totally wrong impression? Nov 05 18:36:56 in the case of having both implemented Nov 05 18:36:57 jprvita: yes, if we would want to do HSP HS role then a lot of the code could be reused Nov 05 18:37:29 jhe: denkenz: what's the diff between Adapter and Manager into HFP API? Nov 05 18:37:56 jhe: thats good :) Nov 05 18:38:41 padovan: Manager controls all adapters, adapter controls particular bluetooth dongle Nov 05 18:38:58 padovan: You might want to run oFono on one dongle and another telephony daemon on another Nov 05 18:39:23 denkenz: s/Adapter/Agent/ Nov 05 18:39:41 sorry, diff between Agent and Manager Nov 05 18:39:50 Manager is running on BlueZ side Nov 05 18:39:56 Agent is running on oFono side Nov 05 18:41:55 denkenz: how do they relate to each other? a rfcomm socket? Nov 05 18:42:24 don't understand the question Nov 05 18:43:54 how do a Manager running on BlueZ side relate to the Agent on the oFono side? Nov 05 18:44:11 Ok, so BlueZ starts, oFono starts up sometime later Nov 05 18:44:27 oFono registers an agent with HandsfreeManager for adapter X Nov 05 18:45:08 HFP connection is made on adapter X, BlueZ looks to see what Agent (if any) handles HFP connections on adapter X Nov 05 18:45:30 It then calls Agent.NewConnection on the agent Nov 05 18:47:30 denkenz: who starts this HFP connection you mentioned? Nov 05 18:47:58 It might be the AG Nov 05 18:48:08 or it might be the UI Nov 05 18:48:22 or it might be oFono by using the Gateway.Connect Nov 05 18:48:52 What does Agent.NewConnection do? Nov 05 18:49:17 We get the rfcomm socket, so oFono can initiate the BRSF exchange Nov 05 18:49:29 e.g. what opening /dev/rfcommX does now Nov 05 18:49:38 ok Nov 05 18:50:45 and when does bluez create the SCo routing? Nov 05 18:51:07 For HFP I think jhe mentioned to let the AG do it Nov 05 18:51:15 I'm not the expert there Nov 05 18:51:22 yep, for HFP it's better to always let the AG have control of the SCO creation Nov 05 18:52:27 jhe: Btw, RegisterHandsfreeAgent(object path) might need a object device parameter as well Nov 05 18:52:47 jhe: Since oFono might want to map Powered property to Gateway.Connected property Nov 05 18:53:59 denkenz: not quite following. so you'd be registering the agent for an adapter but still have it for a specific device? Nov 05 18:54:12 yeah I'm waffling right now Nov 05 18:54:19 denkenz: in that case it sounds like the original registration method should go directly to a device object and not the adapter Nov 05 18:54:32 so the Agent interface is going to be implemented inside ofono, under it's service name, but defined in bluez? and whatever other one who want could implement it's own HFP agent? Nov 05 18:54:38 Basically oFono should create a Modem with HFP driver for each .Gateway object path it finds on BlueZ Nov 05 18:55:16 jhe: Yes, it sounds like it should be on Device, not Adapter Nov 05 18:55:48 ah, so you want a "modem" to exist on the ofono side before even calling Gateway.Connect Nov 05 18:56:05 correct Nov 05 18:56:28 I was thinking of a similar setup as we have with pulse audio where pulse creates a new "sound card" only when some device goes into connected state Nov 05 18:56:38 imo that makes more sense to me Nov 05 18:56:46 So connman works this way Nov 05 18:57:01 it looks for all devices with PAN and exposes them as a network in connman Nov 05 18:57:12 ok Nov 05 18:57:24 So enable/disable on the network results in connect/disconnect on PAN interface Nov 05 18:57:55 I usually think of a bluetooth connection as a virtual cable Nov 05 18:58:17 when you connect you get a new peripheral attached to your PC and when disconnected it's as if the peripheral doesn't exist Nov 05 18:58:57 and the control of pluging the peripheral is outside of the software components that in the end use the peripheral once it's plugged in Nov 05 18:59:25 Trouble is, the UI might want to 'power on' the hfp modem Nov 05 18:59:43 Makes sense to do it through oFono Nov 05 19:00:06 in a way yes Nov 05 19:00:25 in another way you could have a UI dealing with a list of configured bluetooth devices and that UI wouldn't need to know about ofono Nov 05 19:00:44 which would still work Nov 05 19:01:13 oFono would just listen for Connected property and bring up the hfp automagically Nov 05 19:01:19 true Nov 05 19:01:44 it is basically too complicated to every subsystem to know how to deal/connect with bluetooth devices, so normally I would say the bluetooth ui should be responsible to virtually plug the devices Nov 05 19:03:33 I can see how this can be justified both ways Nov 05 19:03:55 in one case you have a UI that knows about modems, in another case you have a UI that knows about bluetooth devices Nov 05 19:04:48 neither UI needs to know both the bluez and ofono API's but just one if ofono could proxy the connect request Nov 05 19:05:25 exactly Nov 05 19:05:57 I can see it both ways, but I think the way connman does it with PAN is the 'better' way Nov 05 19:07:26 PAN is a bit different though. At when you've got a NAP. Nov 05 19:07:51 the NAP never initiates connections Nov 05 19:08:17 so you don't have to worry about the case when a network device suddenly gets "powered on" even though the user didn't request it Nov 05 19:08:53 however with audio (both A2DP and HFP/HSP) either side can initiate the connection and so you have to deal with the fact that the modem can get magically "turned on" Nov 05 19:09:06 so in oFono we have no issue with that Nov 05 19:09:38 in fact we explicitly (should if we don't already) support attaching to 'live' devices Nov 05 19:09:49 ok Nov 05 19:10:30 so basicly, if we go with per-device registration the API gets simplified quite a bit Nov 05 19:11:08 we can drop the HandsfreeManager interface completely (and have the registration method in the Gateway interface) and the object device parameter can be removed from NewConnection Nov 05 19:11:21 yep Nov 05 19:11:33 sound really good Nov 05 19:12:20 So do we want to name .Gateway into HandsfreeGateway? Nov 05 19:12:22 what about SAP and obexd, I would really want a unified Agent to talk to telephony subsystem Nov 05 19:12:49 SAP is quite a bit different from HFP protocol Nov 05 19:12:50 forgetting vendor specific commands, maybe we need something similar to integrate oFono and Bluetooth Sim Access Server. Nov 05 19:13:06 denkenz, but they overlap quite a lot Nov 05 19:13:07 denkenz: I'd support that since "Gateway" could be understood to have something to do with networking as well Nov 05 19:13:29 denkenz, and so does pbap Nov 05 19:13:36 Maybe HandsfreeManager hierarchy could be more generic. fd passing will be also necessary for APDU exchanging. Does it make sense? Nov 05 19:14:01 Can't we have a cloned setup for SimAccessManager? Nov 05 19:14:20 so have .SimAccess interface with Connect/Disconnected/RegisterAgent Nov 05 19:14:49 yeah, sounds like a good plan Nov 05 19:15:32 jhe, holtmann, and perhaps we should get rid of those telephony drivers and have the Agent deal with server role too, how about that? Nov 05 19:16:15 oFono eventually will have a modem emulator project Nov 05 19:16:27 so DUN/HFP AG can be done Nov 05 19:16:41 essentially it is a buildtime X runtime Nov 05 19:16:56 Vudentz: that would imply that you must have a second process to implement the driver Nov 05 19:17:21 jhe, yep, which may helps to deal with telepathy Nov 05 19:17:42 every time I hear 'telepathy' I shudder Nov 05 19:17:53 Vudentz: yeah, but I think we can have a solution where both options are available Nov 05 19:19:25 Vudentz: if you want the agent support for bluez telephony then we could keep the current design but have the default driver implement an agent interface and proxy the C function calls into the D-Bus based Agent interface Nov 05 19:19:43 Vudentz: but this is starting to drift a bit off-topic for #ofono :) Nov 05 19:20:53 jhe, yep, if only we could use the same drivers for pbap, well lets stick to the topic :D Nov 05 19:22:54 Is there a profile for SMS access? Nov 05 19:23:50 yep, message access profile Nov 05 19:24:56 Is it only Import, or can it be used to send / receive? Nov 05 19:25:34 denkenz, no idea, I only know it exists never really took a look at the spec Nov 05 19:26:11 So theoretically one can extend the Handsfree driver with Phonebook support by using PBAP Nov 05 19:26:24 If MAP supports sms send / receive, we can also do SMS this way Nov 05 19:26:49 I'm not crazy enough to try this, but if anyone wants to... :) Nov 05 19:27:51 the main issue I see here is that MAP and PBAP are OBEX based and provided by obexd, and obexd runs in the session whereas ofono runs in the system Nov 05 19:29:56 about MAP, it is possible send messages and receive notifications fo incomming messages Nov 05 19:30:19 yep, perhaps it is too early to think about this without having some implementation in place Nov 05 19:30:37 Lets do HFP first :) Nov 05 19:31:16 but something to think about, since oFono UI can be written once Nov 05 19:31:29 That can talk to real modems / SAP / PBAB+MAP+HFP Nov 05 19:35:40 yep, and we just pulled the trigger by adding support for phonebook and telephony driver in obexd too Nov 05 19:36:42 why does obexd run in session? can't polkit handle it? Nov 05 19:37:40 That is a discussion to have with holtmann, AFAIK he had good reasons Nov 05 19:37:56 tmzt: mainly because it's responsible for reading and writing user files Nov 05 19:38:35 ah Nov 05 19:38:36 tmzt, iirc it was more convenient to access the files that way, but I guess now that we have fd passing in dbus sitting on top of system bus in no longer a problem Nov 05 19:38:36 tmzt: sure you could try to enforce the proper security control by having it as a system level process but it's much simpler to have it running in the user session as any other user process Nov 05 19:38:37 right Nov 05 19:40:35 holtmann has to decide whether PBAB+MAP+HFP is feasible / desired Nov 05 19:40:43 Since that would require major surgery to obexd Nov 05 19:41:24 I see Nov 05 19:43:26 krau: SAP is something we should tak about early next year though ;) Nov 05 19:45:08 denkenz: cool, actually I am implementing a SAP client prototype Nov 05 19:45:47 krau: Nice. SAP has less surprises, for the most part its just a regular modem with a different transport and a different protocol Nov 05 19:46:07 I don't have enough knowledge about oFono API to implement the SAP server yep :-) Nov 05 19:46:31 s/yep/yet Nov 05 19:46:48 Yeah that one's more tricky Nov 05 19:47:02 Server would probably have to be a plugin inside oFono Nov 05 19:47:17 since it needs direct access to most commands Nov 05 19:47:21 jhe did you have problems to connect osso-sap to S60 phones? It is not working on N78 and N85 Nov 05 19:47:51 krau: at least you need to make sure that you've paired with 16 digits before trying to connect Nov 05 19:48:12 it is using 16digits Nov 05 19:48:28 krau: I don't think those models were around when I did the implementation for the 770 Nov 05 19:49:32 jhe: the command is correct, but the phone doesn't reply, no idea what is happening Nov 05 19:49:33 krau: however the 16 digits and of course remembering to enable SAP mode in the control panel are the only potential issues I can think of right now Nov 05 19:50:27 the rfcomm connection is established, but the phone doesn't send CONNECT_RESP Nov 05 19:50:48 krau: and it's working fine with other phones? Nov 05 19:51:02 for 5310 it works Nov 05 19:52:47 http://pastebin.com/m4c8c88c3 (N85 hcidump) Nov 05 19:53:24 * krau away Nov 05 20:03:59 where should the point be at which you create a separate driver (like sim driver) for a given device plugin, vs. add vendor quirk? Nov 05 20:04:25 if one of the commands executed on init on that device must be different, do you create a separate driver? Nov 05 20:09:51 seems so, I have the same problem Nov 05 20:16:53 balrog-k1n: If its just one command, no Nov 05 20:17:04 balrog-k1n: See the calypso quirk in netreg driver Nov 05 20:18:53 denkenz: turns out on those qualcomm modems you need to always supply length to AT+CRSM or it assumes zero, AT+CRSM=192,N becomes AT+CRSM=192,N,0,0,15, i'm wondering if there was anymodem that needed the reverse? Nov 05 20:19:30 not modems per se Nov 05 20:19:34 SIM Cards Nov 05 20:19:45 or rather, both Nov 05 20:19:48 oh, right Nov 05 20:20:14 on MBM devices which support 3G, if you have a UICC inserted CRSM of length 15 is meaningless Nov 05 20:20:19 The format is totally different Nov 05 20:20:56 on this modem, you can pass a higher number, like 150, and it'll clip to the minimum of file length or that number Nov 05 20:21:00 rather than give you an error Nov 05 20:21:20 I suspect its fine to quirk that part Nov 05 20:22:34 We can also possibly do some detection up front whether it is UICC or not Nov 05 20:23:05 I think we can use EFphase for this Nov 05 20:23:48 denkenz: we can always pass the maximum of the UICC-style or G2 style length, Nov 05 20:24:09 Yeah, but I bet ya some modems won't like it Nov 05 20:24:20 but i'm afraid there might be a modem that returns error if the number is bigger than what it expects Nov 05 20:24:34 Another option is to check EFpl to see what the response is Nov 05 20:24:45 If it starts with 0x62 it is a 3G card Nov 05 20:25:12 so we can run CRSM=192,efpl,0,0,1 for instance Nov 05 20:25:36 using EFphase sounds like a better idea Nov 05 20:26:04 EFphase is guaranteed to be present in 2G cards and not in 3G cards Nov 05 20:26:12 however, not sure about 1G Nov 05 20:26:19 Not sure if we care :) Nov 05 20:26:50 let's just have a quirk for this modem for now Nov 05 20:27:14 yeah that's fine, but do find a 3G card already Nov 05 20:27:23 Since the CRSM response might be different Nov 05 20:50:42 jhe: I removed all the code related with the AT engine from gateway.c. Do you think we can reuse the code that handles sco and rfcomm? Nov 05 20:52:00 padovan: for the most part yes Nov 05 20:58:27 jhe: what should I do next? Nov 05 21:00:16 padovan: you need to implement a method handler for RegisterHandsfreeAgent Nov 05 21:01:08 padovan: assuming you alrady removed the method handlers from the old interface that aren't part of the new one Nov 05 21:01:52 jhe: yes, I removed **** ENDING LOGGING AT Thu Nov 05 22:35:36 2009 **** BEGIN LOGGING AT Thu Nov 05 22:46:16 2009 Nov 06 01:40:12 denkenz: ping **** ENDING LOGGING AT Fri Nov 06 02:59:57 2009