**** BEGIN LOGGING AT Tue Nov 03 02:59:57 2009 Nov 03 03:44:03 holtmann: hoy Nov 03 03:44:11 holtmann: finally starting toying with pygtk & gnome applets :-) Nov 03 03:44:28 holtmann: hopefully will have current network name and a couple more things in an applet soon Nov 03 03:46:39 most of the GNOME doco for applets is ... still to be written :-) fun Nov 03 04:26:47 benh: Great :) Nov 03 04:27:11 And don't bother with a GNOME applet. Just write a GTK app. that uses the notification area. The applet crap is stupid and nobody really uses it anymore. Nov 03 04:27:34 benh: Btw. phonesim now uses automake/autoconf. So no confusion anymore. Nov 03 05:01:50 holtmann: yea I saw Nov 03 05:02:13 holtmann: oh well, I started with the applet crap :-) mostly because I wanted to display multiple things in there Nov 03 05:02:22 holtmann: but I'm tempted to switch back to notification area with just an icon Nov 03 05:02:27 holtmann: and put everything in the pull-down Nov 03 05:02:39 holtmann: we'll see, I'm just toying with crap right now Nov 03 05:03:02 holtmann: which reminds me ... might be interesting at some stage to add more info to modems that haven't been enabled :-) Nov 03 05:03:07 holtmann: at least some "user visible" name Nov 03 05:03:20 holtmann: anyway, I'll come back to you when I have something Nov 03 05:03:47 Kinda hard if we don't have it. Sometimes udev gives us this, but most times, we have no clue until they are enabled. Nov 03 05:04:08 But we can stick a name or description in modem.conf. Nov 03 05:06:08 yes Nov 03 05:06:16 and udev often has "something" Nov 03 05:06:27 at least we can standadize on a property to stick in when we have -something- at least Nov 03 05:06:32 anyway, no biggie Nov 03 05:06:37 it's more for "select your modem" kind of thing Nov 03 05:06:45 a bit annoying to power them all on just to display a decent list Nov 03 05:25:07 holtmann: btw, what's the unit or min/max for the signal strenght ? Nov 03 05:28:04 I would assume percent. Nov 03 05:28:13 Did we forget to document that? Nov 03 05:28:18 0-100. Nov 03 05:28:37 Not that GSM can be that precise anyway. Nov 03 05:28:47 denkenz: Details. Nov 03 05:37:04 holtmann: I might have missed it in the doco Nov 03 05:37:13 anyway, back to family matters Nov 03 05:37:18 will continue toying around this week Nov 03 05:37:34 nothing fancy, just want a little applet that shows the operator, allows to switch maybe Nov 03 05:37:39 and eventually receive and send SMS Nov 03 05:37:53 might switch to notification area as you suggested... we'll see Nov 03 05:38:19 it's all reasonably trivial stuff but I have a hard time spending more than 5mn in a row on it between work emergencies and family :-) Nov 03 05:38:41 Can't wait to see it. Nov 03 06:25:57 hehe Nov 03 06:26:00 don't hold your breath too much Nov 03 06:26:02 allright that's it Nov 03 06:26:07 applets oficially suck Nov 03 06:26:14 I'll switch to the notification area :-) Nov 03 06:26:43 I got some basic appletish stuff but it's shithouse to use and debug and generally sucks as an API Nov 03 06:30:32 denkenz, I am working on ConnMan offono plugin, and want to use it to implement MBM 3G data support. Nov 03 06:30:57 denkenz, Could you tell me the state of the MBM support state in ofono? ;-) Nov 03 07:26:08 martin_office: We have enough to attach / report registration status / activate the context on MBM Nov 03 07:26:24 Haven't tested much beyond that since my MBM hardware crashes Nov 03 07:32:03 denkenz, so the Dbus-API is ready for me to write plugin? And I can also help you test on it from ConnMan side. Nov 03 07:33:05 It isn't ready 100% since some of the networking information is not reported Nov 03 07:33:15 but for running DHCP it should be almost enough I think Nov 03 07:33:21 see doc/dataconnectionmanager-api.txt Nov 03 07:33:55 denkenz, cool Nov 03 07:34:47 Thanks Nov 03 08:43:06 morning Nov 03 16:57:26 padovan: Fix up that patch and resend Nov 03 16:57:32 padovan: I'm about to start hacking on it Nov 03 16:57:59 denkenz: I applied the fix. Resending now. Nov 03 17:07:41 denkenz: sent. Nov 03 17:08:22 Cool Nov 03 17:29:52 holtmann: We still need to figure out what to do with our magic Operator scanning Nov 03 17:30:18 holtmann: I suggest we turn this off and add ScanOperators method Nov 03 17:31:36 Such a nice feature in theory, such crappy hardware in practice :) Nov 03 17:43:06 denkenz: I made a mistake, the zhenhua changes are not in the patch =( Nov 03 17:43:14 resending again Nov 03 17:45:24 no worries Nov 03 17:46:17 re-sent! :-) Nov 03 18:03:00 sweet Nov 03 18:05:08 Seems to work quite nicely so far Nov 03 18:05:54 denkenz: are you talking about netreg driver? Nov 03 18:05:58 yeah Nov 03 18:07:00 great :) Nov 03 18:29:32 denkenz: we wanna start the audio stuff for HFP. I need some advices on how to do that. Nov 03 18:30:11 Heh, Zhenhua was going to work on that after he finishes multicall too Nov 03 18:30:18 But really the problem is BlueZ Nov 03 18:30:32 The audio plugin is just not flexible enough right now Nov 03 18:30:49 jhe: Around? Nov 03 18:31:34 what do we need to do into BlueZ? Nov 03 18:31:50 BlueZ handles the SCO socket Nov 03 18:32:13 This is something we do not want to do in oFono, since BlueZ already has integration with pulse/gstreamer/alsa Nov 03 18:32:45 Problem is the management of the sco socket sort of assumes you're running inside BlueZ Nov 03 18:33:50 So what we need to do is to create another interface/entity that handles the HFP connections inside BlueZ Nov 03 18:34:00 Sets up the SCO audio stuff Nov 03 18:34:18 Then uses socket passing / DBus socket passing to give oFono the rfcomm socket Nov 03 18:36:23 will the setting up of the SCo audio stuff be into oFono? Nov 03 18:36:45 I don't think so Nov 03 18:36:54 Not at first anyway Nov 03 18:38:06 oFono really only cares about the rfcomm socket. There might be some cases with in-band rings that we need to take care of Nov 03 18:38:15 But generally the audio handling is up to BlueZ Nov 03 18:39:31 So, what part will be under oFono? Nov 03 18:39:52 Same as it is now, voicecalls and netreg Nov 03 18:40:02 Basically everything on the rfcomm socket is oFono Nov 03 18:40:13 With the exception of bind/listen and connect Nov 03 18:44:50 denkenz: who will associate the SCo connection with the SLC? Nov 03 18:45:06 The kernel? Nov 03 18:45:48 Not sure what you're asking :) Nov 03 18:45:54 denkenz: yes Nov 03 18:46:10 jhe: Have you and holtmann discussed ofono hfp / bluez integration at all? Nov 03 18:46:17 denkenz: not really Nov 03 18:46:44 denkenz: he has just mentioned that I should talk about it with you (hence the original idea that I should have come to portland a month ago or so) Nov 03 18:47:06 jhe: Yeah, that was a big bummer for me Nov 03 18:47:23 jhe: It is easier to do these discussions face to face Nov 03 18:47:27 agreed Nov 03 18:47:40 jhe: You have an idea of what we're trying to do? Nov 03 18:48:24 just reading your recent discussion with padovan Nov 03 18:48:47 so you want to hand over the RFCOMM socket from bluetoothd to ofono but keep the control of SCO on the bluetoothd side? Nov 03 18:49:02 That is my idea right now Nov 03 18:49:09 i.e. basically get rid of the AT parser in headset.c Nov 03 18:49:20 Since we don't want to move all the sco handling into oFono Nov 03 18:49:25 what about the telephony driver concept in bluetoothd Nov 03 18:49:38 Ok, first lets re-sync Nov 03 18:49:43 This is not HFP AG implementation Nov 03 18:49:50 This is HFP client implementation Nov 03 18:49:57 i.e Handsfree role Nov 03 18:50:06 correct Nov 03 18:50:09 ok Nov 03 18:50:20 so then audio/headset.c and audio/telephony-*.c stay as they are now Nov 03 18:50:35 Yes, correct Nov 03 18:50:39 but audio/gateway.c goes away Nov 03 18:51:02 Well, we have to see Nov 03 18:51:09 well, at least part if it Nov 03 18:51:10 As you mentioned previously there are VoIP only devices Nov 03 18:51:18 right Nov 03 18:51:26 So some _really_ minimal part should remain in BlueZ for those Nov 03 18:51:42 But for proper phones, we want this in oFono Nov 03 18:51:52 since we handle multi call, multiparty, waiting, hold, etc Nov 03 18:52:07 yep Nov 03 18:52:53 so I guess we need to define some sort of interface between bluetoothd and ofono Nov 03 18:53:03 yep Nov 03 18:53:22 Ideally DBus descriptor passing should be used Nov 03 18:53:30 right Nov 03 18:53:33 But if we're not there yet, then simple unix socket will do Nov 03 18:53:55 well, you can already use dbus 1.3 versions for the fd passing Nov 03 18:54:17 do you have some preliminary draft or ideas for the new interface? Nov 03 18:54:55 The interface should be basically HeadsetGateway with everything except Connect and Disconnect taken out Nov 03 18:54:55 on the bluetoothd side would it be an extension of the existing org.bluez.Gateway interface or a completely new one? Nov 03 18:55:11 so how do you trigger a connect or disconnect? Nov 03 18:55:28 jhe: I have none. I Need you, guys, to help me on that. Nov 03 18:55:38 oh sorry, those would stay Nov 03 18:55:41 So something like oFonoGateway::Connect oFonoGateway::Disconnect and oFonoGateway::Connected Nov 03 18:56:13 hmm, where would those be? And why are you using :: instead of .? Not a D-Bus interface? Nov 03 18:56:28 Sorry, C++ member notation :) Nov 03 18:56:39 replace it by . Nov 03 18:56:42 yeah, I got that, but we're still talking about D-Bus Nov 03 18:57:14 you're right, oFonoGateway.Disconnect/Connect Nov 03 18:57:31 ok, so the oFonoGateway interface would be on the bluetoothd device object? Nov 03 18:57:40 yes Nov 03 18:57:47 unless there's a better way Nov 03 18:58:16 should we really have oFono in the name? I mean, shouldn't this be a generic interface reusable by other telephony stacks? Nov 03 18:58:28 fine with me Nov 03 18:59:30 ok, so Gateway.Connect/Disconnect (and State property) stay for UI's to control and monitor the connection state. And for what oFono needs we'll have another one Nov 03 19:00:01 Potentially oFono can also listen for the Connected property Nov 03 19:00:14 Then initiate a unix/dbus socket descriptor exchange request Nov 03 19:00:29 do we have a config option so bluetoothd doesn't try to start establishing the SLC by itself but hands over the RFCOMM socket imediately when it's connected? Nov 03 19:00:39 right now Connected means that the SLC is established Nov 03 19:00:46 shouldn't ofono be sending the SLC init AT commands Nov 03 19:01:07 So oFono does send the initial BRSF if that is what you mean Nov 03 19:01:13 yeah Nov 03 19:01:22 So yes, we're abusing the term 'connected' here Nov 03 19:01:48 What I mean is that rfcomm connection exists Nov 03 19:01:53 I think we may need a config switch for this Nov 03 19:02:17 not following, what will the config switch do? Nov 03 19:02:31 or then, we keep the Gateway interface as is and have a new "connected" on the second interface (that's intended for ofono) Nov 03 19:02:49 the idea was that the switch would control the meaning of "connected" on the Gateway interface Nov 03 19:02:56 (i.e. complete SLC or just RFCOMM) Nov 03 19:03:06 so my current thought was to have two separate interfaces Nov 03 19:03:28 Not sure how SDP records / device compatibility would work with that though Nov 03 19:04:12 to avoid a too static setup and a config file option we could have ofono register itself to bluetoothd so bluetoothd knows that its no longer responsible for the SLC but should stop after getting the RFCOMM channel Nov 03 19:04:25 something similar to the current agent concept Nov 03 19:04:52 Question is, what if the user wants to connect a voip only device? Nov 03 19:05:06 wouldn't 2 interfaces work better? Nov 03 19:05:15 then there's nothing registered and bluetoothd works as it does now Nov 03 19:05:34 But oFono might still be around... Nov 03 19:05:39 right Nov 03 19:05:45 you'd still have the two interfaces Nov 03 19:05:55 the second one would be used by ofono to tell bluetoothd about its presense Nov 03 19:06:34 so I'm bit confused, what if I'm using two devices, a voip only one and a real phone Nov 03 19:06:41 hmm, otoh we do already have the well-known D-Bus names, so explicit registration may not be necessary Nov 03 19:06:47 If one of the devices auto connects, what to do? Nov 03 19:07:27 I don't know Nov 03 19:07:35 how do you even detect a voip-only device? Nov 03 19:08:04 I believe you said it is a next rev of HFP profile, perhaps there will be a capabilities / SDP record? Nov 03 19:08:51 there's VoIP support coming yes, but don't remember there being a way of saying that you're VoIP-only Nov 03 19:09:12 I really need to get my hands on that spec :) Nov 03 19:09:20 there's e.g. a new number-type specified (to indicate a VoIP address) and then a few other things Nov 03 19:09:56 Maybe we just handle it in oFono and forget about this two gateway approach Nov 03 19:10:10 Lets not fret about this for now Nov 03 19:11:10 So do we need any other attributes / methods on the interface? Nov 03 19:11:22 Perhaps the unix address if we're not using dbus fd passing? Nov 03 19:12:34 I think we could assume fd passing support in dbus from the get-go Nov 03 19:12:59 to make things a bit simpler and not have to maintain two interface specs or have a too complicated interface Nov 03 19:13:06 that works for me Nov 03 19:14:24 padovan: So do you wanna attempt to bastardize what is in audio/gateway.c? Nov 03 19:14:40 ok, so I think the current logic in gateway.c could stay, but then either through a config option or ofono dynamically telling bluetoothd, the functionality could be disabled and bluetoothd would stop the connection establishment after getting the RFCOMM socket (at which point we need a way to move it over to ofono) Nov 03 19:14:47 denkenz: yes Nov 03 19:15:19 jhe: Yes, so essentially a duplication of gateway.c with some stuff removed Nov 03 19:15:51 sorry for not contribute with the discussion, but I don't have too much experience on that. ;) Nov 03 19:16:06 jhe: Will we physically register 2 SDP records? Nov 03 19:16:26 jhe: Or just remove one interface and register another when oFono is detected? Nov 03 19:16:26 denkenz: no, I don't think so Nov 03 19:16:59 denkenz: I guess we could even keep the old interface but just have anything except Connect or Disconnect return an error Nov 03 19:17:26 jhe: Yep, that could work as well Nov 03 19:17:50 jhe: Though not terribly intuitive to the user Nov 03 19:18:02 true Nov 03 19:18:39 Does BlueZ have an Interfaces property on a device? Nov 03 19:18:55 I think so Nov 03 19:18:58 something that might inform the application that a set of interfaces has changed? Nov 03 19:18:59 not 100% sure though Nov 03 19:19:03 * jhe checks Nov 03 19:19:28 nope :/ Nov 03 19:19:36 we just have UUIDs through which profiles can be detected Nov 03 19:19:47 darn Nov 03 19:19:47 and then of course introspection data, but there's no signal for when it changes Nov 03 19:20:45 configure option? Nov 03 19:21:12 Or perhaps make the two interfaces share the accept() socket and have a default? Nov 03 19:22:09 e.g. newconnection -> if (ofonorunning) give socket to Gateway, else give socket to HeadsetGateway Nov 03 19:22:38 right Nov 03 19:22:44 something like that Nov 03 19:23:10 so the "it" that ofono is registering is essentially an external AT command engine Nov 03 19:23:23 yep Nov 03 19:23:47 we could call the interface then something along those lines Nov 03 19:24:22 We do want to give the user some idea that this is for HFP Nov 03 19:24:38 As we could use Proxy for a generic 'at command engine' Nov 03 19:24:54 that's also useful for dun support both over bluetooth and usb Nov 03 19:24:56 right Nov 03 19:25:12 tmzt: That's what Serial plugin is for Nov 03 19:25:20 HFP is different Nov 03 19:25:58 ok Nov 03 19:26:18 denkenz: the registration should either be on the Manager or Adapter path since it's something that's not specific to any single device object Nov 03 19:26:50 jhe: registration of the interface? Nov 03 19:27:11 jhe: or oFono's existence? Nov 03 19:27:12 if ofono would call something like org.bluez.Manager.RegisterHFPATEngine() Nov 03 19:27:34 ah nod, fine with me Nov 03 19:29:09 so it could be Manager.RegisterHFPATEngine(object path) and the object at that path on the ofono side would be expected to implement a org.bluez.HFPATEngine interface Nov 03 19:29:36 which could e.g. have NewHFPConnection(object path, filedescriptor fd) method Nov 03 19:30:04 (in the later method the path parameter would be that of the remote device object on the bluetootd side) Nov 03 19:30:29 We probably want to have the RegisterHFPATEngine on the Device object Nov 03 19:30:40 Since in oFono we'd probably have 1 modem / bluez device Nov 03 19:30:48 so in that case it *is* per-device and not a global thingie Nov 03 19:30:53 right Nov 03 19:31:15 sorry, not device Nov 03 19:31:17 Adapter Nov 03 19:31:30 yeah, that'd be fine Nov 03 19:31:31 I presume you can't have multiple HFP connections on 1 adapter Nov 03 19:31:43 well, you can Nov 03 19:31:53 and I think there already are HF devices that can connect to multiple AG's Nov 03 19:32:14 What about SCO handling, I thought we still had restriction of 1 / adapter? Nov 03 19:32:28 yeah, that gets tricky Nov 03 19:32:43 but the AT signalling can be done Nov 03 19:33:05 Yeah, so that impacts our design a bit Nov 03 19:33:21 If we have 1 HFP / adapter or 1 HFP / device Nov 03 19:33:32 oFono doesn't really care Nov 03 19:33:53 it'd be 1 HFP/device but the interface for ofono registration can be on the adapter path Nov 03 19:34:09 ofono would just get multiple NewHFPConnection calls if many AG's are connected Nov 03 19:34:21 Yep works for me Nov 03 19:35:18 I'm not sure if we need an explicit Disconnect method either from bluetoothd to ofono or vice-versa since either process can call shutdown() on the fd and the other process would then get a POLLHUP on it Nov 03 19:36:14 True Nov 03 19:36:40 Flip a coin on that one, we have to handle EINVAL/POLLHUP anyway Nov 03 19:36:51 yep Nov 03 19:37:39 the SCO handling requires some thought though Nov 03 19:38:01 do we want to support SCO initiaton or are we always just acceptors Nov 03 19:38:15 The profile allows both Nov 03 19:38:25 iirc there's a white paper that says that even though the spec allows the HF-device to be initiator it's better to always let the AG do it Nov 03 19:38:56 I'm fine with that, but you auto-initiate the SCO when audio is written to the device Nov 03 19:39:27 I don't think it is necessary for oFono / UI to control this manually Nov 03 19:39:56 what do you mean by "the device"? Nov 03 19:40:10 the created alsa / pulse device Nov 03 19:41:25 hmm, right. we don't have such a feature at the moment at least for alsa. the audio connection is created implicitly when the alsa plugin is initialized. not sure how pulse works though. Nov 03 19:42:13 anyway, we should be able to leave out SCO initialization from the API spec for now Nov 03 19:42:23 yeah Nov 03 19:43:00 do we need a way for bluetoothd to tell ofono that SCO is connected? Is that useful for anything? Nov 03 19:43:22 In-band ring tones Nov 03 19:43:29 But those are really tricky Nov 03 19:43:29 right! Nov 03 19:44:31 ofono in itself should need to do anything special when it receives RING besides pass it on to some entity that can synthesize a local ring tone Nov 03 19:44:38 s/should/shouldn't/ Nov 03 19:44:46 Correct Nov 03 19:46:08 a broadcast D-Bus signal would probably be the easiest approach Nov 03 19:46:42 yeah, that'll do, except there's some magic inside audio plugin that determines what the SCO connection is destined to Nov 03 19:46:58 Not sure if it has any interaction with this Nov 03 19:47:32 We might need a 'hint' method to BlueZ to tell it what has preference Nov 03 19:48:30 yep Nov 03 19:52:54 in the case that bluetoothd is also connected to a remote A2DP Audio Source it'd be interested of knowing that there's either an incoming or outgoing call so that it can request a suspend on the A2DP stream Nov 03 19:53:18 but maybe there already are ofono signals for that? Nov 03 19:53:57 There is Nov 03 19:54:14 You will get a call object in the incoming / waiting state Nov 03 19:54:21 ok Nov 03 19:54:39 Not sure if bluetoothd should do this or the UI Nov 03 19:55:16 it could become a latency issue Nov 03 19:55:40 True, but oFono can have 5 bazillion modems Nov 03 19:55:57 right Nov 03 19:56:26 That policy decision might be up to the UI, but both are feasible really Nov 03 19:56:43 usually when both profiles are connected to the same remote device the remove device takes care of suspending A2DP but when we're connected to two different devices we need to tell the A2DP Source to suspend Nov 03 19:58:10 this could (and maybe should) be handles through an audio server, like pulse Nov 03 19:58:29 Also a possibility Nov 03 19:58:29 at least in maemo that knows the global call states and will togle the different audio stream statuses accordingly Nov 03 19:58:59 holtmann, jhe, padovan: First cut of the API http://pastebin.ca/1655300 Nov 03 20:01:02 denkenz: the HandsfreeAgent interface looks ok, but I don't think we'll be adding another method to the Adapter interface Nov 03 20:01:31 instead the audio plugin should register its own adapter driver which would add a new interface to each adapter object (and this interface would have the registration method for ofono) Nov 03 20:01:58 Sounds good Nov 03 20:02:25 any ideas on the naming? Nov 03 20:04:51 it's a bit tricky Nov 03 20:05:31 we've defined interfaces for the different roles for the device objects. and their definitions are modeled based actions you can do with remote devices. Nov 03 20:06:23 yes, which led to much confusion at some point :) Nov 03 20:06:25 now we're talking about acting in the role ourselves and in that case the possible actions are different, yet the existing device object interface names don't in any way reflect that they're targetting remote devices and not the local one Nov 03 20:08:16 the situation isn't that bad really, just need to read the docs first Nov 03 20:09:18 we could name the new interface in a more foccused manner by just targetting it for the purpose of registering or unregistering an AT handler Nov 03 20:09:58 but I'm still failing to come up with any good name Nov 03 20:10:06 org.bluez.HandsfreeEngine? Nov 03 20:10:13 org.audio.HandsfreeRegistry Nov 03 20:10:22 maybe Nov 03 20:10:22 org.audio.HandsfreeManager Nov 03 20:10:35 HansfreeManager sounds at least better than Registry Nov 03 20:10:52 org.audio.HandsfreeAgentManager Nov 03 20:11:03 From those options I'd go for HandsfreeManager Nov 03 20:13:50 btw, will this be extended for Headset profile too? or are we just targetting HFP? Nov 03 20:14:19 Just HFP, we could potentially do HSP too Nov 03 20:14:31 http://pastebin.ca/1655332 Nov 03 20:14:54 I'm wondering whether ofono needs to know whick profile is connected (if it does then a third parameter may be needed to the NewConnection method) Nov 03 20:15:22 So oFono can probably easily handle HSP Nov 03 20:15:28 Question is, do we want to Nov 03 20:15:48 ye Nov 03 20:15:50 yep Nov 03 20:16:11 for symmetry I guess it'd be good to have a UnregisterHandsfreeAgent method too Nov 03 20:17:43 in the case that there's no registered external agent the current Gateway interface would still be useful, right? Nov 03 20:18:00 in that case we should at least not be modifying it Nov 03 20:18:15 I think for now we can safely leave that one as is Nov 03 20:18:25 I've a pretty low opinion of its implementation though Nov 03 20:18:27 either it should be completely removed from the device object or then (as I mentioned) part of the methods should return errors when there's an external agent Nov 03 20:18:52 Ideally we should just remove it and let oFono handle it Nov 03 20:19:02 The only possible reason might be VoIP only devices Nov 03 20:19:02 denkenz: oh, same here (regarding its implementation). It basicly didn't go through much more than a coding style and compile-check review. Nov 03 20:21:23 denkenz: I think I'm off for tonight. It'd be good if you can get some comment on holtmann for this, particularly the HandsfreeManager interface naming. Nov 03 20:21:56 jhe: yep, I'll post the final version that I have with UnregisterHandsfreeAgent Nov 03 20:22:05 Maybe I'll catch him later tonight Nov 03 20:22:17 oh, one more thing, if we do keep org.bluez.Gateway around the semantics of its State property shouldn't change depending on there being an external agent or not Nov 03 20:22:30 which means that bluetoothd should be able to know when the SLC init sequence is complete Nov 03 20:22:56 HeadsetGateway you mean? Nov 03 20:23:12 is that what it's called? I haven't looked at the API doc for awhile :P Nov 03 20:23:16 yeah Nov 03 20:23:22 Its called HeadsetGateway :P Nov 03 20:23:39 yeah, that's what I mean :) Nov 03 20:23:52 Yeah, I think HeadsetGateway can just be left as is Nov 03 20:24:09 We will attempt to splice in the new interface Nov 03 20:24:14 and see how far we get :) Nov 03 20:24:55 I'm not sure if the new Gateway interface is really needed Nov 03 20:25:31 it'd just make life more difficult for something like a pulseaudio policy module which tries to make audio routing decisions based on what inputs & outputs are available Nov 03 20:26:00 since it'd potentially need to listen for signals from both the old and the new interface Nov 03 20:26:01 So lets just get rid of HeadsetGateway Nov 03 20:26:54 Make it handle HFP initially Nov 03 20:27:02 I still wouldn't call the new interface just Gateway Nov 03 20:27:06 Then we might even make it handle HSP Nov 03 20:27:11 it'd need to be HandsfreeGateway in this case Nov 03 20:27:24 In which case the job for Pulse audio is really simple Nov 03 20:27:39 otoh, that'd be asymetcrical to the Headset interface we have for devices implementing th eopposite role Nov 03 20:28:18 anyway, enough brainstorming for now Nov 03 20:28:21 talk to ya later Nov 03 20:28:33 yep, good night :) Nov 04 00:35:15 denkenz: err.. i am reading a so long discussion between u and jhe now. Nov 04 00:35:55 denkenz: actually, i have already has a rough bluez patch that works for HFP. The name is oFonoHFP. Nov 04 00:36:07 denkenz: why not polish it? Nov 04 00:43:25 by all means Nov 04 00:47:34 ? Nov 04 00:47:46 post it, polish it Nov 04 00:47:58 now i have a workable version on my hands Nov 04 00:47:58 padovan is already wanting to work on the BlueZ side Nov 04 00:48:17 no probs. post it to bluez mailing list? Nov 04 00:48:32 or ofono mailing list... Nov 04 00:48:45 BlueZ, but you might want to implement the proposed API Nov 04 00:49:24 right. i need time to read you all discussion. are we separte it with gateway.c or still in gateway.c Nov 04 00:50:18 not sure, I think we decided to get rid of the current interface Nov 04 00:51:26 which API is the latest version? http://pastebin.ca/1655332? Nov 04 00:52:17 holtmann, jhe, padovan, zhenhua: Latest hfp-api.txt here http://pastebin.ca/1655787 Nov 04 00:54:11 so it's totally different with current bluez. Nov 04 00:55:59 why the object path of HandsfreeAgent is freely definable? I think it should under dev_XX_XX_XX_XX_XX_XX Nov 04 00:56:18 no Nov 04 00:56:37 It is not running on the BlueZ side, but on the oFono side Nov 04 00:56:43 so in fact it is freely definable Nov 04 00:57:43 i see Nov 04 01:02:19 i have tried CHUP on multiparty call. and it did hangup all calls in the mpty call Nov 04 01:02:33 told ya :) Nov 04 01:03:17 but i still have small trouble in release specific call Nov 04 01:03:44 if AG doesn't support CHLD=1x, we only could use CHUP to release current active call Nov 04 01:04:12 I told you this before, if CHLD=1X isn't supported, don't even bother supporting mpty Nov 04 01:04:14 if the call is not active call, we need to wake up it? Nov 04 01:04:33 So join would just simply return an error Nov 04 01:05:05 no, i am not talking mpty call. but multiple calls Nov 04 01:05:17 in multiples call, only one call is active Nov 04 01:05:29 but if we want to manager_hangupall Nov 04 01:05:40 we need release them one by one Nov 04 01:06:05 then we have problems here. Nov 04 01:06:20 we need to active each call->id and then hang up it. Nov 04 01:06:47 What device doesn't support CHLD 1X? Nov 04 01:07:00 LG phone, many phones. Nov 04 01:07:08 only support CHLD=0, 1 and 2 Nov 04 01:09:40 I have to think about it Nov 04 01:09:51 I think we would need to swap first Nov 04 01:10:22 The alternative would be to implement the hangup_all logic in the driver Nov 04 01:11:44 yeah, i have no good idea now Nov 04 01:11:56 maybe the latter is better choice Nov 04 01:12:11 we could allow driver to hangup each one. not but queue Nov 04 01:12:18 s/but/by Nov 04 01:12:36 Yes, that is sounding like the best choice Nov 04 01:12:48 Most modems +CHUP would result in hangup_all anyway Nov 04 01:14:17 okay. but you see, it's not true in HFP. +CHUP only release current one Nov 04 01:14:42 yes yes, I know, hfp is different ;) Nov 04 01:14:56 and if we have 1 mpty call and 1 waiting call. +CHUP will release mpty call only Nov 04 01:15:14 actually that is the behavior we want Nov 04 01:15:52 yes. Nov 04 01:15:55 HangupAll should probably skip waiting calls Nov 04 01:16:41 why? I need test to know. Nov 04 01:17:17 anyway, it's complex in multicall and mpty call. different phone also has small difference. Nov 04 01:17:30 Entering END - Releases the subscriber from all calls (except a possible waiting call). Nov 04 01:17:38 This is from 22.030 Nov 04 01:17:47 HangupAll was really meant for that one... Nov 04 01:18:42 oh? then atmodem also need to change. Nov 04 01:19:21 HangupAll is done in the core right now Nov 04 01:20:26 if (vc->driver->hangup) Nov 04 01:20:32 vc->driver->hangup Nov 04 01:20:45 that's in manager_hangup_all Nov 04 01:20:53 ? Nov 04 01:21:04 ops, i am in my branch. sorry. Nov 04 01:21:15 not in my oFono it isn't ;) Nov 04 01:22:01 We still have the issue of having to swap then hangup to release a held call Nov 04 01:22:21 Which is a big crappy thing to do Nov 04 01:22:37 The driver can probably figure that out though Nov 04 01:22:48 yeah. if in a multi calls, user want to release a specific call Nov 04 01:22:57 which is not active Nov 04 01:23:07 we need to swap it to be active first Nov 04 01:23:10 yeah, that's terrible Nov 04 01:23:14 swap -> hangup -> swap Nov 04 01:23:55 not only hangupall, he can only release one call through voicecall_hangup Nov 04 01:24:04 the same terrible Nov 04 01:24:52 Shall we handle hangup_all logic in driver or in core? Nov 04 01:25:17 actually we don't need swap / hangup / swap Nov 04 01:25:44 we can use chld0 if we don't have a waiting call Nov 04 01:25:44 how? Nov 04 01:26:10 nop Nov 04 01:26:18 what if you have two held calls Nov 04 01:26:26 and user only want to release one held Nov 04 01:26:33 not possible Nov 04 01:26:34 through voicecall_hangup Nov 04 01:26:36 1 held 1 active Nov 04 01:26:46 1 waiting Nov 04 01:26:48 That's it Nov 04 01:26:51 okay Nov 04 01:27:21 CHLD=0 will also set UDUB for the waiting call Nov 04 01:27:22 right? Nov 04 01:27:39 yes, the waiting call case is crappy Nov 04 01:27:45 heh Nov 04 01:29:22 i can send u current hfp voicecall.c if you want. Nov 04 01:29:54 most thing is ready. but still problematic for such release Nov 04 01:30:34 send when ready Nov 04 01:30:59 okay. Nov 04 01:48:34 denkenz: still there? Nov 04 02:29:28 denkenz, ping Nov 04 02:29:37 heh, I'm popular today Nov 04 02:31:02 denkenz: i plan to send four patches to mailing list. is that ok? Nov 04 02:31:17 zhenhua: The three simple ones I already applied Nov 04 02:31:21 denkenz: i didn't see my three patches in upstream Nov 04 02:31:39 zhenhua:Yeah I haven't pushed yet, too many discussions and not enough coding today Nov 04 02:31:49 zhenhua: Just resent the fourth one Nov 04 02:31:55 martin_office: pong Nov 04 02:32:08 denkenz: so i only send the 4th? other guys cannot apply it Nov 04 02:32:50 Then resend all 4 and I will reapply them all Nov 04 02:33:03 denkenz: fine Nov 04 02:33:13 I still need to review the fourth one anyway Nov 04 02:33:16 denkenz: thank you Nov 04 02:33:20 So you might need to redo it anyway Nov 04 02:33:29 yeah, i know Nov 04 02:34:03 denkenz, I met some issues using mbm. I have modified the /etc/ofono/modem.conf, and can saw the mbm modem. but I can not enable it. Nov 04 02:34:28 martin_office: mbm plugin is meant to be used with udev Nov 04 02:35:04 make sure plugins/udev is enabled Nov 04 02:35:13 denkenz, So I need not to set configure file? Nov 04 02:35:35 No, but you do need to setup your udev rules. See plugins/ofono.rules Nov 04 02:35:57 Once done your mbm should work by magic Nov 04 02:36:45 denkenz, seems udev.c is not got compiled. ;-) Nov 04 02:37:52 denkenz, but it should be compiled if you do not set --disable-udev. Nov 04 02:38:17 denkenz, and I did not set it when ./configure. Nov 04 02:38:35 denkenz, I will try to re-compiled it. Nov 04 02:39:08 fairly new udev development headers are neede Nov 04 02:39:09 +d Nov 04 02:39:40 denkenz, tell me the udev-devel version. ;-) Nov 04 02:40:07 denkenz, I am from dist team and quite familiar with that. ;-) Nov 04 02:43:02 141 Nov 04 02:43:12 denkenz, Thanks. Nov 04 02:43:54 denkenz: still there? Nov 04 02:44:46 i am troubling guy.:) Nov 04 02:45:04 another 5 minutes or so Nov 04 02:45:35 ok. wait u 5mins Nov 04 02:46:10 No, here for another 5 minutes or so ;) Nov 04 02:46:39 will padovan do the bluez part? Nov 04 02:46:59 i don't want having duplicate work Nov 04 02:47:02 no idea, he said he wants to Nov 04 02:47:19 so let me know if you have idea then Nov 04 02:48:16 i need to know whether i need focus on bluez or do other works in ofono. Nov 04 02:48:43 Plenty of work either way Nov 04 02:49:42 I also need the call volume atom driver at some point Nov 04 02:51:10 i have a copy of call volume on hand Nov 04 02:52:03 so clean it up, make sure it works and submit for review Nov 04 02:52:30 yeah. i am glad to do it. :) Nov 04 02:53:06 the problem for call volume is that Nov 04 02:53:17 it doesn't have AT to query current volume in AG... Nov 04 02:53:44 That's because the roles are reversed Nov 04 02:53:48 and suppose we need record current AG volume in config file. Nov 04 02:53:55 The volume is actually at the headset Nov 04 02:54:47 so less we know the volume, we should not send +VGS to adjust to volume? Nov 04 02:55:09 no, we just simply assume we know the volume Nov 04 02:55:20 either from pulse or alsa or elsewhere Nov 04 02:55:29 The interface can then be used to notify the AG Nov 04 02:55:39 Bit backward Nov 04 02:55:56 ok Nov 04 02:56:17 hardcode the volume to something for now Nov 04 02:56:22 the initial one that is Nov 04 02:56:52 what is the initial value? 50%? Nov 04 02:57:14 fine enough for now, we'll need to query pulse/alsa eventually Nov 04 02:58:02 then i have no questions. ;) **** ENDING LOGGING AT Wed Nov 04 02:59:57 2009