**** BEGIN LOGGING AT Wed Aug 25 02:59:57 2010 Aug 25 11:01:44 hi there Aug 25 11:02:30 looking at drivers/hsomodem/gprs-context.c ... there's nothing GPRS specific as far as I can see, shouldn't be reflected that it can do 3G calls too? Aug 25 11:03:35 gprs means here packet data service, not 2G (or 2.5G) Aug 25 11:04:16 ok pessi thx for the input Aug 25 14:36:56 holtmann: Hi Marcel, I was wondering if the MMS effort for ofono has kicked off( i read ur response on the ML that it will be a separate daemon like obexd) and if there is any documentation/code available for it. Aug 25 15:22:14 Nothing for MMS is available yet Aug 25 16:08:13 hmph, my D5530 wnts to tell me it is D5530 Aug 25 16:10:05 ??? Aug 25 16:12:42 it sends unsolicated string D5530 some time after boot Aug 25 16:16:03 Hah. That is funny. Aug 25 16:16:40 not funny when your imei is D5530 ;) Aug 25 16:16:45 or IMSI Aug 25 16:19:50 and did you know that you can use SIM if its PIN is unlocked even if it otherwise wants to get PUKed? Aug 25 16:28:32 pessi: No I didn't, but that's sort of expected no? Aug 25 16:32:36 sort-of Aug 25 16:33:13 mbm firmware fires nw down and wants to get PUK but after a boot it works again Aug 25 16:34:02 How does one even get to the PIN unlocked but PUK required state? Aug 25 16:34:22 unlock pin, try to lock it three times with wrong pin Aug 25 16:34:36 That's silly Aug 25 16:34:56 ;) Aug 25 16:35:12 So now we have to deal with PIN retries even when LockPin is used Aug 25 16:35:18 I guess all isimodems regard sim as blocked if it wants to get puk Aug 25 16:35:37 And do what if that happens? Aug 25 16:35:55 If the firmware gets it wrong, not much oFono can do Aug 25 16:36:46 not much Aug 25 17:00:20 pessi: So the D5530 handler a purely informational thing? Aug 25 17:00:30 yes Aug 25 17:01:08 Ok, and the +CIMI returning D5530 is funny Aug 25 17:01:17 Too bad +CIMI doesn't have a response prefix Aug 25 17:02:14 A trick we used for CGMM and friends is to grab the last response line Aug 25 17:03:01 That has a good success rate of getting the actual response, not spurious crap Aug 25 20:27:48 balrog-k1n: Here? Aug 25 23:45:32 denkenz: so, if you don't care about wasting space, in which way would you prefer we waste space - putting blocks out of order in the same file and creating a 256 byte header which maps a block to it's location in the file, or leaving 256 byte holes in the file where needed and putting a 256 bit header for present bits? Aug 25 23:48:12 seems to me that putting them in out of order potentially wastes less space. Aug 25 23:58:03 I like the idea of using 256 bit header, we can re-use the same approach for records Aug 26 00:52:00 denkenz, kristen: am i thinking correctly that dividing the file in 256 byte blocks is artificial? why don't we read just the part we need in 256-byte pieces? Aug 26 00:54:36 btw. all modern filesystems support holes Aug 26 00:55:10 so if you open a new file, jump to position 512 and write 256 bytes, the file only occupies 256 bytes Aug 26 01:11:00 balrog-k1n: The idea here is that CLUT can be shared between multiple images Aug 26 01:11:51 balrog-k1n: So we break the file into blocks and read block by block, so that if an image shares the CLUT, we have it cached already Aug 26 01:12:22 That way its pretty simple, no need for more complicated region management Aug 26 01:13:13 balrog-k1n: And I didn't know about holes, so that suggests using a 8 byte bitmap in the header as being the least expensive storage wise Aug 26 01:13:31 denkenz: well, yes, code might become more complicated if you needed to keep track of where the cached pieces start and end Aug 26 01:14:28 balrog-k1n: Yeah, so I'm counting that the images are not going to be on some random start position within a block of 256 Aug 26 01:14:54 And worse case we have to issue 1-2 more reads than normally would... Aug 26 01:16:11 yes, overhead is never bigger than 510 bytes Aug 26 01:17:29 Also, the bitmap can be used for records as well Aug 26 01:17:46 Right now if we crash/shutdown/remove sim when the record file has not been read completely Aug 26 01:17:50 We start over Aug 26 01:17:59 Seems we can use the same bitmap idea there too Aug 26 01:18:11 + EFextN for the EFsdn and some other parts Aug 26 01:18:31 Frequently there'll be like 1 EFextN used out of 255 Aug 26 01:24:36 Anyway, I'm willing to hear other ideas. So far it seems using bitmap + aligned 256 byte blocks as easiest and nearly optimal Aug 26 01:27:20 the only easy format i can think of for byte aligned reads would be a 8k bitmap, 1 bit per byte Aug 26 01:27:47 you'd have to read two places in the file if you wanted to extract one icon, but you already have to do that Aug 26 01:28:46 but i agree that perhaps it doesn't make much difference and 256 aligned reads are just fine Aug 26 01:41:02 honestly, using an 8k bitmap for a 65k max file is a bit overkill Aug 26 01:41:20 Especially since many of them will be less than 8k in the first place :P Aug 26 01:41:31 Or even all of them Aug 26 01:42:07 Regions can be made to work nicely, but too painful Aug 26 01:44:08 kristen: So lets do the 8 byte bitmap approach, if the filesystem supports holes then we have our cake and icing on top Aug 26 02:36:38 denkenz: Could you please advise us some modems via email? **** ENDING LOGGING AT Thu Aug 26 02:59:57 2010