**** BEGIN LOGGING AT Fri Sep 02 02:59:57 2011 Sep 02 06:44:12 ok, yet again, i'm going to ask if there is a spot in the official wikis for linking to documentation of non-manufactured phones. i'm representing a recycling company, willing to host images and hack devices, as best as possible. Sep 02 06:45:12 right now i'm staring at an arm9 235mhz, with 32 megs of ram, in an nokia e62. i'm fine with giving up on the device... but i'd like to really expand the 'device porting' stuff on the wiki, as what i've found is VERY lacking. Sep 02 06:50:34 hmm. in reality, i guess i'm asking for a trac account on shr-project.org, so i can edit the device porting guide. Sep 02 06:50:44 i mean, is there no "status" on devices page? Sep 02 06:50:56 * juri_ sighs. Sep 02 06:51:04 This is Not OpenWRT. ;) Sep 02 06:53:18 I'm looking for somewhere to link information about the various phones i'm scrapping down, and a place to report statuses of SHR on my 1973s. Sep 02 06:53:53 * juri_ makes a lot of noise. :) Sep 02 07:03:00 juri_: wiki.openwrt.org seems like a reasonable enough choice. Sep 02 07:03:08 Ahem, wiki.openmoko.org i meant :) Sep 02 07:03:39 ;) Sep 02 07:03:45 *ahem*. ;) Sep 02 07:05:12 wiki.openmoko makes sense, theres almost something resembling a list there. just. not. really. me being me, i want to document a lot of devices that won't make it... openwrt and coreboot have policies of letting me document on their wikis, but the photos have to pull off of my wiki, which is fine. Sep 02 07:08:59 wtf? Sep 02 07:09:44 I take high resolution photos of the equipment being destroyed here, so that people can see what chips, connected how, etc. Sep 02 07:11:44 /join #qi-hardware Sep 02 07:12:45 http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers there should be a niche for you Sep 02 07:13:26 and afaik they are happy with highres and even videos on their wiki Sep 02 07:21:39 DocScrutinizer: hey, good morning :) Sep 02 07:21:50 moo paul Sep 02 07:24:10 hey :) Sep 02 07:25:55 hey JaMa|Off Sep 02 09:12:10 SHR: 03Martin.Jansa 07shr-chroot * rc8748a9902a4 10/ (915 files in 73 dirs): system upgrade Sep 02 12:23:05 hmm size looks good :) -rwxr-xr-x 1 bitbake bitbake 186028 Sep 2 14:17 tmp/deploy/images/nokia900/u-boot-nokia900-2011.06+gitr2+b1af6f532e0d348b153d5c148369229d24af361a-r0.bin* Sep 02 14:05:13 Is it known already that latest shr-core on gta02 kernel-panics when the user first touches the screen? Sep 02 14:11:35 JaMa|Wrk: ^^^ - ts patches? :D Sep 02 14:12:06 heyho Sep 02 14:12:10 GarthPS: ping Sep 02 14:17:00 morphis: pong Sep 02 14:17:11 GarthPS: I just read your mail Sep 02 14:17:21 what are the problems with the fso-installer? Sep 02 14:19:07 morphis: a new palmpre plus user (french one) came to us saying that wurrently the howto does not work with the current head makefile as you introduce a new variable BOOT_PARTITION = ${BOOT_PARTITION} Sep 02 14:19:30 how this is supposed to be used ? Sep 02 14:20:25 does the use launch the makefile defining it or did you wanted to define it in the makefile but forgot to do so ? Sep 02 14:20:37 hm Sep 02 14:20:42 it should be define in the targetspecific part Sep 02 14:20:46 with which parameters he use the makefile? Sep 02 14:20:49 yes Sep 02 14:21:25 BOOT_PARTITION has a default value which is only adjusted when needed Sep 02 14:21:48 morphis: wrong... Sep 02 14:21:56 or you missed something Sep 02 14:21:59 yes Sep 02 14:22:05 I missed something ... Sep 02 14:22:06 my bad Sep 02 14:22:19 will push it in a minute Sep 02 14:22:45 morphis: if I am right you just addded its definition for the veer not for other devices Sep 02 14:22:49 tha is right ? Sep 02 14:23:35 yes Sep 02 14:23:41 freesmartphone.org: 03morphis 07utilities * r9cd5f605125b 10/palmpre/fso-installer/Makefile: fso-installer: set default value for ${BOOT_PARTITION} Sep 02 14:23:52 the commit above fixes this with setting a default value Sep 02 14:24:03 and not doing a BOOT_PARTITION = ${BOOT_PARTITION} anymore Sep 02 14:24:18 which was my bad due to a search&replace Sep 02 14:25:09 morphis: ok thx ! all good for me Sep 02 14:25:16 great Sep 02 14:25:22 but about your oe problem Sep 02 14:28:36 GarthPS: what goes wrong when you build aurora? Sep 02 14:29:25 morphis: I am relaunching it.. it seems i am progressing Sep 02 14:29:37 ok Sep 02 14:29:56 as I rebuild the whole image two times in the last weeks and it works fine for me Sep 02 14:30:54 morphis: how did you setup your environnement? (I f this build pass here then I will have a working reproductible way for building aurora) Sep 02 14:31:24 I am not building with a chroot Sep 02 14:31:29 (but I should do) Sep 02 14:31:44 the rest build env stuff I can put online somewhere Sep 02 14:34:04 morphis: I am building with shr-chroot and the makefile I adapted from shr for aurora Sep 02 14:34:22 * GarthPS NOTE: Running task 1111 of 7259 Sep 02 14:34:23 ok Sep 02 14:35:07 dos1: posible.. as I said.. haven't tested it in runtime yet :/ Sep 02 14:35:27 morphis: so if this work I will update the wiki . perhaps then it could be good to right somewhere that we have a makefile to build aurora Sep 02 14:35:38 yes Sep 02 14:36:10 maybe we should not use the same chroot as SHR as we have oe-classic and already had troubles with bitbake because of this Sep 02 14:37:00 mickey|office: heyho Sep 02 14:37:46 GarthPS: your tried the aurora beta release on your pre 2? Sep 02 14:38:24 morphis: yop I sent bug repports in the tracker Sep 02 14:38:45 ok Sep 02 14:38:51 * JaMa|Wrk booting u-boot master just fine :) Sep 02 14:39:02 GarthPS: about the touchscreen-button-click issue Sep 02 14:39:12 can you explain it a little bit more Sep 02 14:39:24 is it a issue with the touchscreen or with the aurora ui? Sep 02 14:39:28 is it the same in SHR? Sep 02 14:45:06 morphis: you speak about this one http://trac.freesmartphone.org/ticket/653 . no it is clearly not the same under SHR. Under SHR it works wuick fine apart some weird behaviour some times. under aurora it seems more like an UI issue but as I can not test with something else in aurora.. but it is like buttons are not clickable.. i will try to make a video of it . it will be better Sep 02 14:45:33 they are not clickable or just hard to click? Sep 02 14:45:43 whats with the numbered buttons in the dialer? Sep 02 14:45:58 is their a difference between the dial button and the numbered buttons? Sep 02 14:48:40 morphis: hard to click , I need to touch/click a longtime and relase it in a certain way Sep 02 14:48:57 morphis: hm perhaps.. don't remember Sep 02 14:50:23 morphis: heya! how's it? Sep 02 15:06:39 SHR: 03Martin.Jansa 07meta-smartphone * ree4b7f930f4f 10/meta-nokia/recipes-bsp/ (22 files in 4 dirs): u-boot: upgrade to 2011.06 and refresh patches from Ali Sep 02 15:09:06 looks like it's time to upgrade u-boot :) Sep 02 15:09:18 JaMa|Wrk: thanks for your efforts! Sep 02 15:13:49 wait a bit for keymaps fix :) Sep 02 15:14:18 and thanks to ali who published newer patchset :) next time I'll try bootmenu support from pali Sep 02 15:20:45 dos1: now it's time to build :) Sep 02 15:20:51 SHR: 03Martin.Jansa 07meta-smartphone * rc4d06016870a 10/meta-nokia/recipes-bsp/keymaps/ (keymaps/keymap-2.6.map keymaps_1.0.bbappend): meta-nokia: keymaps: add keymap for nokia900 Sep 02 15:21:52 GarthPS: ok, thats a UI bug Sep 02 15:22:01 GarthPS: btw. halt/reboot is fixed for palmpre Sep 02 15:22:11 but I need to push the commit to upstream Sep 02 15:22:18 its only fixed in Aurora Sep 02 15:22:29 morphis: ah ok yeah pls Sep 02 15:22:52 will do that later Sep 02 15:23:05 morphis: about my mail so could you fis the oe thing for msmcommd ? Sep 02 15:23:10 sure Sep 02 15:26:50 JaMa|Wrk: is bootmenu something like u-boot menu on gta01/02? Sep 02 15:26:55 GarthPS: I will try but I don't have the issue here Sep 02 15:29:09 morphis: hmm perhaps it is efl version related issue.. as this http://git.shr-project.org/git/?p=shr-makefile.git;a=blobdiff;f=Makefile;h=5becc7a43a99adefeb6c11d82a39e8532631712e;hp=b5d4e1e0639b54072fd3187ed84d2fce9ca972fb;hb=dd6836e879936be479acb495531f874adc5a8c27;hpb=675801450326ce24736323436199abd3eed9417f Sep 02 15:29:49 morphis: forgot this sorry my bad, my issue is about val.. Sep 02 15:29:52 vala Sep 02 15:32:54 dos1: yes Sep 02 15:39:07 GarthPS: can you tell me if the issue still exists with your current rebuild? Sep 02 15:41:53 morphis: the issue of my mail is for building SHR for pre2 and yes it is currently happening Sep 02 15:42:02 GarthPS: ok Sep 02 15:42:12 so it's SHR Sep 02 15:42:18 morphis: yes Sep 02 15:47:44 GarthPS: pushed to upstream Sep 02 15:50:04 dos1: btw have you seen /dev/tty2 gone when all other tty* devs were there and Xorg failing to attach tty2? Sep 02 15:50:31 JaMa|Wrk: where? Sep 02 15:50:36 JaMa|Wrk: no, i haven't Sep 02 15:50:56 dos1: n900 Sep 02 15:51:25 JaMa|Wrk: no, i don't have any problems with X Sep 02 15:51:39 dos1: and what's VRFB? :) Sep 02 15:51:54 JaMa|Wrk: rotation Sep 02 15:52:00 ah ok Sep 02 15:52:18 JaMa|Wrk: i have added params to kernels cmdline to have screen in portrait mode Sep 02 15:57:09 ic Sep 02 15:57:13 gtg Sep 02 18:12:21 morphis: thx ! shr for my pre2 built! Sep 02 18:12:30 with old shr-u Sep 02 18:12:38 yeah! Sep 02 18:12:53 GarthPS: please check if halt/reboot is working Sep 02 18:13:31 morphis: ok I will. then i will finish to build for aurora (a recipe is broken for the moment) Sep 02 18:14:22 GarthPS: you're building aurora from aurora/development branch? Sep 02 18:15:17 morphis: hmm 2" Sep 02 18:15:56 morphis: yep Sep 02 18:16:52 http://git.freesmartphone.org/?p=aurora-makefile.git;a=blob_plain;f=Makefile;h=c55170766bce4393aafe789e1aa69db4069134f3;hb=HEAD Sep 02 18:29:32 morphis: we have to fix this powerbutton handling. i think that we should revert your commit about filtring all gpio events.. Sep 02 18:30:10 GarthPS: whats your solution then? Sep 02 18:30:17 but for SHR you can do so Sep 02 18:30:25 for Aurora we should not Sep 02 18:30:43 morphis: ok . I would do that http://trac.shr-project.org/trac/ticket/1401#comment:3 Sep 02 18:32:31 GarthPS: ok Sep 02 18:32:57 GarthPS: maybe good to know: I am currently creating a fsoeventsd which will be the replacement for oeventsd Sep 02 18:38:03 morphis: Hi! Sep 02 18:38:07 angelox|laptop: heyho Sep 02 18:38:50 angelox|laptop: we need to talk about the future development of aurora Sep 02 18:38:54 hi Sep 02 18:39:21 morphis: sure,when? Sep 02 18:39:33 not today Sep 02 18:39:45 I will start creating a wiki page for the next version Sep 02 18:39:52 I would like to get a 2011.12 release out Sep 02 18:40:20 JaMa|Off: hi Sep 02 18:40:38 gnutoo: heyho Sep 02 18:40:51 could someone try my patch for ubifs on om-gta02? Sep 02 18:40:54 hi Sep 02 18:41:07 morphis: that would be great,and good too if we include some other funcionality (settings app?)... Sep 02 18:41:13 btw,hi gnutoo :) Sep 02 18:42:21 hi Sep 02 18:45:12 morphis: btw,i did see your messages in mailing lists,and Timo Jyrinki asked for putting Aurora's photos in Aurora's main page,may i do that? Sep 02 18:45:42 angelox|laptop: yeah, that would be nice Sep 02 18:45:57 angelox|laptop: jepp we should definitly include the settings app Sep 02 18:46:17 gnutoo: hi, which ubifs patch? Sep 02 18:46:19 morphis: ok,then i'll hurry with settings app Sep 02 18:46:56 morphis: ok good to know. hmm reboot does not work here.. at least called by /usr/bin/phoneui-quick-settings. how could I check that our changes are there . Sep 02 18:47:05 radekp: something for oe-core Sep 02 18:47:15 GarthPS: check /etc/init.d/unmountfs Sep 02 18:47:22 basically the volname wasn't set Sep 02 18:47:23 gnutoo: ahh oki Sep 02 18:48:59 btw i'd like to package qtmoko for SHR, any ideas how should i start? Sep 02 18:50:55 radekp: you need to create recipes for OE Sep 02 18:51:27 morphis: i have to build shr from sources to do it? Sep 02 18:51:35 yes Sep 02 18:51:59 radekp: talk to JaMa about this Sep 02 18:52:04 i ma now reading http://shr-project.org/trac/wiki/Building%20SHR Sep 02 18:52:41 oki, thanks, i will ask him when he is here Sep 02 19:00:30 morphis: I have this http://pastebin.com/raw.php?i=Gt27z8zi Sep 02 19:00:53 OT: Dialer word exists ? Sep 02 19:04:37 GarthPS: should look like this: http://git.freesmartphone.org/?p=openembedded.git;a=blob;f=recipes/initscripts/files/palmpre/umountfs;h=45d4c2ff6cf4b6c5305e766d375ed7ab9b3e0061;hb=e7a25ecfbdf6525d21793be6bfeea03ac4bd8f0c Sep 02 19:04:45 GarthPS: maybe you should rebuild task-base Sep 02 19:04:51 or initscripts Sep 02 19:10:01 bbs Sep 02 19:11:24 morphis: then for settings app i'll include basic things,ok? Sep 02 19:12:35 yes Sep 02 19:16:07 bonsoir :) Sep 02 19:16:28 nabnd Sep 02 19:17:18 mickeyl: sorry I was not able to look over those papers Sep 02 19:17:56 mrmoku: no problem, i think we covered the most important aspects @ FrOSCon Sep 02 19:18:17 there wasn't room enough to go into details of every project anyways Sep 02 19:18:31 otherwise successful? Sep 02 19:18:47 ya, i think it went very well Sep 02 19:18:51 good :) Sep 02 19:19:08 hi Sep 02 19:19:45 hi gnutoo Sep 02 19:20:20 mickeyl: heyho Sep 02 19:20:22 ./window 3 Sep 02 19:20:35 window 3 not found Sep 02 19:20:43 +s +.11 Sep 02 19:20:53 irsirssi... Sep 02 19:20:54 but that was long ago ;) Sep 02 19:21:37 morphis: which non-functional areas would the veer with aurora atm.? Sep 02 19:24:51 freesmartphone.org: 03angelo 07angelox/testing * r1d9b16867388 10aurora/aurora-applications/app-settings/SettingsPage.qml: aurora-settings: remove GPS from Settings page Sep 02 19:25:35 mickeyl: modem, audio, ... Sep 02 19:25:39 mickeyl: why? Sep 02 19:25:47 mickeyl: you want it supported? Sep 02 19:26:20 morphis: i don't know. i love the form factor, really. but if it's a dead-end as well, i wonder whether it's worth the work Sep 02 19:26:41 it's fully msm Sep 02 19:26:56 and I don't think its worth the work Sep 02 19:27:25 I love the form factor too but they should have choosen a omap3/4 for the device Sep 02 19:27:39 not a crappy msm architecture Sep 02 19:27:56 btw. my audio issues are still their Sep 02 19:28:02 audio echo for the remote party Sep 02 19:28:44 so that's why they sell that very cheap.... Sep 02 19:29:14 might be a tribute to the form factor Sep 02 19:29:27 although there are some small MOTO phones that manage that without any echo Sep 02 19:30:45 yes Sep 02 19:30:55 but you can't buy one anymore Sep 02 19:31:03 so the phones are a really dead end Sep 02 19:31:18 mickeyl: btw. I received my new day-work smartphone yesterday Sep 02 19:31:21 mickeyl: a Nexus S Sep 02 19:31:51 mickeyl: I will not do much work on it but the architecture sounds very interesint Sep 02 19:32:13 mickeyl: but we should still stay with our aim to get the gta04 working Sep 02 19:32:15 hardware architecture or android? Sep 02 19:32:19 and to be our main target Sep 02 19:32:27 mickeyl: hardware architecture Sep 02 19:32:34 a s5p chip from samsung Sep 02 19:32:40 modem from infinion Sep 02 19:32:46 intel Sep 02 19:33:08 still with their own protocol but it's already reversed and working Sep 02 19:33:54 mickeyl: and we should start to get meeting with the core developers done to create a strategy for further development Sep 02 19:34:06 yes. i'll send the promised mail out this weekend Sep 02 19:34:11 great Sep 02 19:34:24 I am currently very busy during the weeks Sep 02 19:34:45 I think we should select the new targets(not gta02)with the possible and real bugs.... Sep 02 19:35:23 in other words what will require time Sep 02 19:35:37 gnutoo: my opinion is we should focus on not more than three devices Sep 02 19:35:44 palmpre, gta04 and n900 Sep 02 19:35:47 and what won't Sep 02 19:35:50 get them working and supported Sep 02 19:36:19 switching for a current phone from today to the current phone of tomorrow doesn't work Sep 02 19:36:23 what about gta02? Sep 02 19:37:03 it should be supported too Sep 02 19:37:04 apart gta02: n900,nexus S if good,gta04 Sep 02 19:37:35 yes, but as core developers we should try to evolve the platform too and not only the hardware support Sep 02 19:37:47 I cannot juge the palmpre but it seem buggy Sep 02 19:37:51 and thats what we're doing mostly in the last years Sep 02 19:38:11 gnutoo: hardware or software? Sep 02 19:38:11 like neon issues, wifi issues etc.... Sep 02 19:38:21 no idea.... Sep 02 19:38:25 it works Sep 02 19:38:32 some rough edges, yes Sep 02 19:38:33 core software I guess Sep 02 19:38:55 htcdream works too, altough it's unusable at the end Sep 02 19:38:58 aurora works fine on the palmpre Sep 02 19:39:05 ok Sep 02 19:39:12 what about mplayer,vlc etc... Sep 02 19:39:16 and gives you a good and working telephony experience Sep 02 19:39:23 ah? Sep 02 19:39:36 you can make calls Sep 02 19:39:36 I never tried aurora Sep 02 19:39:59 I tought about SHR when I told that the palmpre was buggy Sep 02 19:40:02 morphis: can x applications be launched within aurora or is it a fullscreen shell? Sep 02 19:40:19 mplayer, vlc are nice when they are working but we should shrink our focus to a minimum we can support Sep 02 19:40:27 Alex[sp3dev]: Aurora doesn't use X Sep 02 19:40:34 it's a fullscreen shell Sep 02 19:40:37 on n900 they are working Sep 02 19:40:57 yes but what do we want to do with this devices? Sep 02 19:41:03 n900 only lacks some telephony + uboot stuff Sep 02 19:41:13 everything.... Sep 02 19:41:15 first we want them for telephony Sep 02 19:41:32 everything, we can't archive this .. Sep 02 19:41:51 it's not the right time to get everything working Sep 02 19:41:55 ah? like SHR? Sep 02 19:42:17 SHR is not good? Sep 02 19:42:25 SHR is good Sep 02 19:42:40 but it tries to solve too many things at once in my opinion Sep 02 19:42:48 why not make a debian repository with nightly builds so that users can have all software (vlc, mplayer) for free from debian? in which way would building debian images be harder than openembedded? Sep 02 19:43:08 which are not obtimizated.... Sep 02 19:43:12 yes Sep 02 19:43:21 thats what I want to archive with aurora Sep 02 19:43:32 concentrate on small feature sets we can support very well Sep 02 19:43:58 ok Sep 02 19:44:00 and don't try to support things we can not support cause of time/bugs/... Sep 02 19:44:11 shr is a bit larget.... Sep 02 19:44:20 *larger Sep 02 19:44:23 yes Sep 02 19:44:35 and makes it harder to get new feature in Sep 02 19:44:41 s/feature/features/ Sep 02 19:44:42 morphis meant: and makes it harder to get new features in Sep 02 19:44:54 depend on the feature.... Sep 02 19:45:13 do you have an example of feature? Sep 02 19:45:55 like network management Sep 02 19:46:02 lot's of features one get's mostly free... like terminal+ssh Sep 02 19:46:12 (which is a very important one for me personally) Sep 02 19:46:18 yes Sep 02 19:46:29 ah you have all that in aurora? Sep 02 19:46:38 or is it just planed? Sep 02 19:46:50 currently not but the comprimized structure makes it possible to integrate it very fast Sep 02 19:46:52 networkmanagement should be for free too... at least connman+plugins in e are supposed to work Sep 02 19:47:07 in SHR I have to create E gadgets, applications with complex build structure .. Sep 02 19:47:20 ok, what about GPS routing support for instance.... Sep 02 19:47:30 can it be integrated easily? Sep 02 19:47:31 yes but it feels not made like for a phone Sep 02 19:47:38 why not Sep 02 19:47:43 navit works fine on shr Sep 02 19:47:48 creating a new application for aurora is simple Sep 02 19:47:56 it's not about replacing SHR Sep 02 19:48:00 ah? Sep 02 19:48:01 yeah Sep 02 19:48:06 those are alternatives Sep 02 19:48:07 if you're fine with SHR stay with it Sep 02 19:48:20 I want some playground where I can add features to FSO very fast Sep 02 19:48:20 featurephone vs. smartphone Sep 02 19:48:24 yes Sep 02 19:48:35 ok Sep 02 19:48:37 comprimized feature set not very extensible Sep 02 19:48:43 but working and mostly bug free Sep 02 19:48:55 ok nice... Sep 02 19:49:06 and very easy to port to new devices Sep 02 19:49:12 radekp: why do you want to package qtmoko for SHR? Sep 02 19:49:19 what device can I try it on? Sep 02 19:49:28 qtmoko for shr...nice Sep 02 19:49:42 antrik: for testing FSO Sep 02 19:49:52 maybe if it uses oe+fso it could be so nice.... Sep 02 19:50:01 gnutoo: Aurora? Sep 02 19:50:31 hmmm Sep 02 19:50:46 for me it's a nice thing to try and an alternative... Sep 02 19:51:11 I'm not sure I want to switch to qtmoko for real on all phones Sep 02 19:51:17 it lacks X Sep 02 19:51:35 but it's a good thing to see it "in the right direction" (subjective) Sep 02 19:53:03 btw. I started to port aurora to oe-core Sep 02 19:53:49 ok nice Sep 02 19:53:57 maybe I could try it soon then? Sep 02 19:54:10 maybe Sep 02 19:54:15 morphis: about that we will have to speak about the makefile, of it future.to know what worse the most. Sep 02 19:54:24 I don't know how good the python support is in oe-core these days Sep 02 19:54:31 GarthPS: for sure Sep 02 19:54:35 GarthPS: but it will take some time Sep 02 19:54:46 and the old oe-classic branch will stay active Sep 02 19:54:52 as long as the port is not done Sep 02 19:55:17 mickeyl: still here? Sep 02 19:55:28 I don't think I will validate the current make file this evening(TVtime with my love) but this weekend. but then it is base on old oe Sep 02 19:55:40 ok goo for me Sep 02 19:55:57 radekp: judging by the myriads of bugs mentioned here over tha past couple of months, FSO support in SHR doesn't actually seem to be great... Sep 02 19:56:57 antrik: i have it now working (QtMoko on top of SHR) so i can switch this setup to my primary phone and test it ;-) Sep 02 19:57:38 antrik: what do you mean with "FSO support in SHR doesn't seem to be great"? Sep 02 19:57:45 do you think this is easier than getting FSO stuff in Debian-based QtMoko?... Sep 02 19:59:06 morphis: well, judging by the various problem reports, it seems that SHR is not really usable on *any* phone with any recent build... Sep 02 19:59:22 ok Sep 02 19:59:41 can you give me an example? Sep 02 20:00:09 antrik: recent builds are not suitable to make such assumptions based on them Sep 02 20:00:16 antrik: as SHR is now in big transition Sep 02 20:00:22 old OE vs. oe-core Sep 02 20:00:32 SHR: 03morphis 07meta-smartphone * r613279b9bfa9 10/meta-palm/conf/machine/include/palmpre.inc: meta-palm: update machine description for palmpre machine class Sep 02 20:00:34 morphis: May i create a branch for 2011.12? That way it will be better to code (mainly the settings app) ? Sep 02 20:00:36 SHR: 03morphis 07meta-smartphone * r1780b5f72e06 10/meta-palm/recipes-bsp/u-boot/u-boot_git.bbappend: meta-palm: remove old and unneeded u-boot bbappend file Sep 02 20:00:42 angelox|laptop: no Sep 02 20:00:49 angelox|laptop: do your development in the main branch Sep 02 20:00:52 shr-unstable being to be obsolete Sep 02 20:00:59 but shr-core is not yet really useable Sep 02 20:01:02 angelox|laptop: but we should talk about various aspects in the near future Sep 02 20:01:03 morphis: ok,thanks! Sep 02 20:01:11 antrik: so maybe that's why you have such opinion Sep 02 20:01:34 antrik: and I don't see the problem on FSO's side Sep 02 20:01:48 FSO is still not perfect but mostly working Sep 02 20:01:50 morphis: on gta02 for example SD and accelerometers are unusable with the current kernel(s), there are problems with SMS, IIRC there are some problems with telephony too... and a number of other issues I don't remember right now Sep 02 20:02:11 are there bug reports for the SMS problems? Sep 02 20:02:17 and for telephony? Sep 02 20:02:25 if there are bugs in FSO we should fix them Sep 02 20:02:36 not sure... probably. Sep 02 20:02:57 I haven't tested this myself; I'm only going by the various problem reports I have seen in here over the past couple of months Sep 02 20:03:03 ok Sep 02 20:03:28 as far as i can tell FSO was working quite fine when i was integrating it with qtmoko Sep 02 20:04:12 antrik: here is one: http://trac.freesmartphone.org/ticket/654 Sep 02 20:04:29 i wasnt able to read SMS messages on SIM, but the PIM api was working good, so i am using PIM api now in qtmoko Sep 02 20:04:53 yeah :) Sep 02 20:05:36 :) Sep 02 20:05:37 btw i think i have found one flaw in the FSO API design Sep 02 20:05:46 radekp: you mean FSO-based QtMoko can't deal with messages on SIM? Sep 02 20:07:09 radekp: what flaw? Sep 02 20:07:26 antrik: it uses the PIM api for reading & receiving SMS - i think the SMS go to database and are not stored on sim Sep 02 20:08:11 dos1: the functions for getting various statuses and signals can IMO produce race conditions Sep 02 20:08:37 dos1: e.g. when my phone app starts i want to GetDeviceStatus() Sep 02 20:09:14 and during the call DeviceStatus signal comes with some changed status Sep 02 20:09:33 then GetDeviceStatus() finishes with old status Sep 02 20:10:20 the new status which was delivered with the DeviceStatus signal is then forgotten Sep 02 20:10:31 radekp: that is a bug Sep 02 20:10:48 radekp: hmm Sep 02 20:11:00 well i havent hit it - but IMO it can theoretically happen Sep 02 20:11:04 radekp: well, I don't know how many of the problems are with FSO itself, and how many with FSO integration in SHR... my point is that I'm not convinced SHR is a good base for anything right now Sep 02 20:11:10 radekp: ah ok Sep 02 20:11:26 (but then, I'm biased, as I generally consider smartphone distros based on OE rather than Debian a bad idea...) Sep 02 20:11:27 theoretically yes, but it depends on how your application handles this Sep 02 20:12:56 morphis: i register the DeviceStatus signal and then call GetDeviceStatus() Sep 02 20:13:18 morphis: i dont think there is other way how to handle this Sep 02 20:13:57 but when do you execute GetDeviceStatus(), on startup? Sep 02 20:14:05 antrik: i prefer debian myself too ;) Sep 02 20:14:30 morphis: yes, i need to know the current device status when i start my phone app Sep 02 20:15:42 then you should finish processing the result of the GetDeviceStatus and then process the signal Sep 02 20:16:52 morphis: hmm you are probably right, maybe it's just problem of my implementation, because i call GetDeviceStatus() asynchronously Sep 02 20:17:12 you can still call it asynchronously Sep 02 20:17:23 but then implemented some initialized flag Sep 02 20:17:36 yup Sep 02 20:17:41 and while it's false you don't process any signal or defer the handling of them Sep 02 20:18:15 btw it would be nice to know which FSO functions are "fast" and which one are slow Sep 02 20:20:05 e.g. if the function just returns some variable then i can call it synchronously, if it does something more time consuming (like sending modem AT command) then it's candidate for async call Sep 02 20:20:28 you can expecting something like GetDeviceStatus() to be very fast Sep 02 20:20:40 most get method should be fast Sep 02 20:20:48