**** BEGIN LOGGING AT Thu Jan 28 02:59:56 2010
Jan 28 03:11:02 <denkenz> zhenhua: That one is next, the STE and HFP patches took most of the day
Jan 28 03:12:40 <zhenhua> okay
Jan 28 03:14:39 <zhenhua> denkenz: for basic command, DUN will add more basic command like S0, S10, so I will add interface to add_basic_command for upper layer.
Jan 28 03:16:17 <denkenz> zhenhua: sounds good
Jan 28 03:16:37 <denkenz> zhenhua: The basic structure is actually OK, but the buffering needs serious redesign
Jan 28 03:17:04 <zhenhua> denkenz: yeah, i know that. so looks forward for your comments then.
Jan 28 03:17:49 <zhenhua> denkenz: and i wanna looking into qtopia code to learn sth from there.
Jan 28 06:30:08 <holtmann> zhenhua: I want the HFP plugin to be compiled.
Jan 28 06:30:51 <zhenhua> holtmann: my mistake, HFP plugin could be compiled both dbus 1.2 and 1.3 now.
Jan 28 06:31:14 <zhenhua> holtmann: i have double verified that.
Jan 28 06:32:19 <zhenhua> holtmann: but i cannot apply padovan's bluez part patch with latest master branch.
Jan 28 06:32:35 <holtmann> I haven't looked at the BlueZ changes.
Jan 28 07:19:05 <zgli> :holtmann,  with ofonod -d -n  can't see the debug log and only -n works now. 
Jan 28 07:19:23 <zgli> something wrong with it
Jan 28 08:04:23 <holtmann> ofonod -n -d '*' now.
Jan 28 08:40:15 <zgli> :you fixed it now?  when I type -n -d, it show Missing argument for -d. 
Jan 28 14:15:34 <padovan> denkenz: ping
Jan 28 15:49:11 <denkenz> padovan: pong
Jan 28 15:58:03 <padovan> denkenz: we need a way to show what's modem is hfp{0,1,..}. I mean, we need to show the bluetooth device name or the object path in bluez.
Jan 28 15:58:23 <padovan> but seems that org.ofono.Modem doesn't have a field for that.
Jan 28 15:58:43 <denkenz> oFono modem path is configurable
Jan 28 15:59:15 <denkenz> So you can put in the bdaddr into the path
Jan 28 16:00:06 <padovan> Sounds good.
Jan 28 16:14:31 <jprvita> denkenz: is it possible for a device to have more than one modem?
Jan 28 16:16:00 <jprvita> denkenz: anyway, it seems a little overkill IMO to add the BTADDR to the object path. wouldn't be better to expose the BDADDR or bluez's object path for the device through a property?
Jan 28 16:16:53 <jprvita> this way we don't have a bigger object path
Jan 28 16:30:32 <denkenz> jprvita: So oFono needs a unique ID for a modem anyway
Jan 28 16:30:41 <denkenz> jprvita: If one is not provided it generates one based on driver name
Jan 28 16:31:04 <denkenz> jprvita: Using properties can be done, but up to this point we haven't needed it
Jan 28 16:31:40 <denkenz> jprvita: Why do you need to correlate this information anyway?
Jan 28 16:32:24 <jprvita> denkenz: no specific need right now, but I guess it would be good for the user to be able to specify which modem he's connecting to
Jan 28 16:33:02 <denkenz> Theoretically one can do this through BlueZ UI
Jan 28 16:33:10 <jprvita> when testing I realized that there is no way to know which modem is connected to each phone
Jan 28 16:33:56 <jprvita> is this info avaiable in bluez? which device in bluez is bound to which modem in ofono?
Jan 28 16:34:21 <denkenz> Well, when you hit connect a modem will get powered up ... :)
Jan 28 16:34:43 <denkenz> But for proper correlation you need to store not only device address but also the adapter
Jan 28 16:34:55 <denkenz> Since two adapters can pair the same remote device
Jan 28 16:35:24 <padovan> denkenz: can we add a property for that?
Jan 28 16:35:42 <denkenz> You can set the property on the modem already
Jan 28 16:35:53 <denkenz> But we don't expose it over DBus
Jan 28 16:36:15 <jprvita> yep, that's true..  I'm just not sure if the adapter would matter much
Jan 28 16:36:33 <jprvita> I mean, one can have 2 different adapters paired with the same device
Jan 28 16:36:56 <denkenz> Sure, but there would be two different modems 
Jan 28 16:36:59 <padovan> jprvita: denkenz: we can just eliminate duplicated devices.
Jan 28 16:37:00 <jprvita> and use the adapters in different situations
Jan 28 16:37:03 <denkenz> One on adapter 1, the other on adapter 2
Jan 28 16:37:18 <jprvita> ok, i see, didn't know that
Jan 28 16:37:49 <denkenz> padovan: Potentially we can, but that is not necessarily a good idea
Jan 28 16:37:58 <denkenz> we need holtmann / jhe to comment on that
Jan 28 16:38:22 <holtmann> On what?
Jan 28 16:39:05 <denkenz> see backscroll, but basically there's an oFono modem per adapter/device combination
Jan 28 16:39:21 <denkenz> On systems with multiple adapters, the same device might be paired to multiple adapters
Jan 28 16:40:06 <denkenz> jprvita wants to track what bluez device corresponds to what oFono modem
Jan 28 16:40:40 <holtmann> Sure. Just use a combination of <adp_addr><dev_addr> and you have a unique path.
Jan 28 16:41:16 <denkenz> That was my suggestion as well, but for UIs it might be easier to expose a proper DBus property of some sort
Jan 28 16:41:39 <holtmann> Who cares?
Jan 28 16:42:26 <holtmann> jprvita: The BDADDR has to be in the modem object path. That needs to be unique and persistent.
Jan 28 16:42:54 <jprvita> ok, that works
Jan 28 16:43:09 <denkenz> I suggest we simply use the bluez path as the path of the oFono modem
Jan 28 16:43:27 <denkenz> That should keep everyone happy
Jan 28 16:43:39 <holtmann> We can't use the whole path. It is has a PID random element in it.
Jan 28 16:43:50 <jprvita> including the '/org/bluez' part?
Jan 28 16:43:59 <denkenz> So? if bluetoothd goes away we have to shut down the device anyway
Jan 28 16:44:32 <holtmann> See my comment. Won't work because of the PID in it. As I said, the modem object path has to be unique and persistent. At least the last part of it.
Jan 28 16:45:06 <denkenz> Question is, do adapters even preserve uniqueness part?
Jan 28 16:45:11 <holtmann> denkenz: Path matching to match correlations between daemons is a bad idea.
Jan 28 16:45:26 <holtmann> In BlueZ they don't.
Jan 28 16:45:36 <holtmann> But we do export the BD_ADDR of the adatper.
Jan 28 16:45:54 <denkenz> Ok, so we store adapter bdaddr and device bdaddr
Jan 28 16:46:06 <padovan> denkenz: if bluetoothd goes away ofono already shuts down the modem.
Jan 28 16:46:07 <denkenz> That is the way to go
Jan 28 16:46:40 <holtmann> So why does anybody cares which Bluetooth object it is when talking to oFono?
Jan 28 16:47:07 <padovan> holtmann: because you wanna choose wich cell phone to use.
Jan 28 16:47:37 <holtmann> Can we just not include a Name property in the modem object path for that.
Jan 28 16:48:00 <holtmann> The UI should not jump between org.bluez and org.ofono anyway.
Jan 28 16:48:18 <padovan> That's fine too.
Jan 28 16:48:31 <denkenz> holtmann: What is this Name property? on the Modem Interface?
Jan 28 16:48:43 <jprvita> would be good if we could use the device's bt name for that
Jan 28 16:48:50 <holtmann> Just a string that gives you the UI friendly name.
Jan 28 16:49:16 <holtmann> If you need to choose between modems.
Jan 28 16:49:28 <holtmann> For non Bluetooth modes, I can fill these via udev.
Jan 28 16:49:43 <holtmann> And we can even add it to modem.conf.
Jan 28 16:49:53 <holtmann> Just a UI bling thingy.
Jan 28 16:50:54 <denkenz> We can do that certainly, but this has to be synced to bluez Alias
Jan 28 16:51:17 <denkenz> so I need to make this proper ofono API, with PropertyChanged emission, etc
Jan 28 16:51:25 <padovan> Will we add the bluetooth device name? This not a unique name.
Jan 28 16:52:19 <jprvita> padovan: the name will not be part of the object path, so doesnt need to be unique
Jan 28 16:53:50 <denkenz> padovan: Submit a patch for adapter/device bdaddr path naming
Jan 28 16:54:05 <denkenz> padovan: If that is not enough we add proper oFono property
Jan 28 16:55:51 <padovan> /hfp/hci0/dev_00_1F_DF_00_DD_EE is good enough?
Jan 28 16:56:55 <holtmann> padovan: Use /hfp/0011FF..._0011FF as path. No extra objects in between.
Jan 28 16:57:15 <holtmann> And the the Name use the BlueZ alias.
Jan 28 16:57:46 <padovan> Right.
Jan 28 16:57:59 <denkenz> holtmann: Do you want to make these properties generic?
Jan 28 16:58:13 <denkenz> holtmann: E.g. ofono_modem_set_dbus_property or something?
Jan 28 16:59:06 <holtmann> Don't need that right now.
Jan 28 16:59:58 <denkenz> holtmann: So just ofono_modem_set_name?
Jan 28 17:13:56 <holtmann> Sure.
Jan 28 17:15:13 <padovan> denkenz: I forgot to rebase my patches againt your last changes on hfp.c, sorry. I resent the patch.
Jan 28 17:18:56 <denkenz> padovan: Care to work on ofono_modem_set_name as well?
Jan 28 17:19:12 <denkenz> padovan: Default to null/empty in case it wasn't set
Jan 28 17:27:30 <padovan> denkenz: I'll work on that today and tomorrow, then I don't if I'll have time for that. Should not be hard. :)
Jan 28 18:37:41 <padovan> jhe: any idea why the link RFCOMM doesn't disconnect on the hfp patch? My ref/unref counts seems ok.
**** ENDING LOGGING AT Fri Jan 29 02:59:56 2010