**** BEGIN LOGGING AT Tue Jul 27 02:59:56 2010
Jul 27 09:18:48 <tmzt> anybody know how to make hfpmodem actually do something? I've been reading the source and everything else [hfpmodem] Driver=hfpmodem in /usr/local/etc/ofono/modem.conf doesn't appear to work, neither does adding HF and HFAG with sdptool or trying to conenct from phone
Jul 27 09:19:18 <tmzt> this is current git running from the source tree
Jul 27 09:31:56 <tmzt> okay, so ./bootstrap followed by configure doesn't appear to work, ./bootstrap-configure is required
Jul 27 09:45:06 <tmzt> okay, I do have dbus 1.3 so I'm not sure what's going on, but it's reaching the return -BADF in plugins/hfp.c
Jul 27 09:47:35 <tmzt> no it's 1.2.16 and ubuntu is lying about the abi or some other weirdness, I guess I'm installing dbus from source
Jul 27 11:37:59 <tmzt> it worked, had to upgrade to bluez git, dbus-1.3.xx and repair after the service uuid was registered correctly
Jul 27 11:38:06 <tmzt> I think I can make calls now, we'll see
Jul 27 17:25:03 <jprvita> inakypg: I'm starting to look at your sms work, is everything on master branch?
Jul 27 17:25:20 <inakypg> jprvita: yes
Jul 27 17:25:35 <jprvita> i see a smsdbus branch but it's based on a very old commit from upstream
Jul 27 17:25:43 <jprvita> ok, tks
Jul 27 18:17:38 <denkenz> balrog-k1n: here?
Jul 27 18:17:59 <balrog-k1n> denkenz: yep
Jul 27 18:18:18 <denkenz> So I'm looking at the stkagent.[ch] patches
Jul 27 18:18:34 <denkenz> I'm wondering whether we can encapsulate the calling of Agent methods completely inside it
Jul 27 18:18:43 <denkenz> e.g. stk_agent_request_selection()
Jul 27 18:18:52 <denkenz> stk_agent_display_text()
Jul 27 18:18:54 <denkenz> etc
Jul 27 18:19:16 <balrog-k1n> i guess we could, but there will be many
Jul 27 18:19:52 <denkenz> To me that seems cleaner, because we can also typecheck the arguments and sanitize the ouput from the agent
Jul 27 18:20:00 <denkenz> e.g. get_key returns a single UTF8 char, etc
Jul 27 18:20:06 <balrog-k1n> there will be even more call than there are currently in stk-api.txt
Jul 27 18:20:33 <balrog-k1n> we can also sanitize in stk.c
Jul 27 18:20:33 <denkenz> I know, but all this has to be handled somewhere anyway
Jul 27 18:20:59 <denkenz> Sure, but this makes result handling from stkagent useless
Jul 27 18:21:07 <denkenz> You're doing it inside stkagent.c and then again in stk.c
Jul 27 18:21:29 <balrog-k1n> well yeah, in stkagent.c i'm not looking at the contents of a successful reply
Jul 27 18:22:01 <denkenz> Yeah, so I think this can be all made cleaner
Jul 27 18:22:14 <denkenz> The only sticky point is dbus marshaling of menus
Jul 27 18:22:55 <balrog-k1n> because they will be shared between stkagent.c and stk.c?
Jul 27 18:23:46 <jprvita> inakypg: unit/test-sms-msg-id.c:25: error: no previous declaration for ‘test_fatal_log’
Jul 27 18:23:58 <jprvita> are you using --enable-maintainer-mode?
Jul 27 18:24:19 <jprvita> It enables more warnings and treat warnings as errors, so we can put the compiler to work for us :)
Jul 27 18:25:00 <jprvita> it's complaining because you should use static for that function
Jul 27 18:25:00 <balrog-k1n> denkenz: the menu utils can go in stkutil.c
Jul 27 18:25:35 <denkenz> balrog-k1n: Correct, sharing is a bit nasty
Jul 27 18:25:51 <denkenz> If we do the marshaling in stkutil.c then we introduce a dependency there
Jul 27 18:26:47 <jprvita> i've fixed that one, but I've found more header problems on src/sms.c
Jul 27 18:27:14 <balrog-k1n> denkenz: oh right, we don't want to link the unit tests against dbus
Jul 27 18:27:27 <jprvita> I guess you've forgot to declare some functions / structs on include/sms.h
Jul 27 18:28:10 <denkenz> balrog-k1n: Yep, so my thinking is that maybe the stk_menu struct should be simplified to use string, int pair
Jul 27 18:28:26 <denkenz> balrog-k1n: And we introduce a new marshal function for such string, int pair in dbus.c
Jul 27 18:29:15 <balrog-k1n> i think it's simpler to just move the marshalling function to stkagent.c and make it public so stk.c can use it
Jul 27 18:31:04 <denkenz> Simpler yes, but stk_menu is way too complicated
Jul 27 18:32:04 <denkenz> It needs to be simplified down to string title, vector<pair<string, byte>> items and some of those gbooleans you have
Jul 27 18:32:46 <balrog-k1n> if it's going to use GSList it'll just make it worse :)
Jul 27 18:33:18 <denkenz> Use an array of struct string_int_pair
Jul 27 18:33:29 <denkenz> I don't understand why everyone hates GSList ;)
Jul 27 18:33:53 <denkenz> You'd rather be picking apart a very low level data structure as opposed to dealing with strings? Jeez
Jul 27 18:34:16 <balrog-k1n> i personally hate it because of the number of mallocs to create a GSList :)
Jul 27 18:34:46 <holtmann> balrog-k1n: GLib has GPtrArray and should also have a string array thingy.
Jul 27 18:35:15 <balrog-k1n> well, C alrady has arrays
Jul 27 18:35:37 <denkenz> balrog-k1n: I don't see the point of worrying about that, you will need to run the items and the title through Kristen's magic html converter anyway
Jul 27 18:35:43 <denkenz> So I think your concern is misplaced
Jul 27 18:35:46 <holtmann> Sure, but you have to grow them manually if needed. If you know the size of front, everything is fine.
Jul 27 18:35:46 <balrog-k1n> ah the string array functions in Glib are nice
Jul 27 18:36:49 <balrog-k1n> holtmann: if i need to grow them then GSList is ok, but in this case it's just a constant size array
Jul 27 18:37:35 <denkenz> Again, its fine to use an array too
Jul 27 18:37:42 <denkenz> We can then g_strfreev it
Jul 27 18:38:04 <denkenz> However, you still need to malloc everything because html converter will do that
Jul 27 18:40:13 <balrog-k1n> denkenz: if we move all the request handling to stkagent.c we will need a struct for each request's parameters and one for each response (or a function typedef)
Jul 27 18:40:35 <denkenz> Function typedef is fine, e.g. see bluez/src/agent.h
Jul 27 18:41:11 <balrog-k1n> yes, but iirc bluez just has one or two agent requests, and stk-api.txt already has about 10
Jul 27 18:41:26 <denkenz> Sure, but I want the code readable
Jul 27 18:41:33 <denkenz> So if we have to do more work, so be it
Jul 27 18:42:13 <denkenz> Also remember that we will most likely re-use stk agent in other parts
Jul 27 18:42:27 <denkenz> So that will pay off anyway
Jul 27 18:42:49 <balrog-k1n> if we're going to re-use it then we should not put more stk-specific stuff in it
Jul 27 18:43:15 <balrog-k1n> but i don't think there's so much to re-use anyway
Jul 27 18:44:54 <balrog-k1n> ok, what i like about the current code is that adding a new command is pretty simple, so it's extensible
Jul 27 18:45:17 <balrog-k1n> if we move things to stkagent.c, everytime you add a new command you'll need changes in both files and in the header
Jul 27 18:45:40 <denkenz> Its not like we're going to be adding any new commands
Jul 27 18:46:17 <denkenz> And right now what I'm seeing is a mess of functions between two files trying to cooperate
Jul 27 18:46:19 <balrog-k1n> we'll at least need to add Get Input, Get Inkey, Set Up Call
Jul 27 18:46:23 <denkenz> e.g. a disaster area
Jul 27 18:47:00 <balrog-k1n> ok, let's change it
Jul 27 18:47:02 <balrog-k1n> but it's no soooo bad :)
Jul 27 18:47:24 <denkenz> Lets just try it, maybe I'm wrong
Jul 27 18:47:33 <denkenz> But in the end I don't think the added code will be all that much
Jul 27 18:48:21 <denkenz> Just all the nasty validation crap will be off in one file, so it doesn't clutter up stk.c logic
Jul 27 18:49:12 <denkenz> And if possible, lets make stk_agent structure opaque
Jul 27 18:49:47 <balrog-k1n> ok, i can add the same calls that bluez had, i just don't see much point
Jul 27 18:49:51 <balrog-k1n> has*
Jul 27 18:50:04 <holtmann> Don't trust BlueZ too much here.
Jul 27 18:50:36 <holtmann> We were the first one using agent style D-Bus and might have still some craziness in there.
Jul 27 18:51:03 <denkenz> Craziness yes, layout of the .c files is fine
Jul 27 18:51:35 <denkenz> Lets just treat stkagent as another class with an API
Jul 27 18:51:38 <balrog-k1n> i'm just talking about making the structure opaque, maybe it makes sense but it changes direct accesses to calls (inherently slower for no reason, but not a very big deal)
Jul 27 18:51:56 <denkenz> Then maybe you have too many accesses ;)
Jul 27 18:51:57 <balrog-k1n> i.e. java style
Jul 27 18:54:14 <denkenz> The only ones I buy are path and bus for UnregisterAgent call, and performance isn't really a consideration there
Jul 27 18:55:01 <kristenc> denkenz: do you have a minute to talk about EFimg and EFiidf?
Jul 27 18:55:11 <denkenz> kristenc: Sure
Jul 27 18:55:46 <balrog-k1n> yeah, there are only three accesses, the two you mentioned and one checking if any request is running i think (so just need to make app_agent_busy() public)
Jul 27 18:55:46 <kristenc> denkenz: you mention in the TODO that you want all the icons automatically read and made available via dbus.
Jul 27 18:56:08 <kristenc> but presumably we could have a lot of images to read, and it is slow to read from the sim.
Jul 27 18:56:10 <balrog-k1n> obviously not a big performance hit but there's still no reason to change them into calls
Jul 27 18:56:40 <kristenc> and is it possible we have limited memory resources?  I wonder if we should keep a cache of a few EFiidfs but maybe cap how much memory we spend on that
Jul 27 18:56:54 <kristenc> and use an algorithm to evict them from the cache if necessary.
Jul 27 18:56:58 <kristenc> what do you think?
Jul 27 18:57:30 <holtmann> denkenz: Since we have GetIcon method call now. Can we not just lazy read them when needed and then cache them?
Jul 27 18:57:46 <holtmann> We just need to have the list of available icon indexes up-front.
Jul 27 18:57:52 <denkenz> So I thought about this some
Jul 27 18:58:06 <denkenz> My personal suggestion is that EFimg should be read at startup
Jul 27 18:58:10 <balrog-k1n> we do we even need to expose all available icon indexes?
Jul 27 18:58:41 <denkenz> And cached in memory semi-efficiently
Jul 27 18:58:59 <denkenz> The reading of the actual data can be done on-demand (potentially _very_ slow)
Jul 27 18:59:10 <holtmann> balrog-k1n: The UI needs this information if it wants to read these up-front. I don't want tons of GetIcon() calls for unavailable indexes.
Jul 27 18:59:15 <kristenc> denkenz: reading the EFimg files at start up makes sense.  They will not be very large.  But then for the data files, I wonder if it would make sense to keep a small cache.
Jul 27 19:00:07 <holtmann> So once the data is read we keep it in memory.
Jul 27 19:00:09 <denkenz> Another possibility is to just read them at some point after startup and cache on disk
Jul 27 19:00:32 <holtmann> The penalty of memory usage is only for UI applications actually using the icons.
Jul 27 19:00:51 <holtmann> Not sure if our UI design will in the end. The iPhone for example doesn't care and seems to get away with it.
Jul 27 19:00:51 <balrog-k1n> they should be cached on disk transparently (unless they're modifiable but i don't think)
Jul 27 19:00:59 <kristenc> denkenz: would we always be in an environment where we'd have plenty of disk space?
Jul 27 19:01:17 <holtmann> Not necessarily.
Jul 27 19:01:24 <denkenz> They probably wouldn't be cached, the EFiidf files are modifiable
Jul 27 19:01:42 <denkenz> However, define plenty of space? I doubt SIM can store more than a few MB
Jul 27 19:01:49 <holtmann> So we have to be careful here. I just say lets read them into memory in demand based on GetIcon() method call.
Jul 27 19:02:14 <holtmann> But then again caching them in /var/lib/ofono/<imsi>/ is also fine.
Jul 27 19:02:30 <denkenz> Caching into /var/cache is better
Jul 27 19:02:47 <kristenc> could we use a compile flag to define an appropriate cache size
Jul 27 19:02:49 <balrog-k1n> as far as i can see there can be max 256 icons, max 65536 icons, so 16MB max
Jul 27 19:02:49 <holtmann> Would be better for sure, but I don't wanna pollute another directory.
Jul 27 19:03:20 <balrog-k1n> err max 65536 bytes per icon
Jul 27 19:03:47 <balrog-k1n> was there another limit?
Jul 27 19:03:55 <denkenz> Nope, 16MB is correct
Jul 27 19:04:06 <denkenz> But I doubt any SIM in existence does that
Jul 27 19:04:24 <denkenz> The basic point here is that on-demand loading is going to be too slow
Jul 27 19:04:44 <denkenz> We only want to do that in case an app is speedy gonzales and wants an icon before we're ready
Jul 27 19:04:56 <holtmann> For simplicity and get this started, lets load them on-demand into memory. So first GetIcon call will be slow. After that it will be fast.
Jul 27 19:05:07 <holtmann> Then we can optimize with disk caching from there.
Jul 27 19:05:41 <holtmann> denkenz: Btw. we need a note for GetIcon() method call that it might take time when called first. So they set a proper D-Bus timeout value.
Jul 27 19:06:04 <denkenz> Shrug, that is assumed for all calls
Jul 27 19:06:31 <balrog-k1n> if we're going to cache them, maybe it's easier to re-use the already existing cacheing and just tell it that these files can be treated like read-only
Jul 27 19:06:52 <denkenz> except the cache needs to be removed every time a sim is inserted
Jul 27 19:07:05 <denkenz> Or modem powered down
Jul 27 19:07:19 <denkenz> Anyway, way too many cooks here right now
Jul 27 19:07:35 <denkenz> kristenc: Do the EFimg + on demand loading and we go from there
Jul 27 19:08:06 <balrog-k1n> so either we want to cache them on disk or we don't, and just cache them in ram
Jul 27 19:08:14 <holtmann> denkenz: That works as well. We can optimize that later ;)
Jul 27 19:08:17 <kristenc> denkenz: ok.
Jul 27 19:08:30 <denkenz> balrog-k1n: No, we want to cache them on disk for the duration of the oFono session
Jul 27 19:08:39 <denkenz> balrog-k1n: The current EF caching is forever
Jul 27 19:08:39 <holtmann> I still don't know if any of my SIM cards actually have icons on it. I never saw them.
Jul 27 19:08:46 <denkenz> They do
Jul 27 19:08:55 <denkenz> And the GetIcon API will need to be moved
Jul 27 19:09:00 <denkenz> But that's for later
Jul 27 19:09:01 <balrog-k1n> denkenz: is it to save on RAM?
Jul 27 19:09:09 <denkenz> balrog-k1n: Yeah
Jul 27 19:09:20 <balrog-k1n> ah
Jul 27 19:10:58 <kristenc> denkenz: would you create a new file for icon related code, or just throw all this stuff into stkutil?
Jul 27 19:11:43 <denkenz> kristenc: It depends on how much code there is, but definitely not stkutil, that one is getting overused
Jul 27 19:12:06 <denkenz> GetIcon will be moved to the SIM atom
Jul 27 19:12:17 <denkenz> so you might want to do your changes inside sim.c
Jul 27 19:12:19 <kristenc> denkenz: that was my feeling too.  Perhaps I'll create a new file and we can figure out where the stuff goes at the end.
Jul 27 19:12:38 <denkenz> That would be fine as well
Jul 27 19:12:45 <holtmann> denkenz: Then also the Icon index property needs to be moved.
Jul 27 19:12:48 <kristenc> (meaning after we're all done we can sort out where stuff belongs).
Jul 27 19:13:06 <denkenz> holtmann: I know
Jul 27 19:13:14 <holtmann> denkenz: Question is why do you wanna move it?
Jul 27 19:13:28 <denkenz> Because there are icons used outside STK
Jul 27 19:13:32 <holtmann> Anything else besides SIM Toolkit application using it? I know it is generic SIM feature, but why bother.
Jul 27 19:13:53 <holtmann> How are these icons used outside SIM Toolkit and where?
Jul 27 19:13:59 <denkenz> Carrier Logos
Jul 27 19:14:07 <holtmann> Crap.
Jul 27 19:14:45 <holtmann> Can we just not have a carrier logo specific API inside SIM interface ;)
Jul 27 19:14:59 <holtmann> I would hate if the UI code has to jump between interfaces.
Jul 27 19:15:19 <denkenz> Carrier logo icon id will get exposed on netreg / network operator
Jul 27 19:15:40 <denkenz> Then GetIcon() will be a generic function to be used by homescreen / stk
Jul 27 19:15:51 <holtmann> I understand that.
Jul 27 19:16:00 <holtmann> I am just coming from API usage point of view.
Jul 27 19:16:25 <denkenz> The ideal way is to ship the icon via D-Bus, then we don't have this problem
Jul 27 19:16:30 <denkenz> But you nixed that idea ;)
Jul 27 19:16:44 <holtmann> I know. However for one carrier logo that might be acceptable.
Jul 27 19:16:50 <holtmann> Just for STK case it was too much.
Jul 27 19:17:01 <holtmann> How many carrier logos do we expect on the SIM card.
Jul 27 19:17:19 <denkenz> Primary + up to 255 secondaries
Jul 27 19:17:44 <denkenz> However, they're only really exposed through NetworkOperator, so only a handful active at a time
Jul 27 19:17:44 <holtmann> Yeah ...
Jul 27 19:18:16 <holtmann> So in theory we could keep GetIcon on STK interface. And just expose the operator logo in binary.
Jul 27 19:18:47 <holtmann> Assume we have one for the current operator and the 4 for the other ones in your country. Never saw a country with more than 5 operators.
Jul 27 19:19:06 <denkenz> Honestly i don't see the point
Jul 27 19:19:49 <denkenz> You're not really saving much here for the application
Jul 27 19:19:59 <holtmann> Depends on the D-Bus bindings ;)
Jul 27 19:20:12 <holtmann> Some of them are utterly fucked. Like dbus-glib.
Jul 27 19:20:58 <denkenz> Still, even homescreen will need to pay attention to the Sim interface
Jul 27 19:21:04 <denkenz> For the Inserted status
Jul 27 19:21:12 <holtmann> Anyhow, that is a detail we can figure out once we have this working. Lets postpone this for a bit.
Jul 27 19:29:25 <inakypg> jprvita: sorry, was out -- the smsdbus branch should be forgotten -- quite a mess to delete it on gitorious, can't figure it out
Jul 27 19:29:46 <inakypg> jprvita: I'll check on the test_fatal_log thingie, thanks for the catch
Jul 27 19:30:28 <jprvita> inakypg: git push <gitorious_remote_name> :smsdbus
Jul 27 19:30:39 <jprvita> this should delete your remote branch
Jul 27 19:31:13 <jprvita> inakypg: use bootstrap-configure, it's really handy
Jul 27 19:32:03 <jprvita> -gboolean test_fatal_log(const gchar *log_domain,
Jul 27 19:32:03 <jprvita> +static gboolean test_fatal_log(const gchar *log_domain,
Jul 27 19:32:42 <jprvita> inakypg: since you're not exporting this function, this should suppress the warning
Jul 27 19:33:10 <jprvita> but for the other problems, I guess there are some stuff missing from sms.h
Jul 27 19:40:38 <inakypg> jprvita: verifying: this is in the master branch, right?
Jul 27 19:41:04 <jprvita> inakypg: yes
Jul 27 19:48:57 <inakypg> jprvita: wonder how did I miss the warning on non-declared sms_msg_send(), wth?
Jul 27 19:49:10 <inakypg> now solving that is less than trivial...run into #include hell
Jul 27 19:50:16 <jprvita> bootstap-configure enables maintainer-mode, which in turn enable extra warnings
Jul 27 19:50:38 <jprvita> I don't get any warning when compiling your master branch without maintainer-mode
Jul 27 19:51:27 <jprvita> inakypg: and yes, that's #include hell..  that's why I've stopped to try to fix it ;)
Jul 27 20:03:50 <jprvita> denkenz: I'm trying to test SMS patches from inakypg but I might have faced some sort of regression for huawei E220
Jul 27 20:04:10 <jprvita> on ofono 0.16 I used to have org.ofono.SmsManager org.ofono.NetworkRegistration org.ofono.VoiceCallManager org.ofono.SimManager for this modem
Jul 27 20:04:21 <jprvita> and now I have only SimManager
Jul 27 20:04:36 <denkenz> Is your modem pin locked?
Jul 27 20:04:53 <jprvita> no idea, how can I check this out?
Jul 27 20:05:01 <jprvita> I know it's operator-locked
Jul 27 20:05:06 <jprvita> is this what you mean?
Jul 27 20:05:09 <denkenz> What does AT+CPIN? return
Jul 27 20:05:26 <jprvita> let me enable at debug
Jul 27 20:05:41 <denkenz> I think kvalo's SIMST magic doesn't cover PIN locked modems
Jul 27 20:11:15 <jprvita> ofonod[14083]: > AT+CPIN?\r
Jul 27 20:11:15 <jprvita> ofonod[14083]: < \r\n+CPIN: READY\r\n\r\nOK\r\n
Jul 27 20:11:15 <jprvita> ofonod[14083]: at_cpin_cb got result: 1
Jul 27 20:11:15 <jprvita> (note: this is with 0.16, btw)
Jul 27 20:11:46 <denkenz> Paste your at debug with git on pastebin
Jul 27 20:12:22 <jprvita> ok
Jul 27 20:17:28 <kristenc> denkenz: one other question.  ofono_sim_read can only read entire files.  Is there a more appopriate api to read len bytes from fileid at a specified offset?  Or is it possible to issue a command to the sim to read only part of a file?
Jul 27 20:17:28 <jprvita> denkenz: http://pastebin.ca/1909586
Jul 27 20:17:52 <jprvita> (it's actually printing more BOOT and RSSI messages very slowly)
Jul 27 20:18:45 <denkenz> kristenc: I suggest you extend the sim queue to handle images
Jul 27 20:19:09 <denkenz> kristenc: We want to serialize our calls to the driver
Jul 27 20:20:14 <denkenz> That part can then take care of reading the clut & the like
Jul 27 20:42:57 <denkenz> jprivta: sounds like your modem never sends a SIMST
Jul 27 20:43:53 <denkenz> It also reports 'USIM is invalid in case of PS'
Jul 27 20:44:56 <jprvita> denkenz: is there someway to fix or workaround this issue?
Jul 27 20:46:10 <denkenz> ofonod[20614]: Pcui:< \r\n^SYSINFO:0,1,0,0,3,0,0\r\n\r\nOK\r\n
Jul 27 20:46:29 <denkenz> You can try doing a g_timeout and re-running the SYSINFO query
Jul 27 20:46:36 <denkenz> If that 3 turns into a 1 then you're fine
Jul 27 20:47:01 <denkenz> The other alternative is to simply force the inserted state inside plugins/huawei.c
Jul 27 20:50:16 <jprvita> so I can play with g_at_chat_send(data->pcui, "AT^SYSINFO", sysinfo_prefix, sysinfo_cb, modem, NULL) and notify_sim_state(), right?
Jul 27 20:50:28 <denkenz> yeah
Jul 27 20:51:01 <jprvita> seem very easy to test, tomorrow I'll let you know the results
Jul 27 21:00:23 <kristenc> denkenz: by sim queue you mean the simop_q ?  It seems that is only exposed through sim_read/sim_write.  Correct?
Jul 27 21:00:42 <denkenz> kristenc: Yep, but we can change that
Jul 27 21:00:54 <kristenc> denkenz: won't that lead to concurrency issues?
Jul 27 21:01:02 <denkenz> err?
Jul 27 21:01:16 <kristenc> multiple ways to push onto the same queue?
Jul 27 21:01:27 <denkenz> We're not threaded, so no
Jul 27 21:01:42 <kristenc> oh - but if we are only single threaded that doesn't matter...
Jul 27 21:02:28 <kristenc> ok.
Jul 27 21:15:45 <balrog-k1n> out of curiosity, why not use sim_read?
Jul 27 21:22:28 <denkenz> There are two problems
Jul 27 21:22:40 <denkenz> sim_read doesn't handle files > 256 bytes
Jul 27 21:22:58 <denkenz> And we don't actually want to read all of EFiidf
Jul 27 21:23:25 <denkenz> We only want to read and cache the portions that are relevant
Jul 27 21:24:38 <denkenz> e.g. EFiidf of 65K might have 2 images in the beginning and a C-LUT at the end
Jul 27 21:24:56 <denkenz> Reading all 65K (256 read operations) to the SIM is wasteful, when maybe 10 would do
Jul 27 21:25:56 <balrog-k1n> denkenz: oh good point
Jul 27 21:27:19 <balrog-k1n> it should handle > 256-byte files if the driver supports it
Jul 27 21:28:47 <denkenz> We don't, because we don't utilize offset properly
Jul 27 21:29:11 <denkenz> We always use offset of 0 and don't actually check that length <= 256
Jul 27 21:29:35 <balrog-k1n> denkenz: ah yeah, now i remember, sorry
Jul 27 21:29:56 <denkenz> Up to now it just hasn't been a problem, nothing except EFiidf is more than 256 bytes ;)
Jul 27 21:53:25 <denkenz> holtmann: You should be happy now, your long asked for feature is in
Jul 27 22:25:31 <holtmann> denkenz: Sweet :)
Jul 27 22:33:58 <holtmann> zhenhua: Can you run potential btio.[ch] changes by #bluez or linux-bluetooth@vger.kernel.org first. I would require that Johan or Luiz are signing off on these as well.
Jul 27 23:35:18 <holtmann> kristenc: Did you send that patch just twice or is it a different version? If it is a different version please do something like [PATCH v2].
Jul 27 23:35:49 <holtmann> Or is my mailserver being stupid again and not filtering duplicates. That could be also posssible :(
Jul 27 23:35:51 <kristenc> holtmann: it's a different version.  I'll do that next time, sorry
Jul 27 23:36:08 <kristenc> ignore the first version, it had a bug
Jul 27 23:36:16 <holtmann> No problem. Just helps us to ignore the previous version.
Jul 28 00:06:17 * balrog-k1n will soon be doing [PATCH v75] sending stk patches ;)
Jul 28 00:14:11 <zhenhua> holtmann: not quite catch you. btio.[ch] is a subset of bluez's btio.[ch]. how to run them within bluez?
Jul 28 00:15:13 <zhenhua> holtmann: the 5 patches are for oFono. i doubt they might be confused how to review the patches.
Jul 28 00:18:20 <denkenz> balrog-k1n: You just need denkenz mind reader device ;)
Jul 28 00:28:30 <zhenhua> denkenz: any comments for dun patches?
Jul 28 00:51:27 <denkenz> zhenhua: You need to get the btio stuff through holtmann first
Jul 28 00:52:31 <luke-jr> N900 support still on vacation?
Jul 28 00:55:23 <zhenhua> i see.
Jul 28 01:02:13 <balrog-k1n> denkenz: i assume the string_and_int type needs to be added in g_dbus, right?
Jul 28 01:02:30 <balrog-k1n> gdbus, not g_dbus
Jul 28 01:04:35 <balrog-k1n> ah, not right
Jul 28 01:05:11 <balrog-k1n> ok, ignore me, i found the right header
Jul 28 01:05:19 <denkenz> balrog-k1n: just src/dbus.c
Jul 28 01:05:33 <balrog-k1n> yes
Jul 28 01:06:24 <balrog-k1n> denkenz: i'm not sure between include/dbus.h and src/ofono.h though
Jul 28 01:06:54 <balrog-k1n> for the struct ofono_string_and_int (or similar) declaration
Jul 28 01:07:27 <denkenz> balrog-k1n: Stick it inside ofono.h and dbus.c for now with __ofono prefix
Jul 28 01:09:19 <denkenz> Maybe name it like __ofono_dbus_append_menu_item()
Jul 28 01:10:00 <balrog-k1n> wait, "items" in plural, right?
Jul 28 01:10:11 <balrog-k1n> since it needs to append the entire list
Jul 28 01:10:32 <denkenz> items is fine too
Jul 28 01:10:59 <denkenz> Probably makes more sense, you're right
Jul 28 01:11:01 <balrog-k1n> ok, just wasn't sure if we meant the same thing
Jul 28 01:16:17 <denkenz> And if you can make it use basic types that'd be nice
Jul 28 01:16:36 <denkenz> e.g. like const char **items, unsigned char *icons
Jul 28 01:17:17 <balrog-k1n> i thought we wanted an array of structs?
Jul 28 01:19:05 <balrog-k1n> i'm not sure if you're going to like it though :)
Jul 28 01:19:40 <balrog-k1n> there need to be three functions, __ofono_dbus_message_iter_append_menu_items for messages, __ofono_dbus_dict_append_menu_items for property dicts and __ofono_dbus_signal_menu_items_property_changed for properties
Jul 28 01:24:27 <denkenz> array of structs means we have to define the struct somewhere common
Jul 28 01:24:35 <denkenz> Bit hesitant to do it inside ofono.h
Jul 28 01:25:46 <denkenz> I see two choices here: basic types + implementation in dbus.c
Jul 28 01:25:47 <balrog-k1n> i have struct __ofono_string_and_byte in ofono.h together with the new functions, seems lesser evil than taking two array parameters :)
Jul 28 01:26:09 <denkenz> lol
Jul 28 01:26:35 <denkenz> disclaimer: I'm still totally waffling this myself, I hate every solution I thought of so far
Jul 28 01:27:17 <balrog-k1n> yeah
Jul 28 01:29:07 <denkenz> So I'm actually fine with something like struct stk_menu { char **items; byte *icons; }
Jul 28 01:29:21 <denkenz> And then having __ofono functions take char **items and byte *icons
Jul 28 01:30:04 <denkenz> Seems lesser of all evils so far
Jul 28 01:31:20 <balrog-k1n> how about stk_menu_item instead of string_and_byte then?
Jul 28 01:31:51 <balrog-k1n> and the __ofono functions take a single array
Jul 28 01:32:10 <denkenz> as in __ofono_foo(stk_menu_item *items)?
Jul 28 01:32:21 <balrog-k1n> right
Jul 28 01:32:36 <denkenz> So again, my problem there is the struct has to be defined somewhere
Jul 28 01:32:44 <denkenz> Putting it into ofono.h seems really ugly
Jul 28 01:32:57 <balrog-k1n> but you're already putting the functions there
Jul 28 01:33:37 <denkenz> Yeah, which is why I'd like basic types, it just feels cleaner
Jul 28 01:33:40 <balrog-k1n> another possibility is it could be a special case in ofono_dbus_dict_append_array
Jul 28 01:34:35 <balrog-k1n> using a fake dbus type constant
Jul 28 01:35:09 <denkenz> Heh, I could be convinced of that one, but feels too evil
Jul 28 01:36:16 <denkenz> All actuality the char ** is actually not bad
Jul 28 01:36:27 <denkenz> it leads to g_strfreev() and quite easy to fill in
Jul 28 01:37:08 <denkenz> Instead of messing with custom structs and struct destructors
Jul 28 01:37:37 <balrog-k1n> actually are you sure we want all three functions, instead of just append_menu_items_variant?
Jul 28 01:39:57 <denkenz> Lets see, we need the variant version for stk.c
Jul 28 01:40:04 <denkenz> and we need the regular version for stkagent.c
Jul 28 01:40:39 <balrog-k1n> the variant version can use the regular version
Jul 28 01:41:16 <denkenz> So maybe the regular version inside ofono.h and the other 3 static inside stk/stkagent
Jul 28 01:41:28 <denkenz> s/ofono.h/ofono.h & dbus.c
Jul 28 01:43:13 <denkenz> In reality we're talking about a 6 line function
Jul 28 01:43:31 <denkenz> If you want to just forget all this and duplicate the code, I'm fine with that too
Jul 28 01:44:15 <balrog-k1n> ok i'll let you decide :)
Jul 28 01:44:23 <balrog-k1n> the more ideas the more difficult to decide
Jul 28 01:45:01 <denkenz> Ok, tell me what you want the struct to look like? Are you still partial to item being 1 struct?
Jul 28 01:45:30 <balrog-k1n> that would be the cleaner way to me
Jul 28 01:48:25 <denkenz> Ok, then do that and duplicate the marshaller
Jul 28 01:49:54 <denkenz> Feel free to send the struct declarations, marshallers and basic MenuItem property implementation for review first
Jul 28 01:50:02 <denkenz> Even if it doesn't work / is empty
Jul 28 01:51:02 <balrog-k1n> so the structs would be declared in stkagent.c, and the variant version of the marshaller in stk.c and regular in stkagent.c?
Jul 28 01:51:21 <balrog-k1n> err
Jul 28 01:51:27 <balrog-k1n> struct in stkagent.h i mean
Jul 28 01:52:19 <denkenz> you can declare the struct and the _from functions in stkutil.[ch] too
Jul 28 01:52:39 <denkenz> e.g. to convert select item / setup menu into the simplified struct
Jul 28 01:52:51 <denkenz> And have that one call the text_to_html converter, etc
Jul 28 01:53:23 <denkenz> Then the marshallers as you described it
Jul 28 01:54:15 <balrog-k1n> i was thinking stk.c should call the text_to_html converter because using html is a property of our dbus interface
Jul 28 01:55:51 <balrog-k1n> how about we go back to your idea of the three marshallers defined in ofono.h and dbus.c, taking two separate arrays? :)
Jul 28 01:56:33 <denkenz> rofl
Jul 28 01:57:10 <denkenz> See how hard this is? :)
Jul 28 01:58:10 <balrog-k1n> well, i'll leave it for tomorrow and send something for review
Jul 28 01:58:21 <denkenz> I'm fine with it, question is who calls text_to_html?
Jul 28 01:58:30 <denkenz> You still need a utility function to do that
Jul 28 01:59:06 <balrog-k1n> so maybe let's define all the structs and marshallers in stkagent.[ch]
Jul 28 01:59:12 <balrog-k1n> and expose for stk.c to use
Jul 28 01:59:38 <denkenz> Okay, do that
Jul 28 02:01:03 <denkenz> If I change my mind I just move it around
Jul 28 02:01:09 <denkenz> Lets get this stuff merged
Jul 28 02:01:12 <balrog-k1n> ok
Jul 28 02:02:03 <denkenz> Go to sleep ;)
Jul 28 02:03:07 <balrog-k1n> good point :)
**** ENDING LOGGING AT Wed Jul 28 02:59:56 2010