**** BEGIN LOGGING AT Thu Feb 17 02:59:58 2011
Feb 17 03:00:04 <holtmann> zgli: No idea. What is the hs2230? Or give me the subject line of the patch.
Feb 17 03:00:47 <zgli> Enable hs 2330 MBM modem: 
Feb 17 03:00:56 <zgli> it's for udev part
Feb 17 03:03:42 <holtmann> What is the subject line of that patch?
Feb 17 03:04:38 <zgli> [PATCH] Enable hs 2330 MBM modem:    
Feb 17 03:04:49 <zgli> Do you need I send it again?
**** BEGIN LOGGING AT Thu Feb 17 07:32:20 2011
Feb 17 13:34:29 <tomaszgr> holtmann, denkenz: ping
Feb 17 15:36:36 <denkenz> tomaszgr: pong
Feb 17 15:41:06 <OlivierG> denkenz: i have some questions for you regarding gprs contexts management.... ;)
Feb 17 15:42:24 <OlivierG> My understanding is that if a context is deleted,  the next one will be created with an id based on gprs->last_context_id ...
Feb 17 15:43:18 <OlivierG> cf: gprs.c  add_context() with id_map_alloc_next
Feb 17 15:43:49 <tomaszgr> hi denkez, I am implementing +CEREG: UN support in AT modem, and got into some concerns about it. It is status for LTE network so we would have two statuses: one for 3G, one for LTE but the core has one
Feb 17 15:45:18 <tomaszgr> two solutions come to my mind, add second status in oFono gprs OR combine this two into one with some logic
Feb 17 15:45:40 <tomaszgr> any ideas which way to go?
Feb 17 15:48:08 <denkenz> OlivierG: could be, it has been a while
Feb 17 15:48:26 <OlivierG> ok ...i ll dig in the code ;)
Feb 17 15:49:06 <denkenz> tomaszgr: I suspect LTE will need its own atom
Feb 17 15:50:24 <denkenz> OlivierG: From what I remember the idmap tries to emulate the pid map from the kernel, so deleting a context and adding a new one will not get you the id of the deleted context
Feb 17 15:52:26 <OlivierG> As i m trying to completly implement the +CGDCONT, i m facing the problem where you can delete a specific context (eg: +CGDCONT=3) then, create a new one with the same cid (eg: +CGDCONT=3,"IP") ....
Feb 17 15:53:20 <denkenz> The context management inside oFono and CGDCONT don't really map
Feb 17 15:53:39 <denkenz> Which is why I don't really want to consider this problem right now
Feb 17 15:55:15 <OlivierG> I m not talking about the "modem side" but i m focused on the emulator side (for DUN)... i can understand that is not a high priority ;)
Feb 17 15:56:37 <denkenz> CGDCONT is not required by BT DUN
Feb 17 15:57:12 <denkenz> And in some respect I don't even want to expose the configured GPRS contexts to the emulator
Feb 17 15:57:29 <denkenz> So all of this might have to be just faked
Feb 17 15:57:41 <OlivierG> ok...i see ...
Feb 17 15:59:52 <fdanis> denkenz: hello, I have some unwanted emulator disconnection:
Feb 17 15:59:53 <fdanis> - if I connect to the emulator sample using telnet while modem is enabled, I am able to use online-modem/offline-modem several times
Feb 17 15:59:53 <fdanis> - if I connect when modem is online, first call to offline-modem remove the emulator atom
Feb 17 16:00:02 <fdanis> HFP needs to keeps the connection during time modem is enabled, even if connection occured when modem is online (it should not disconnect if signal is lost)
Feb 17 16:00:58 <denkenz> fdanis: known bug, the atom is created with the same state as the modem, so if the modem is moved to a lower state the atom is removed
Feb 17 16:02:40 <fdanis> denkenz: do you have any idea how to fix it ?
Feb 17 16:02:40 <fdanis> I did not find one, and HFP also needs to support multiple clients
Feb 17 16:03:18 <denkenz> We'll need some way to override the atom state down to offline
Feb 17 16:03:42 <denkenz> either a new atom_register variant or a setting function
Feb 17 16:09:00 <denkenz> fdanis: btw, in hfp_ag_connect_cb, do we even need a shutdown call?
Feb 17 16:09:12 <denkenz> Can't we simply return and have the socket be closed on unref?
Feb 17 16:11:05 <fdanis> denkenz: not sure to understand your question, fdalleau fixes the disconnection problem, do you see his fix ?
Feb 17 16:11:25 <denkenz> Yeah I applied it
Feb 17 16:11:33 <denkenz> But we also have a goto failed in there
Feb 17 16:11:49 <denkenz> and a g_io_channel_shutdown at that label
Feb 17 16:11:57 <denkenz> The question is whether we can simply return
Feb 17 16:13:53 <fdanis> denkenz: you are right, this is no more needed
Feb 17 16:14:41 <tomaszgr> denkenz: do you mean own gprs atom for a new atmodem lte driver?
Feb 17 16:16:05 <denkenz> My current thinking is that a brand new atom is needed for LTE bearer management
Feb 17 16:16:29 <denkenz> This might include an lte attach status
Feb 17 16:19:14 <tomaszgr> wouldn't it be almost a 1:1 copy of current gprs atom? just extended by lte status?
Feb 17 16:22:03 <tomaszgr> we would need to hand over active contexts between atoms when the barier changes
Feb 17 16:22:12 <denkenz> last time I thought about this, which was 3 months ago, the atom was different enough
Feb 17 16:22:36 <denkenz> But then I have no LTE hardware or network to play with, so all of this is pure conjecture ;)
Feb 17 16:26:14 <tomaszgr> ok :) well, I am not in much better position but I have some hardware posibilities, for me easiest and cleaniest way would be adding lte status to current gprs atom, but yes, this would break assumption of one atom for one thing
Feb 17 16:28:00 <tomaszgr> I might not be aware of everything, but it looks like 3g, lte and 3g/lte modems differ mainly in having CGREG and CEREG UNs from at commands point of view (+ initial PDN)
Feb 17 16:36:41 <tomaszgr> I need to go, I'll put on the mailing list a patch with proposal for doing this, to have some background for discussion
Feb 17 17:03:19 <fdanis> denkenz: for online/offline, I can add __ofono_modem_add_atom_offline() to ofono.h which force atom->modem_state to MODEM_STATE_OFFLINE
Feb 17 17:03:19 <fdanis> are you ok with this ?
Feb 17 17:08:41 <padovan> fdanis: why do you need this?
Feb 17 17:11:01 <fdanis> padovan: atom created in online state are destroyed when modem goes to offline state
Feb 17 17:11:58 <fdanis> HFP needs to stay connected
Feb 17 17:14:37 <denkenz> fdanis: Either that or simply hardcode __ofono_modem_add_atom to add emulators in offline mode
Feb 17 17:15:06 <fdanis> denkenz: which one do you prefer ?
Feb 17 17:15:06 <denkenz> Or maybe we need to bite the bullet and expose modem states into ofono.h 
Feb 17 17:15:19 <denkenz> Do the atom_offline for now
Feb 17 17:40:53 <holtmann> ofonod[31910]: Replied with an error: org.freedesktop.DBus.Error.Spawn.ChildExited, Launch helper exited with unknown return code 1
Feb 17 17:41:08 <holtmann> denkenz: I keep seeing these now. Do you see them as well or is just a Fedora screwup?
Feb 17 17:41:32 <denkenz> Haven't seen these myself
Feb 17 17:45:21 <holtmann> I think they updated my D-Bus package.
Feb 17 17:45:35 <holtmann> Sounds to me like D-Bus autostart or crap like that.
Feb 17 17:48:29 <holtmann> denkenz: It is the Bluetooth support.
Feb 17 17:48:44 <denkenz> funny
Feb 17 17:49:00 <denkenz> I haven't tested the BT support since I don't have bluez installed
Feb 17 17:49:15 <padovan> holtmann: where exaclty?
Feb 17 17:49:52 <holtmann> No idea. It must call a org.bluez with something unknown.
Feb 17 17:50:10 <holtmann> Maybe the any adapter stuff. However dbus-daemon tries to autostart something.
Feb 17 17:50:51 <holtmann> Either add_record_cb or find_adapter_cb
Feb 17 17:50:52 <padovan> Is is on oFono powered -> online state?
Feb 17 17:51:07 <holtmann> Nope. It is on ofonod start.
Feb 17 17:51:16 <holtmann> All modems powered off.
Feb 17 17:56:08 <padovan> Nothing here.
Feb 17 17:56:16 <padovan> Ah, I had an ideia.
Feb 17 18:07:53 <holtmann> So bluetooth_ref sends commands without checking if BlueZ is up and running.
Feb 17 18:08:12 <holtmann>         bluetooth_watch = g_dbus_add_service_watch(connection, BLUEZ_SERVICE,
Feb 17 18:08:12 <holtmann>                                         NULL, bluetooth_disconnect, NULL, NULL);
Feb 17 18:08:36 <holtmann> So what is this? There is pure disconnect watch in gdbus. Or you do implement the bluetooth_connect callback.
Feb 17 18:13:04 <holtmann> bc793d94 (Frédéric Danis     2011-02-04 19:46:17 -0200 794)     bluetooth_send_with_reply("/", BLUEZ_MANAGER_INTERFACE, "GetProperties",
Feb 17 18:13:04 <holtmann> bc793d94 (Frédéric Danis     2011-02-04 19:46:17 -0200 795)                             manager_properties_cb, NULL, NULL, -1,
Feb 17 18:13:04 <holtmann> bc793d94 (Frédéric Danis     2011-02-04 19:46:17 -0200 796)                             DBUS_TYPE_INVALID);
Feb 17 18:13:04 <holtmann> bc793d94 (Frédéric Danis     2011-02-04 19:46:17 -0200 797) 
Feb 17 18:13:07 <holtmann> e0c1c155 (Frédéric Dalleau   2011-02-11 10:31:05 +0100 798)     bluetooth_send_with_reply("/", BLUEZ_MANAGER_INTERFACE, "FindAdapter",
Feb 17 18:13:10 <holtmann> e0c1c155 (Frédéric Dalleau   2011-02-11 10:31:05 +0100 799)                             find_adapter_cb, NULL, NULL, -1,
Feb 17 18:13:13 <holtmann> e0c1c155 (Frédéric Dalleau   2011-02-11 10:31:05 +0100 800)                             DBUS_TYPE_STRING, &adapter_any_name,
Feb 17 18:13:16 <holtmann> e0c1c155 (Frédéric Dalleau   2011-02-11 10:31:05 +0100 801)                             DBUS_TYPE_INVALID);
Feb 17 18:13:26 <padovan> A dbus disconnect will fit better there. I didn't figured out when I wrote that the first time
Feb 17 18:13:29 <holtmann> fdanis: You can not just call a D-Bus message without ensuring that the daemon is running.
Feb 17 18:13:47 <padovan> we can also do this:
Feb 17 18:13:48 <padovan>         if (dbus_message_is_error(reply, DBUS_ERROR_SERVICE_UNKNOWN)) {
Feb 17 18:13:48 <padovan>                 DBG("Bluetooth daemon is apparently not available.");
Feb 17 18:13:48 <padovan>                 goto done;
Feb 17 18:13:48 <padovan>         }
Feb 17 18:14:02 <holtmann> padovan: No. That is fully wrong.
Feb 17 18:14:28 <holtmann> You need to monitor when the daemon becomes available. And only then bootstrap.
Feb 17 18:15:06 <holtmann> So the error was clearly visible, but it got ignored and hacked around.
Feb 17 18:15:10 <holtmann> Please fix this properly now.
Feb 17 18:16:42 <denkenz> I think this bug has been there for a long time
Feb 17 18:16:55 <denkenz> Probably ever since the original hfp implementation 
Feb 17 18:17:25 <holtmann> Could be. Nevertheless it just got hacked around now when adding more logic to it.
Feb 17 18:18:15 <padovan> denkenz: yes, it's from the original hfp code
Feb 17 18:18:21 <holtmann> padovan: Also the connect callback from the service watch will be automatically called if the daemon is already running.
Feb 17 18:18:41 <padovan> I remember when I wrote that bug. ;)
Feb 17 18:18:52 <denkenz> likely it never came up because bluetoothd was always running in our testing
Feb 17 18:19:02 <denkenz> But as I said, I don't even have bluez installed :P
Feb 17 18:19:26 <holtmann> Fedora is making bluetoothd exit if no devices are present (rfkill).
Feb 17 18:19:26 <padovan> holtmann: yes, I'm changing the code to have a connect callback, and then start the DBus cals from there.
Feb 17 18:21:21 <padovan> And we actually don't need to call Manager.GetProperties, we are already sticked to the AdapterAdded property 
Feb 17 18:21:54 <demarchi[WORK]> zrafa: around?
Feb 17 18:21:55 <denkenz> what if we're started after?
Feb 17 18:22:48 <padovan> denkenz: yeah, that is the reason in have both triggers
Feb 17 18:22:52 <zrafa> demarchi[WORK]: yes
Feb 17 18:22:57 <padovan> I can remember now.
Feb 17 18:23:21 <demarchi[WORK]> interesting... why do i have this nick?
Feb 17 18:23:45 <padovan> because you are supposed to be working now...
Feb 17 18:23:48 <demarchi[WORK]> i don't remember connecting from anywhere else
Feb 17 18:24:31 <demarchi[WORK]> zrafa: so... about your gps patches
Feb 17 18:25:00 <demarchi[WORK]> zrafa: why do you keep an fd when you open the device and send it through dbus?
Feb 17 18:25:06 <holtmann> padovan: You need to call that one.
Feb 17 18:25:25 <holtmann> padovan: It could be that bluetoothd is already running. Then you missed the AdapterAdded signal.
Feb 17 18:26:21 <padovan> Yes, Denis just made me figure out that now.
Feb 17 18:26:45 <zrafa> demarchi[WORK]: because the api changed completely since you check last time I guess. Now the atom should give via dbus the fd to the external client who asked for it. when external client releases it ofono should close the file.
Feb 17 18:27:12 <demarchi[WORK]> but dbus will dup the ff
Feb 17 18:27:15 <demarchi[WORK]> s/ff/fd/
Feb 17 18:27:27 <demarchi[WORK]> no need to keep it open
Feb 17 18:28:39 <zrafa> demarchi[WORK]: that is like the api was decided. You can change and modify it again ;)
Feb 17 18:33:06 <zrafa> demarchi[WORK]: if you do not keep it open, why we would send a fd to some external client?. It would not be a fd
Feb 17 18:33:37 <holtmann> demarchi[WORK]: You might wanna keep the fd around. So you can do a shutdown() on it.
Feb 17 18:33:38 <demarchi[WORK]> zrafa: it's a dup'ed fd
Feb 17 18:33:47 <holtmann> From oFono side that is.
Feb 17 18:34:10 <holtmann> Only if you don't need any control over the fd anymore at anytime, you can just close it.
Feb 17 18:35:50 <demarchi[WORK]> holtmann: but it's not a socket
Feb 17 18:37:57 <holtmann> True, I have never tested this on device nodes.
Feb 17 18:38:27 <holtmann> Would be good to know if that works as well. However then a close() should trigger a HUP on the duped fd.
Feb 17 18:38:52 <denkenz> We don't really know what type of fd it is
Feb 17 18:38:57 <denkenz> It might be a socket as well
Feb 17 18:39:04 <denkenz> e.g. caif socket or phonet socket
Feb 17 18:39:13 <demarchi[WORK]> also, since the driver opened the device, it's its role to know if it's a socket or not
Feb 17 18:39:27 <demarchi[WORK]> so, no need to the fd on core
Feb 17 18:40:07 <demarchi[WORK]> s/need to/need to keep/
Feb 17 18:41:18 <demarchi[WORK]> i'd keep the fd inside the driver
Feb 17 18:41:48 <padovan> But I think I need to keep the 
Feb 17 18:41:48 <padovan> -       if (dbus_message_is_error(reply, DBUS_ERROR_SERVICE_UNKNOWN)) {
Feb 17 18:41:49 <padovan> -               DBG("Bluetooth daemon is apparently not available.");
Feb 17 18:42:16 <demarchi[WORK]> denkenz: then i remove the ofono_location_reporting_get_fd
Feb 17 18:42:49 <padovan> holtmann: what happens if bluetoothd goes down just after ofonod sends a method call. then that check is still needed.
Feb 17 18:44:05 <denkenz> demarchi[WORK]: sure
Feb 17 18:46:50 <holtmann> padovan: You can cancel outstanding D-Bus method call in case the daemon goes down.
Feb 17 18:46:57 <holtmann> Also the error will be a timeout then.
Feb 17 18:48:05 <denkenz> no such service probably
Feb 17 23:56:44 <holtmann> denkenz: Don't you want to combine sim_file_read and sim_add_file_watch into something like sim_file_read_and_watch that does all the magic for you?
Feb 17 23:57:19 <holtmann> At least for simple case where you just have to re-read that single file?
Feb 17 23:57:21 <denkenz> not really, there are some places that don't care
Feb 18 00:17:44 <holtmann> Just giving a NULL handler or having an extra helper might work then.
Feb 18 00:18:33 <denkenz> let this evolve a bit, right now it is not needed
Feb 18 00:19:12 <denkenz> we also need to let watches and file reads be cancellable separately
Feb 18 00:19:48 <holtmann> Fair enough. Looked just like same code over and over again, when I reviewed it.
**** ENDING LOGGING AT Fri Feb 18 02:59:57 2011