**** BEGIN LOGGING AT Wed Feb 09 02:59:57 2011 Feb 09 08:55:02 denkenz: ping Feb 09 09:51:14 holtmann: ping Feb 09 13:54:27 quit Feb 09 15:46:08 denkenz: You changes to the bluetooth patches looks good. Feb 09 15:46:17 I had no eyes too see those issues. Feb 09 16:01:52 padovan: hehe Feb 09 16:01:58 akiniemie: pong Feb 09 16:02:09 akiniemi: rather Feb 09 16:03:53 denkenz: In your patch, when server is stopped the connected clients are not disconnected, is it the attended behavior ? Feb 09 16:04:08 fdanis: yep Feb 09 16:04:19 we might want to kill the server and keep the client sockets Feb 09 16:04:29 Besides, even in your patch they are not disconnected Feb 09 16:04:42 You just remove a watch, if the GIOChannel has other watches active, its still around Feb 09 16:05:07 you're right Feb 09 16:08:15 after authorization is completed, if socket fails, client_event() will call cancel_authorization(), can this be a problem ? Feb 09 16:17:17 fdanis: Isn't this what we want? Feb 09 16:17:30 fdanis: Ah sorry, it won't Feb 09 16:17:34 we remove the source Feb 09 16:17:42 see g_source_remove in cb_data_destroy Feb 09 16:18:28 denkenz: this will only be called when the socket disconnects Feb 09 16:20:37 fdanis: Sorry not getting you Feb 09 16:20:39 sorry, another mistake, I do not catch that we no more follow the client socket after authorization phase Feb 09 16:57:05 denkenz: in the bluetooth server patches, AddRecord is called once per adapter. Feb 09 16:59:06 denkenz: Does it makes sense to call AddRecord at higher level so that it is registered once for all adapter? /org/bluez/xyz/any object provides org.bluez.Service.AddRecord method that seems to do that Feb 09 16:59:41 fdalleau: That would make sense to me, however I think padovan had some problems in BlueZ trying to do this Feb 09 17:00:26 No, I haven't tryed that. Feb 09 17:00:39 That makes sense to me too. Feb 09 17:01:26 So lets just go in that direction, submit patches to fix it Feb 09 17:01:29 denkenz: padovan: good, let me have a look at this Feb 09 17:15:58 denkenz: I saw that the nai (next action indicator) was actually parsed from proactive commands TLV objects like SETUP Menu, Select Item. Feb 09 17:16:23 But this kind of information is not provided to the STK agent. Any reason for that ? Feb 09 17:17:21 basically no point in it Feb 09 17:17:36 pretty much hard to display to the user in any meaningful manner Feb 09 17:17:43 Or explain it to the UI developer Feb 09 17:19:29 Precisely, that was my first opinion too but talking with the guys in charge of the STK agent, we could display elegantly this kind of information. Feb 09 17:20:26 Also this NAI is tested from GCF and this is mandatory. Yes, I know this is not sufficient... Feb 09 17:21:40 So, if you don't mind, I willing to add this nai in the dbus message signature. Feb 09 17:21:53 Last we discussed it the NAI was not mandatory Feb 09 17:22:49 "The inclusion of Feb 09 17:22:50 the items next action indicator is to allow the terminal to indicate to the user the consequences of performing the Feb 09 17:22:50 selection of an item. Feb 09 17:22:50 " Feb 09 17:22:57 There's no indication of SHALL / MUST etc Feb 09 17:23:28 sure ? I don't see any option related to that nor a byte in the STK profile ? But I can double check. Feb 09 17:24:07 Yes, it is specified, if the SIM provides this info, the terminal may ... Feb 09 17:24:35 'may' is not must ;) Feb 09 17:25:02 There's also: "If the UICC provides an Items Next Action Indicator data object, the comprehension required flag shall be set to '0'. Feb 09 17:25:02 " Feb 09 17:25:09 If CR flag is 0, it is optional Feb 09 17:26:31 Ok, let's clarify why it is indicated 'M' in the test applicability table. I come back to you later on this subject. thanks. Feb 09 17:28:32 Feel free to discuss the proposal either way Feb 09 17:28:55 Maybe it is elegant enough to include, but the 10 minutes I spent thinking about it I wasn't convinced ;) Feb 09 17:38:25 In practice, we are never receiving icons in the proactive commands. So the idea is: as we are displaying default icons for each proactive commands, we could display the same icon in a bullet when highlighting an item in the menu. Feb 09 17:38:30 That's roughly my comprehension Feb 09 17:39:09 But I prefer also to skip this information if not mandatory. You gave me the doubt. Feb 09 17:42:22 that was also my idea for using the "next action" indicators, but i'm not sure if there's any value to the user Feb 09 17:42:55 iirc Jeevaka has a phone which does make use of these indicators in some way Feb 09 17:52:39 balrog-k1n: finding a way to render elegantly this information is I think possible but I agree with Denis why bother if it is not mandatory and even if it is mandatory it is specified, the terminal may inform not must. Feb 09 17:53:12 there is here something confusing I need to clarify. Feb 09 18:34:52 for GCF sure, but generally we need to consider what is or isn't useful to the user in the first place :) Feb 09 20:28:17 denkenz: have you had time to look at pessi's SIM ready notify patches? Feb 09 20:30:00 denkenz: they look good to me, but you've discussed the issue in the past Feb 09 20:36:11 akiniemi: They look good to me as well, but I want to have some time to play with them Feb 09 20:36:29 holtmann: ping Feb 09 20:36:39 I've also asked Jeevaka to look at them but haven't looked at his findings yet Feb 09 20:36:44 on IFX that is Feb 09 20:44:20 Jeevaka: So it looks like the sim_ready stuff works nicely on IFX right? Feb 09 20:46:04 Jeevaka: pong Feb 09 20:48:55 denkenz: yep, didnt face any issues with the hot swap as well Feb 09 20:50:39 Jeevaka: Have you tried the no-pin case? Feb 09 20:50:49 yes Feb 09 20:50:58 denkenz: yes Feb 09 20:51:17 Ok, sweet Feb 09 20:51:29 Let me see if I can merge these in then Feb 09 20:52:32 holtmann: incase of ifx fast dormancy support with old fm, it supports only set and query command Feb 09 20:53:22 holtmann: i'm working to add the support for both old(mode=1) and new fw(mode 2 - ONand 3 - OFF) Feb 09 20:54:24 is it ok if the patch takes care of both the case or is it enough to provide support for only the new firmware? Feb 09 21:02:29 Jeevaka: No. Feb 09 21:03:04 If you hit a firmware with XFDOR=? that gives you only mode 1, then don't do XFDOR. Feb 09 21:03:29 See the lengthy description in our API docs what we expect to make it behave. Feb 09 21:03:43 And until you invented a time machine, you can not make mode 1 behave like that. Feb 09 21:05:10 holtmann: ok Feb 09 21:07:33 read the doc, agreed. definitely with only mode 1 its not possible Feb 09 23:55:33 hi Feb 09 23:56:17 holtmann: do you still think we should make additional gprs_context driver for kernel mux case? Feb 09 23:58:17 so far we are using same gprs context driver , for ifx, just switching between kernel mux and user space mux, based on line discipline define in udev rules... Feb 10 00:04:39 tino: At some point the line discipline define will go away and we just check support for N_GSM. Feb 10 00:35:39 hm Feb 10 00:36:04 so if n_gsm is not in then? Feb 10 00:36:17 we simply don't load the driver? Feb 10 00:43:03 so this means we could now have just one driveR? **** ENDING LOGGING AT Thu Feb 10 02:59:57 2011