**** BEGIN LOGGING AT Thu Jun 04 02:59:58 2009 Jun 04 02:59:58 DocMobilizer: yeah, likely. still, seems to be a rather sweeping condemnation of a whole country. Jun 04 03:00:35 I just said I'm happy I never went to there Jun 04 03:02:39 and actually I don't like our politicians thinking with olympic games and transrapid they could change anything, or just pretend it never happened Jun 04 03:03:15 * mwester has a whole list of places he wishes never to have to go to, and he hopes that's not a condemnation of those who _do_ enjoy living there. (Although it does rather seem that for some of those places, the people don't seem to like to live there themselves.) Jun 04 03:06:00 i'd rank all those countries where you can't go to a bar and try to pick up some girls pretty high in my list of "no go" places :) Jun 04 03:06:40 hmm, US is on my list for different reasons Jun 04 03:06:55 the mere police states don't scare me so much anymore, since those that aren't yet seem to be hellbent on catching up anyway ... Jun 04 03:07:19 tho root cause might be related to your bar-situation as well Jun 04 03:08:48 DocMobilizer: yeah, too many fat girls and ridiculous closing hours at the bars :) Jun 04 03:09:21 btw took me some hours to fix the antenna. So I'm in a rather unforgiving mood now anyway Jun 04 03:10:40 mwester: you'd be amazed how patronizing those closing hours feel to someone who comes from a culture where no such concept exists. (well, they do kick you out at dawn in most places in europe and even south america.) Jun 04 03:10:49 DocMobilizer: what antenna ? Jun 04 03:12:49 my TV antenna. was broken when I tried to watch TV at 23:00 Jun 04 03:14:12 DocMobilizer: oh, anything good on ? Jun 04 03:15:15 now it works better than ever (not that I'd notice that on DVB-T). But wasn't quite conclusive *which* one of my neighbours to shoot down for that Jun 04 03:17:46 DocMobilizer: eliminate the doubt and kill 'em all :) Jun 04 03:18:23 DocMobilizer: and if you get caught, the increased cost is marginal :) Jun 04 03:18:53 lol, right Jun 04 03:19:44 even better, makes a mental disorder more likely Jun 04 03:21:40 yeah, quantity discount :) Jun 04 03:23:42 strange thing: I wasn't able to just fix it, had to do a major rework to put it to function again. So I really wonder what else they did than just pulling the one PL59 plug Jun 04 03:26:48 especially in the night between 9 and 11 Jun 04 03:27:28 DocMobilizer: you seem to check your tv quite regularly. can't be too careful with those pesky neighbours ;-) Jun 04 03:28:31 It's constantly on, so I don't forget about the sound of spoken word ;-) Jun 04 03:39:46 DocMobilizer: keeping a watch on the nation :) Jun 04 06:19:59 Bleeeeh Jun 04 06:20:16 I was pretty sure this hour didn't exist Jun 04 06:22:20 it doesnt Jun 04 06:22:24 you are sleeping Jun 04 06:22:53 or if it suits your state of mind better... hallucinating Jun 04 06:23:40 Ainulindale, turn around and be quiet ;) Jun 04 06:24:12 roh: I doubt that, I wouldn't dream about you, you don't have breasts for starters Jun 04 06:25:44 mrmoku|a`: checking my idea about RRECOMMENDS for tangogps Jun 04 06:26:10 (RRECOMMENDS_shr = "fso-gpsd" Jun 04 06:26:11 ) Jun 04 06:26:59 Ainulindale hrrr Jun 04 06:30:56 Ainulindale, good luck... off to work now :( Jun 04 06:33:52 nasty dream Jun 04 06:34:52 even a nightmare Jun 04 06:36:48 had no luck to boot SHR for 6 times now. "DBus borked", no GSM, Backlight at "2%" while full brightness. Dunno, maybe "best before" expired for this flash Jun 04 06:38:47 maybe suspend-timer=0 makes frameworkd go nuts Jun 04 06:39:19 something wrong and odd with these timers anyway Jun 04 06:42:42 plus TZ refuses to return to normal, after it was set to GB/London yesterday when system was booted with a T-Mobile SIM. I wonder how it ever could have been right before, but evidentally was Jun 04 06:43:47 fix TZ by replacing /etc/localtime Jun 04 06:44:11 hehe, for now I deleted it Jun 04 06:44:24 and /etc/timezone of course Jun 04 06:44:53 cp /usr/share/zoneinfo/... /etc/localtime Jun 04 06:45:05 hoped it would do same thing it did when first booted (with O2 SIM). TZ was correct then (well at least time was) Jun 04 06:46:46 strange how time switched from CEST to UTC on a T-Km SIM, but then never reverts to the good CEST it had initially with O2 Jun 04 06:47:36 the whole freaking concept of automatic TZ switching is braindead Jun 04 06:48:52 and I repeat my request to disable it by default, and have a manual config on first boot instead Jun 04 06:51:01 also the Date/time settings could use a TZ selector as well - in addition to any means to actually read/set the *Date* (as supposed by caption of this window) Jun 04 06:51:53 heheh, yup Jun 04 06:52:08 what a joke was this to code a time setting and forget about the date? :-D Jun 04 06:52:59 there's no need to have a separate current time display, combine the two Jun 04 06:53:07 that'll give enough room to set the date Jun 04 06:53:36 ffalarm has a much more user friendly "time set" Jun 04 06:53:40 if only for the alarm clock Jun 04 08:23:05 tracfeed: gps.log.gz attached to Ticket #503  || Ticket #503 (wrong speed in shr-settings gps module) created Jun 04 08:24:37 hello there Jun 04 08:24:39 tracfeed: Screenshot-3.png attached to Ticket #503  || Screenshot-4.png attached to Ticket #503 Jun 04 08:27:13 i have new crashes of messages + contacts, with dbus calls timing out. Should i append to a given ticket or open a new one? Jun 04 08:27:45 ah, i just reproduced it : dbus.exceptions.DBusException: org.freesmartphone.GSM.SIM.NotFound. Jun 04 08:28:15 now the dbus call works.. Jun 04 08:28:22 There seems to be a problem building shr-unstable at the moment: http://pastebin.com/m1156b4f7 Jun 04 08:49:51 ChristW: what's the log? Jun 04 08:49:53 Here it worked Jun 04 08:56:53 MarcOChapeau \o/ Jun 04 08:59:09 good morning :) Jun 04 09:00:20 Ainulindale: Where can I _find_ the log? Jun 04 09:00:45 ChristW: well what you just pasted tells you where :-) Jun 04 09:00:57 Ainulindale: I'm currently giving a ride to shr unstable Jun 04 09:01:00 /home/christ/openmoko/sources/shr-unstable/tmp/work/armv4t-angstrom-linux-gnueabi/gtk+-2.14.2-r1/temp/log.do_compile.23078 <= Jun 04 09:05:07 Hmmm, figures :-) Jun 04 09:05:13 I've updated the pastebin. Jun 04 09:05:15 MarcOChapeau: good! :-) Jun 04 09:05:42 weird you're using /bin/ld Jun 04 09:05:53 Are you sure you make update, and dit . setup-env ? Jun 04 09:07:18 I did 'make update' this morning. Perhaps the setup-env was missing. I did that, and am now bit-bakeing again. Jun 04 09:07:50 well if it uses system tools it's obviously wrong Jun 04 09:08:00 so either the recipe is wrong which I'm sure isn't the case as it worked perfectly here Jun 04 09:08:04 Or you forgot to do something Jun 04 09:08:09 Or someone forgot to tell you to do something Jun 04 09:08:15 Which sounds more likely :-m) Jun 04 09:08:17 -m Jun 04 09:15:07 Hmm, it still fails... Jun 04 09:15:24 Let's do this step by step then. I am in openmoko/sources and run 'make update' Jun 04 09:15:43 Then, I cd to shr-unstable and do . setup-env Jun 04 09:15:51 Then, I 'bitbake navit' Jun 04 09:16:11 Anything I missed? Jun 04 09:16:57 Nothing supposedly but you need to clean gtk now Jun 04 09:17:03 As it has been configured probably with a wrong path Jun 04 09:17:23 so bitbake -c clean gtk+ Jun 04 09:17:54 And (may pb__ smite me if I'm wrong), the former path is kept Jun 04 09:18:02 As long as you don't reconfigure Jun 04 09:18:24 (I'm off for a jiffy) Jun 04 09:18:27 (keep me in touch) Jun 04 09:27:51 hello again Jun 04 09:30:47 Still 'the same' arror message... perhaps this is a pointer: .libs/libgdk_pixbuf-2.0.ver:2: ignoring invalid character `\001' in script Jun 04 09:32:30 Yup, that illegal character is there, alright... Jun 04 09:33:08 It says: { global: ^A; local: *; } Jun 04 09:37:00 Hmmm that's weird Jun 04 09:37:44 It's in libgdk_pixbuf-2.0.ver Jun 04 09:42:15 Ainulindale: i'm still having issues with messages and contact (segfault). should i append my logs to an existing ticket or open a new one? Jun 04 09:42:24 oh, and, hi, btw :) Jun 04 09:42:33 KaZeR_mobi: well what kind of issues? Jun 04 09:42:53 kazer, did you get my email? Jun 04 09:48:04 Ainulindale: contacts and messages segfault at startup. it happens after one call or one message, i haven't yet figured the exact pattern. you can still use dialer and make outgoing call Jun 04 09:48:13 Blu3: not yet, but i was away from internet for a few days. i'm checking mailbox Jun 04 09:50:43 Ainulindale: Strangely enough, I can even see where that ^Acomes from! It gets put in there by some sed command a bit higher in the log file! Jun 04 09:52:08 Do you still have the pastebin link? I've highlighted the line that does that. Jun 04 09:59:02 ChristW: well it changes each time, could you regive it to me? Jun 04 09:59:15 KaZeR_mobi: maybe that's yet another bad pdu case Jun 04 09:59:26 KaZeR_mobi: please open a new ticket and assign it to me with full debug logs for framework Jun 04 09:59:33 KaZeR_mobi: I'll try to help Jun 04 10:00:30 Ainulindale: Not really, since I editted the original one, but I'll copy/paste it anyway: http://pastebin.com/m6c4f7fdf Jun 04 10:01:18 (I don't trust those 'block block block' on line 41 either...) Jun 04 10:01:42 Blu3: any tip about your mail? when did you send it? Jun 04 10:24:24 good morning Jun 04 10:26:17 hola ptitjes ! :D Jun 04 10:27:13 i was really busy due to RL work but i've looked at ophonekitd sources and now i think i've understood how it's work, also the gui Jun 04 10:29:09 heyho Jun 04 10:29:52 m0nt0: good Jun 04 10:30:03 hello morphis Jun 04 10:33:38 what has to be done is discussed in the devel ml, about this "functional" context, right? Jun 04 10:34:34 m0nt0: yep right away :) Jun 04 10:34:45 ok Jun 04 10:34:46 :D Jun 04 10:35:09 so i hope that we get to a decision so we can go on with the new design Jun 04 10:36:32 m0nt0: I'll try to explain better between session-based and session-based protocols later in the afternoon Jun 04 10:36:47 first I must take a coffee Jun 04 10:36:54 yeah, no problem about that Jun 04 10:37:08 m0nt0: I believe that dead line is next week and the one that follows Jun 04 10:37:14 Gotta go (kinda a job interview, I'm without work at the moment. If anyone knows of a place where they can use a C/C++ and/or PHP programmer in (or around) Eindhoven, NL, let me know...) Jun 04 10:37:21 but we need to get to a point, it's about 1 month that the thread appears and disappeas Jun 04 10:38:07 m0nt0: sure Jun 04 10:38:10 ptitjes, good to hear that :D Jun 04 10:38:54 m0nt0: thus don't hesitate to comment on the different mails Jun 04 10:39:31 don't worry about that, i'll explain my opinion if i got one :D Jun 04 11:00:55 I want to devel on SHR, but phone goes to sleep. how to prevent it ? Jun 04 11:01:52 in shr-setting Jun 04 11:01:57 auto-suspend off Jun 04 11:02:12 or via dbus call, which do similar stuff Jun 04 11:05:31 max_posedon: thx Jun 04 11:09:39 ChristW|away: editing creates a new hash on pastebin Jun 04 11:22:16 hello again Jun 04 11:22:49 Ainulindale: no kbd recommendations here. Only got that rubber kbd you probably seen at F9N Jun 04 11:24:31 DocScrutinizer: too bad, can't find any Jun 04 11:24:59 neomilium_[afk]: for me frameworkd does autosuspend-off automagically when usb power connected Jun 04 11:26:02 Ainulindale: every usb-kbd will work I guess. Select form factor to meet your needs Jun 04 11:30:45 Ainulindale, mrmoku|away, m0nt0|pappatime, Deubeuliou: new food on the ML Jun 04 11:36:35 Ainulindale: was I clear enough ? Jun 04 11:39:26 ptitjes: first part is, second part is a bit complicated Jun 04 11:39:38 ptitjes: I just replied to first part, second part I had nothing to say Jun 04 11:39:44 about the selection ? Jun 04 11:39:51 multiple | single ? Jun 04 11:40:07 Nah, the use cases Jun 04 11:40:31 yep multiple contact selection and single contact selection... Jun 04 11:40:38 I thought I was clear Jun 04 11:40:53 I reread that three times before pressing send Jun 04 11:40:54 :( Jun 04 11:41:24 Well I didn't get quite right what you wanted to say with that use case Jun 04 11:41:30 You should sum things up at the bottom or at top Jun 04 11:41:35 In two sentences at most Jun 04 11:42:04 But anyway, I don't think doing a distinction for multiple/single selection is wise Jun 04 11:42:11 We should always assume it may be multiple Jun 04 11:42:15 Then it's up to the requester to handle that Jun 04 11:42:18 (IMHO) Jun 04 11:43:33 hum yeah that is defendable Jun 04 11:44:06 but then how I specify I just want one contact (because I can call only one contact at a time... for now) ;) Jun 04 11:45:22 ptitjes: well the point is Jun 04 11:45:29 you don't have to Jun 04 11:45:37 if you think there is a functional justification to do that Jun 04 11:45:46 as it's the single possible specific thing we may need Jun 04 11:45:54 I'd suggest, let us just put a boolean for that Jun 04 11:46:00 There's no point IMHO in having Jun 04 11:46:03 SelectMultipleContacts() Jun 04 11:46:04 and Jun 04 11:46:07 SelectContact() Jun 04 11:46:10 It's a bit obfuscated Jun 04 11:46:14 * KaZeR_mobi just read Ainulindale's interview. Jun 04 11:46:15 I'd rather say Jun 04 11:46:17 Ainulindale: oh yeah this wasn't my request Jun 04 11:46:29 ptitjes: yeah just making sure you see my point Jun 04 11:46:29 nice. Jun 04 11:46:31 Ainulindale: I'm not for multiple methods for that Jun 04 11:46:38 ptitjes: good, neither am I Jun 04 11:46:47 Ainulindale: but different way it is implemented inside Jun 04 11:46:53 ptitjes: well to me in the end Jun 04 11:46:57 if the requester asks for contacts Jun 04 11:47:04 and gets several of them Jun 04 11:47:07 and wants to place a call Jun 04 11:47:14 if it's dumb enough not to handle that case Jun 04 11:47:17 we can't be held responsible for it Jun 04 11:47:26 Ainulindale: in a way I am meaning there may not be a 1:1 between methods and views Jun 04 11:47:34 s/views/screens/ Jun 04 11:47:34 ptitjes meant: Ainulindale: in a way I am meaning there may not be a 1:1 between methods and screens Jun 04 11:47:42 ptitjes: well that's up to the implementation Jun 04 11:47:56 sure Jun 04 11:47:56 we'll be giving specs, the implementation will do as it wants Jun 04 11:48:03 if I have two views, one for single one for multiple Jun 04 11:48:10 as long as I'm sure I'll get the expected result Jun 04 11:48:11 I don't care Jun 04 11:48:22 (As long as it complies to the specs) Jun 04 11:48:25 KaZeR_mobi: "nice" ? Jun 04 11:48:31 yep but the one or multiple must be conveyed in the request anyway Jun 04 11:48:37 ptitjes: of course Jun 04 11:48:41 ptitjes: did you see my reply anyway? Jun 04 11:48:45 yep Jun 04 11:48:47 I agree Jun 04 11:48:53 Ok good :-) Jun 04 11:49:02 I still think seriously this isn't sanely doable, sadly Jun 04 11:49:09 even though I can understand your wishes Jun 04 11:49:21 It might be doable for a couple of toolkits but this implies a lot of work IMHO Jun 04 11:49:27 Ainulindale: but maybe you think I'm seeing that session-based way too lowlevel Jun 04 11:49:27 And it won't be "universal" Jun 04 11:49:39 ptitjes: well not like "that" Jun 04 11:49:46 I think that this APi should be high level (as in functional) Jun 04 11:49:48 Ainulindale: I just don't think at the widget|toolkit level but very higher than that Jun 04 11:49:55 Then we may do such a thing as what you were describing on top of that Jun 04 11:49:57 but then we will speak of this at appropriate time Jun 04 11:50:01 but this will imply we'll need to wrap toolkits Jun 04 11:50:20 and I seriously think this is a hell of a job, long, painful, and bug inducing Jun 04 11:50:29 So I'm not keen on the idea Jun 04 11:50:30 Ainulindale: not necessarily wrapping toolkits Jun 04 11:50:44 ptitjes: well let us talk about that when we'll meet then Jun 04 11:50:55 Ainulindale: just adding a litlle lifecycle to screens is my idea Jun 04 11:51:04 I know Jun 04 11:51:11 yep Jun 04 11:51:12 Lifecycle is a bit different from what you were saying about customization Jun 04 11:51:19 * ptitjes => shower Jun 04 11:51:20 Signals, I can consider as lifecycle and useful Jun 04 11:51:26 Customization goes further Jun 04 11:51:31 And is more difficult IMHO Jun 04 11:51:54 Ainulindale: ha ok I see where you bump Jun 04 11:51:55 blahblah Jun 04 11:51:55 s/a/i Jun 04 11:51:55 s/a/i/ Jun 04 11:51:55 s/i/a/ Jun 04 11:51:55 KaZeR_mobi meant: s/i/i Jun 04 11:51:56 KaZeR_mobi meant: s/a/a Jun 04 11:52:03 Ainulindale: customized buttons Jun 04 11:52:08 Ainulindale: yeah I understand Jun 04 11:52:17 ptitjes: if by customized you mean Jun 04 11:52:30 "I want to call that screen with a button called 'toto' and another button called 'tutu'" Jun 04 11:52:33 I think this is difficult Jun 04 11:52:36 If you want to say Jun 04 11:52:38 Ainulindale: that would just mean, ok UI implementers must provides space to put 3 button actions (for instance) Jun 04 11:52:44 "Send a signal when contact is selected/view changed" Jun 04 11:52:48 I think this is doable Jun 04 11:53:03 The main purpose to me is Jun 04 11:53:04 yep I understand your point Jun 04 11:53:07 Keep it simple, keep it sane Jun 04 11:53:19 There's a compromise to do between complexity & flexibility Jun 04 11:53:20 I"ll come up with a proposal at the appropriate time then Jun 04 11:53:27 Ok thanks Jun 04 11:53:34 I'll relaunch the subject when the API will be up & running :-) Jun 04 11:53:47 Ainulindale KaZeR_mobi: "nice" ? i was talking of your interview. Jun 04 11:53:51 hehe :) Jun 04 11:53:56 why nice? Jun 04 11:54:09 (I'm interested in opinions) Jun 04 11:55:22 so. Ainulindale (or whoever wants to kick in) : interested in my logs? for my message + contact segfault Jun 04 11:56:32 KaZeR_mobi: yeah told you an hour ago to post that on a new ticket assigned to me Jun 04 11:57:34 ah sorry Ainulindale, i got disconnected and didn't saw your reply Jun 04 11:57:34 (i'm connected using FR ;) ) Jun 04 11:57:59 Ainulindale: ptitjes: kdialog --help, see --multiple Jun 04 11:58:40 DocScrutinizer: k? I have no k* software on my computer Jun 04 11:58:45 k* sucks! Jun 04 12:00:26 you asked for it, so prepare for impact ;-D Jun 04 12:01:03 DocScrutinizer: thanks for the german crap :-) Jun 04 12:01:34 Sorry but I can't read that :-) Jun 04 12:02:32 jr@halley:~/Documents/OpenMoko/images> LANG=C kdialog --help Jun 04 12:02:34 welcome. Sory lang=c didn't help Jun 04 12:05:05 Don't worry I'll check :-) Jun 04 12:10:37 Ainulindale: http://techbase.kde.org/Development/Tutorials/Shell_Scripting_with_KDE_Dialogs Jun 04 12:14:05 tracfeed: Ticket #504 (The revenge of the segfault - contacts + messages (but calls still ...) created Jun 04 12:15:26 Ainulindale: #504, gift for you :) Jun 04 12:15:30 i'm attaching logs Jun 04 12:20:44 done Jun 04 12:21:16 hehe the attack of the killer segfault ;-D Jun 04 12:21:18 tracfeed: ophonekitd.log attached to Ticket #504  || frameworkd.log attached to Ticket #504 Jun 04 12:24:54 DocScrutinizer: :) Jun 04 12:26:06 KaZeR_mobi: could you add messages log? Jun 04 12:26:35 Ah and I don't see any messagebook request in your log Jun 04 12:28:07 tracfeed: Ticket #504 (The revenge of the segfault - contacts + messages (but calls still ...) updated  || Ticket #504 (The revenge of the segfault - contacts + messages (but calls still ...) updated Jun 04 12:29:20 Ainulindale: i rebooted since.. messages log is console output ? Jun 04 12:29:33 yep :-) Jun 04 12:31:55 mmm. i don't have the bug right now (unfortunately? ;) ) Jun 04 12:32:36 i had it almost all the time last two days Jun 04 12:33:06 well try to modify the desktop file for messages & contacts to log into a file Jun 04 12:33:18 and when or if the problem happens again Jun 04 12:33:22 you'll have the log Jun 04 12:33:32 Does that suit you? Jun 04 12:33:57 good idea Jun 04 12:34:28 Don't forget to log stderr too Jun 04 12:34:42 sure Jun 04 12:35:28 KaZeR_mobi: by the way Jun 04 12:35:28 btw : any news about the fix for the gprs buffer issue? i don't think i've hit the bug recently, has it been implemented? Jun 04 12:35:34 Are you happy about SHR? Jun 04 12:35:39 What do you think is missing? Jun 04 12:35:48 (no idea about gprs) Jun 04 12:36:23 i am really happy with shr. it's my daily phone since march. i'm often telling good thing (because i think them) in forums, etc. Jun 04 12:36:52 phonelog seems to crash at startup in unstable. aware of this ? Jun 04 12:37:03 UI is good looking, lots of software, very reactive dev team (probably one of the major reason of my liking :) ) Jun 04 12:38:10 Ainulindale: missing, according to me : convenient way to handle contacts. scrolling is a real PITA. since it's sluggish, scrolling should be forgotten at all imo, in favor of something else like typing with keyboard Jun 04 12:38:31 MarcOChapeau: no crash here Jun 04 12:38:36 great Jun 04 12:38:39 if i had convenient contact handling, reliable alarm and a calendar, i would be even more happy :) Jun 04 12:38:58 For contacts I couldn't agree more Jun 04 12:39:06 I think TAsn had an idea about that Jun 04 12:39:22 For alarm, I think ffalarms is supposed to work well Jun 04 12:39:23 As for calendar, I have no idea about that Jun 04 12:39:24 Ainulindale: ah, and stable dbus backend of course, even if it doesn't really depends on your team Jun 04 12:39:39 well KaZeR_mobi it depends as much on "my" team than on FSO Jun 04 12:39:45 We're consumers and all part of the same community Jun 04 12:39:53 ffalarms didn't convince me last month when i tried it. i'll give it another go Jun 04 12:40:13 Ainulindale: see? that's what i like in moko, and especially with shr : team spirit Jun 04 12:40:17 And by calendar do you mean real calendar or schedule? Jun 04 12:40:24 KaZeR_mobi: heh =) Jun 04 12:40:51 calendar. i have no memory i have to write everything. i could forget to pee if it wouldn't hurt after a while :) Jun 04 12:41:11 so more a rendez-vous/tasks thing Jun 04 12:41:20 I think e-tasks or enotes might be of interest to you Jun 04 12:41:25 MarcOChapeau: i've been facing a lot of similar issues. you should open a ticket with framework, ophonekit and console output Jun 04 12:41:31 No idea if they're exactly what you need though Jun 04 12:41:56 Ainulindale: thinkg 'google agenda syncing', rather. i have all my appointements on it Jun 04 12:42:06 Yeah I can see that need pretty easily Jun 04 12:42:16 Unfortunately I don't know about any software currently handling that Jun 04 12:42:19 (properly, that is) Jun 04 12:42:56 i have no other phone/smartphone pda, so i really need it. i'm using agenda via midori, but, it's not really convenient. Jun 04 12:43:17 i tried the knj-* some weeks ago, but it had a lot of boring dependencies, and didn't work in the end. i'll give it another try to. Jun 04 12:43:31 KaZeR_mobi: well some pointers for knj? Jun 04 12:43:33 I could package them Jun 04 12:43:36 Or try to Jun 04 12:44:00 KaZeR_mobi: nope, fixed. I had an old config file in ~/.phonelog Jun 04 12:44:17 MarcOChapeau: ah, great Jun 04 12:44:43 Ainulindale: thanks for the offer. i'm reinstalling it and will give feedback probably this afternoon Jun 04 12:44:48 Ainulindale: do you intend to come at "Pas Sage En Seine" ? Jun 04 12:45:35 ye Jun 04 12:45:36 +s Jun 04 12:45:38 I'll be there Jun 04 12:45:45 MarcOChapeau: need to talk with Louis :-> Jun 04 12:45:52 Ainulindale: same here :) Jun 04 12:45:56 I know :-p Jun 04 12:46:15 You'll pay me this beer you owe me then Jun 04 12:46:20 sure Jun 04 12:46:21 For letting me down with the gtk lib :-p Jun 04 12:46:22 tonight or tomorrow ? Jun 04 12:46:26 tonight Jun 04 12:46:30 tomorrow I'm off Jun 04 12:48:15 Ainulindale: ah, i have a question for you. if you are good at packaging, it might be a good idea to split navit's package in 3 parts, for example binaries, gfx and demo map. cause current packet is 5M, hard to opkg upgrade via gprs Jun 04 12:48:27 well, that's not really a question but i guess you got my point :) Jun 04 12:49:56 Ainulindale: I'll leave work at 17h00. I guess I'll be around at 17h30 Jun 04 12:50:38 Ainulindale: PM me your phone. I don't have it since my phone doesn't handle contacts properly... :p Jun 04 12:51:00 KaZeR_mobi: Good idea Jun 04 12:51:07 KaZeR_mobi: Could you please open a ticket about that? Jun 04 12:51:29 MarcOChapeau: well I leave work at 16h, going home, I'll be there around 17h30-18h Jun 04 12:51:50 Currently trying to hack pidgin to include msn Jun 04 12:52:35 Ainulindale: msn should work out of the box if you have the right dependencies installed Jun 04 12:53:11 Well libpurple dependencies are not build Jun 04 12:53:18 That's why Jun 04 12:53:18 sure Jun 04 12:53:24 oh Jun 04 12:54:23 MarcOChapeau: so I hacked a bit the bb recipe for dynamic_prpls Jun 04 12:54:41 Trying to build it with default for DYNAMIC_PRPLS="irc,jabber,oscar,yahoo,simple,msn,myspace" Jun 04 12:55:13 hmm, looks like gentoo USE flags. yummy Jun 04 12:56:14 tracfeed: Ticket #505 (Split navit's ipk in 3 parts) created Jun 04 12:56:33 MarcOChapeau: +1 :) Jun 04 12:57:19 Ainulindale: i'd be interested in your recipe for #505, because we could also do the same for other distro. Jun 04 12:57:23 MarcOChapeau: How do you think I got the properties? :-) Jun 04 12:57:36 KaZeR_mobi: Well if I do a recipe for that I'll modify the existing Jun 04 12:57:42 KaZeR_mobi: And commit it to OE Jun 04 12:57:46 So it'll be there for all to see Jun 04 12:58:15 built shr-unstable: seems no mofi - whats used for wifi now? Jun 04 12:58:23 BillK: mofi is there Jun 04 12:58:34 I installed it yesterday to give it a try Jun 04 12:58:39 Ainulindale: perfect, thanks. Jun 04 12:58:51 Ainulindale: hehe Jun 04 12:58:53 k, must have lost it somehow - lite image. Jun 04 12:58:58 Ainulindale: 'if i'? or 'when i'll' ? :) Jun 04 12:59:09 When :-) Jun 04 13:01:09 Ok new package for pidgin available in a minute or so on the buildhost, will check afterwards Jun 04 13:04:26 Ah, opkg segfaulted Jun 04 13:04:28 Nice Jun 04 13:04:54 lol ! another kitty Jun 04 13:04:59 And failed again on fork Jun 04 13:05:31 this is annoying Jun 04 13:05:42 Hi, how to force openoembedded to rebuild Packages.gz ? Jun 04 13:05:50 neomilium: bitbake package-index Jun 04 13:05:57 or make index with the shr makefile Jun 04 13:06:01 thanks Ainulindale Jun 04 13:06:04 You're welcome Jun 04 13:08:15 Is there is a "nice" way to enable charging while usb running as host ? Jun 04 13:08:28 (or should I use sys path to do it ?) Jun 04 13:08:53 neomilium: shr-settings allows you to do that Jun 04 13:09:14 huh ? Jun 04 13:09:25 in shr-settings you have a "power" category Jun 04 13:09:27 it's supposedly there Jun 04 13:09:58 ok, looking for them into connectivity (near USB host/device switch) Jun 04 13:10:07 nah, it's in power IIRC Jun 04 13:12:26 Ainulindale : are you talking about "usb charge rate" ? Jun 04 13:18:25 Ainulindale: LED is blue and yet the battery applet says I'm 33% charged. know issue ? Jun 04 13:21:55 Ainulindale: new package request :) Jun 04 13:21:56 tracfeed: Ticket #507 (Package request : erminig) created  || Ticket #506 (Package request : erminig) created Jun 04 13:28:22 tracfeed: Ticket #474 (cannot reply sms in native language) updated Jun 04 13:32:48 MarcOChapeau: known issue yes Jun 04 13:32:58 MarcOChapeau: HAL is bothering us Jun 04 13:37:27 anyone in here knows where onen got all this cells for openbmap all of a sudden? Jun 04 13:37:42 did cellhunter or something else collaborate in the end? Jun 04 13:37:55 mrmoku|away: (see question above) Jun 04 13:45:07 Zorkman_: they import regularly stuff from it Jun 04 13:47:05 Currently packaging msn-pecan for pidgin Jun 04 13:49:35 In Bitbake recipes, what is the difference between "inherit autotools" and "inherit autotools_stage" ? Jun 04 13:51:15 autotools_stage will stage the headers if they are Jun 04 13:51:20 s/ey/ere/ Jun 04 13:51:20 Ainulindale meant: autotools_stage will stage the headers if there are Jun 04 13:51:31 neomilium: for instance libframeworkd-phonegui Jun 04 13:51:41 it ships headers on the host in order to build depending libs Jun 04 13:51:50 (not on the actual device) Jun 04 13:52:12 so if you need to install headers in the staging dir of bitbake Jun 04 13:52:18 for dependencies & such Jun 04 13:52:20 use autotools_stage Jun 04 13:52:27 (I feel I'm not clear enough) Jun 04 14:01:22 Ainulindale: it's ok, thanks for explanations ^^ Jun 04 14:22:21 Ainulindale, I'm not sure if it was or wasn't my idea, though I will do the contact list Jun 04 14:22:25 hopefully this weekend Jun 04 14:22:29 worst case, the one after :) Jun 04 14:24:49 Ainulindale: do you know how shr do the colored bash prompt? Jun 04 14:42:42 MarcOChapeau: it's HAL-related, yes. Basically the problem is that we don't know how to use HAL for battery monitoring properly and we don't know what kernel interfaces should be provided to HAL for that. Jun 04 14:42:57 MarcOChapeau: easy workaround: disable HAL in battery applet settings. Jun 04 14:46:43 tracfeed: Ticket #508 (Move/rename (frameworkd|ophonekitd).log before overwriting) created Jun 04 14:49:09 PaulFertser: hmm, interesting Jun 04 14:50:30 PaulFertser: where do I find those battery applet settings ? Jun 04 14:50:39 MarcOChapeau: if you're interested to further investigate here's the hint: we have 3 hal batteries: one is apm emulation, one is real but lacks properties that E bat gadget counts on and one is USB (which is according to hal sources is a battery too). So we need to understand hal semantics fully (after that somebody will fix E and i'll fix the kernel) and hal documentation lacks that. Jun 04 14:51:03 MarcOChapeau: the wrench Jun 04 14:51:09 PaulFertser: I'll have a look. I'm curious Jun 04 14:51:18 Ainulindale: You're right, pastebin _does_ change its hash! That's not that helpfull, now, is it? Anyway, latest version is at http://pastebin.com/m1a4fe667 I'll try make update again... Jun 04 14:52:23 PaulFertser: yup, I got as far as the wrench Jun 04 14:52:56 Ainulindale: you can close http://shr-project.org/trac/ticket/506 if you want, it's a dup of #507. I hit 'stop' to add the url to the package in #506 but it was too late. Jun 04 14:54:13 MarcOChapeau: if you can sort that out (precise semantics of hal-aided battery monitoring) with hal guys i promise you i'll do the kernel work needed. Jun 04 14:54:32 PaulFertser: hal should be able to expose the battery exposed through the power_supply class. afaik gnome-power-manager is (was?) using that so it can help you to look at that Jun 04 14:54:53 rtp: how? Reread the backlog please. Jun 04 14:55:39 rtp: we need some statement from hal guys to implement interfaces they require and to use the interfaces they provide properly. Jun 04 14:56:19 PaulFertser: some interfaces should already be there. For instance, the ACPI battery stuff is using the power_supply class and hal is able to use it Jun 04 14:56:45 rtp: yes, but E uses that hal properties that are unavailable in our kernel. Jun 04 14:57:07 do you have an example of missing property ? Jun 04 14:57:46 rtp: not offhand, i'd need to look at E sources again. You can as well compare list of bat properties with your laptop's. Jun 04 14:59:07 comparing with a laptop may not be a good idea. different battery/power systems means differents informations available. Jun 04 15:00:02 hi, i want to mount my nand memory while booted from SD, i have /dev/mtnblock6 and /de/mtnblock7, but mount -t jffs2 /dev/mtdblock7 /mnt doesn't work and gives an error: mount: /dev/mtdblock7: can't read superblock Jun 04 15:00:05 rtp: when raster/whomever developed his bat gadget he had probably looked at laptop properties. As the result if batgat is using hal (power_supply) battery it estimates the charge to be zero always. Jun 04 15:00:23 any way to merge the two partitions on NAND when booted from SD? Jun 04 15:01:36 then it's a bug in the battery stuff and not in the kernel or hal. if you have a link to the source code, it shouldn't take long to detect what's wrong Jun 04 15:02:33 rtp: i already know what's wrong: usage of nodes that are non-existant in FR's kernel. Bad thing is that if HAL has some policy wrt this probably we should implement those nodes. Jun 04 15:03:00 rtp: because we can "fix" E to not use that but we can't fix all other apps that count on it. Jun 04 15:03:26 rtp: hal is an abstraction so it should clearly state how to use its interfaces and what to provide for hal itself to work. Jun 04 15:04:16 rtp: and how to deal with the situation of having 3 batteries (our case). Jun 04 15:04:31 PaulFertser: the kernel is supposed to expose only the available informations. you won't ask him to report this it doesn't know Jun 04 15:04:33 (3 batteries where one is apm emulation, one is real and one is USB). Jun 04 15:05:08 rtp, it is not that simple. Jun 04 15:05:09 tracfeed: Ticket #506 (Package request : erminig) updated Jun 04 15:05:35 PaulFertser: the usb is not a battery. I think that some fields like info.category or something like that doesn't report battery Jun 04 15:05:37 rtp, for example, the gta02 has a columb counter -- this is fundamentally different information to report than the gta01 with a dumb battery that must estimate the charge available. Jun 04 15:06:01 rtp: according to hal sources, usb is a battery. Read for yourself if you don't trust me. Jun 04 15:06:10 rtp, so the kernel must "synthesize" the info required by the upper layers in some cases. We need to know what hal expects so that we can do so. Jun 04 15:06:42 rtp: or at list look at your lshal output. Jun 04 15:07:34 afair kernel is wrong at asigning properties to usb + charger Jun 04 15:07:51 DocScrutinizer: no, it's in hal sources. Jun 04 15:08:05 Kernel reports USB. hal considers it to be a battery. Jun 04 15:08:54 kernel reprts charger (which our hw is NC completely) which hal reprts as bat as well Jun 04 15:10:07 dunno who's to decide if its a bat or a mains power supply - anyway its wrong Jun 04 15:10:10 PaulFertser: to avoid the usb battery, you need to avoid battery with "battery.type" set to "usb" Jun 04 15:10:51 PaulFertser: hal is assuming that power_supply device with usb type is a battery Jun 04 15:11:48 * DocScrutinizer wonders which type the charger path has Jun 04 15:13:52 DocScrutinizer: the sysfs file should contains mains for ac adapters afaik :) Jun 04 15:14:27 *our* charger path is a NotConnected one Jun 04 15:15:22 it's the second power rail after usb, on PCF50633, and it's NC Jun 04 15:16:07 AIUI it makes for the 3. of the 3 bat, of which only one bat is a real one Jun 04 15:17:29 the apm one is probably due to the apm power supply emulation. the usb is problably for the power coming from usb. Jun 04 15:17:56 rtp: do you understand that we need semantics for that? We shouldn't guess how to use hal, we should know it for sure. Jun 04 15:18:19 rtp: yes the apm is due to apm battery emulation. Jun 04 15:19:15 PaulFertser: what I'm saying is not 100% guesses. I already looked at the hal source code when I wrote a driver for the power_supply class Jun 04 15:20:12 PaulFertser: what I don't know exactly is how the battery stuff is managed on the FR Jun 04 15:20:25 ok, so seems I got it wrong back when this has been discussed first time Jun 04 15:20:53 rtp: go ahead and ask ;-) Jun 04 15:22:08 hehe :) Jun 04 15:22:29 probably no better place and better time than now and gere to get an answer Jun 04 15:22:46 s/ ge/ he/ Jun 04 15:22:46 DocScrutinizer meant: probably no better place and better time than now and here to get an answer Jun 04 15:22:52 from a quick look at the pcf driver, it looks like the usb battery is really for the power coming from the usb charger Jun 04 15:23:24 errr, what's the meaning of this statement? Jun 04 15:24:14 the battery is for powering FR when there is *no* power coming from USB ;-) Jun 04 15:24:39 and how do you charge your battery ? :) Jun 04 15:24:58 via PCF50633 MBC Jun 04 15:25:27 which is taking its power from the usb right ? Jun 04 15:25:32 yup Jun 04 15:26:04 like the system does, if there is any power on USB Jun 04 15:26:08 rtp: the problem is: usb is in class power_supply. It's type is USB. And hal considers power supplies of that type to be batteries. Jun 04 15:26:08 the battery called "usb" in the applet is for that :) Jun 04 15:26:50 PaulFertser: yes but you can detect if it's a battery or not. the "battery.type" hal property is different Jun 04 15:26:59 that's quite obvious nonsense in hal to me Jun 04 15:27:32 hmm. have to admit I have no idea about hal semantics Jun 04 15:27:52 DocScrutinizer: I keep saying: we need a document about hal semantics. Jun 04 15:28:03 DocScrutinizer: rtp tries to convince me that it's obvious and we don't need it. Jun 04 15:28:04 ack Jun 04 15:28:56 in the first instance assigning a bat property to usb sounds odd Jun 04 15:29:36 PaulFertser: I'm not saying that it's obvious but the information is available in place like http://cgit.freedesktop.org/hal/tree/hald/linux/device.c :) Jun 04 15:30:09 rtp: information's available, yes. But not the semantics afaict. Jun 04 15:31:09 booooah, neeed coffee Jun 04 15:32:33 the only usb batteries I have seen exported by hal on pc are uninterruptable power supplies, which gnome-power-manager etc. report on if detected Jun 04 15:33:36 most of the information in hal is in the script/fdi files though, the c is as generic as possible Jun 04 15:34:07 useful information/logic Jun 04 15:34:37 khiraly1: Yes PS1 in profile Jun 04 15:36:13 tmzt: I also think there has to be some sort of hw-descr-file somewhere Jun 04 15:36:26 tmzt: and yet that stuff about assuming USB is battery is in C, i saw it myself. Jun 04 15:36:44 for gta02 or you mean generally? Jun 04 15:36:52 so it's wrong, no? Jun 04 15:36:53 tmzt: generally. Jun 04 15:36:55 yeah, I wasn't trying to comment on this specific case Jun 04 15:37:04 with the second statement Jun 04 15:37:20 Deubeuliou ? Jun 04 15:39:26 PaulFertser: you want to say every usb *device* is a bat? For sure usb hosts are not, usually ;-) Jun 04 15:40:35 does lshal work? Jun 04 15:40:55 sitting on my laptop here, lshal doesn't show any usb bat Jun 04 15:41:07 I heard it does Jun 04 15:41:29 grep -r power_supply /usr/share/hal/ Jun 04 15:41:37 no results, so that one is in c Jun 04 15:41:51 if it happens on here Jun 04 15:41:56 DocScrutinizer: ls /sys/class/power_supply :) Jun 04 15:41:59 (ubuntu) Jun 04 15:42:22 tmzt: yes, i saw the C code where USB power_supply was considered to be a battery. Jun 04 15:42:25 tmzt: I gave the link to the source code handling the power_supply stuff in hal some minutes ago Jun 04 15:42:52 PaulFertser: not arguing with that, I'll look in a second Jun 04 15:43:02 rtp: ??? Jun 04 15:43:10 (17.34.37) Ainulindale: khiraly1: Yes PS1 in profile Jun 04 15:43:23 Ainulindale: could you point me an url please to the .bb recipe? Jun 04 15:43:40 I searched yesterday but didnt found it in bash recipe Jun 04 15:45:10 DocScrutinizer: hal relies mainly on power_supply class so if your usb battery is not is /sys/power_supply, it's likely that you won't see it in lshal Jun 04 15:45:29 okay, I see that, but why would it treat the device as both a power_supply and a usb device? Jun 04 15:45:41 rtp: wtf is a usb battery? Jun 04 15:45:46 why do you say usb battery, or you mean /sys/class/power_supply/*/name is usb? Jun 04 15:46:21 DocScrutinizer: you said "lshal doesn't show any usb bat" did I read it too quickly ? Jun 04 15:46:29 ok, type Jun 04 15:46:43 cat /sys/class/power_supply/*/type Jun 04 15:47:35 s/any usb bat/ any bat of class usb/ Jun 04 15:49:25 ahh. I expect that on your laptop you have only a primary battery and a ac_adapter in lshal Jun 04 15:49:45 exactly. and that's the way it should be Jun 04 15:49:51 is CONFIG_PDA_POWER set? Jun 04 15:51:04 .type = POWER_SUPPLY_TYPE_USB Jun 04 15:51:42 tmzt: on the FR, if you want kernel code for the power_supply, look at the pcf50633*.c file Jun 04 15:51:43 on FR we have no ac_adapter (working implementation, though we got the fnction for it in PMU). Still I don't see how this makes usb a battery Jun 04 15:52:31 seems it's a convention from zaurus, but I can't understand it Jun 04 15:52:48 fsck zaurus Jun 04 15:53:36 it must be that they had two charger ports, one was a small barrel for ac power and the other was usb Jun 04 15:53:57 by the way, later zaurus, not sl5500 Jun 04 15:53:57 if two persons don't understand it, this suggests it probably might be odd anyway Jun 04 15:54:23 tmzt: we could have that as well. see above comment Jun 04 15:54:33 yeah Jun 04 15:54:35 but it's NC on FR Jun 04 15:54:59 still it's odd Jun 04 15:55:06 usb is *no* battery Jun 04 15:55:27 no, it's a power_supply which can supply a battery which can also be a power_supply Jun 04 15:55:50 until hal semantics specs tell me concludent why it has to be that way and not any different Jun 04 15:55:53 DocScrutinizer: the usb is Jun 04 15:56:03 DocScrutinizer: the usb is a battery is purely in hal Jun 04 15:56:50 DocScrutinizer: the pcf driver is only saying the a power supply of type usb. Doesn't say it's a battery Jun 04 15:57:08 rtp: yep Jun 04 15:57:11 if hal semantics specs fail to convince me on this being the only way to handle, I'd rather start a war against those specs Jun 04 15:57:28 DocScrutinizer: looks like there's no "hal semantics specs" at all. Jun 04 15:57:45 DocScrutinizer: so you have a good opportunity to make love, not war. Jun 04 15:57:55 so the war is easily won ;-D Jun 04 15:58:06 hehe Jun 04 15:58:21 maybe devicekit-power stuff is better :) Jun 04 15:59:00 so here come *my hal semantics spec (excerpt)": USB IS NO BAT - period Jun 04 16:00:38 as - according to PaulFertser - this are the only hal semantics spec worldwide, obviously they are obliging :-D Jun 04 16:00:44 seems usb ups's use a variant of hid protocol, but still haven't found where they get labeled type usb in hal Jun 04 16:01:37 the ups are called ups on lshal I think. About the protocol used, there's a usb spec for this kind of devices Jun 04 16:02:16 tmzt: type "usb" comes from the kernel drivers, i guess userspace UPS controlling daemons can't inject anything in /sys/class/power_supply Jun 04 16:02:38 yeah, I mean how it gets to hal Jun 04 16:02:42 based on the only obliging hal semantics specs, I raise a bug ticket against the behaviour of hal on FR. Alas dunno where, so do symbolic here and now Jun 04 16:03:04 DocScrutinizer: :) Jun 04 16:03:07 isn't hal deprecated already anyway? /me hides... Jun 04 16:03:15 it's possible to work around this with an fdi I think if the gta02 power_supply device has specific attributes Jun 04 16:04:11 PaulFertser: didn't I tell I know how to open tickets ;-) Jun 04 16:04:18 lindi-: I'm not sure it's possible to switch to devicekit-power now :) Jun 04 16:04:52 PaulFertser: wait until coffe takes effect ;-D Jun 04 16:09:10 pfff, zaurus devels pushed a botch upstream, nobody here at OM would get away with, it seems :-/ Jun 04 16:09:39 from what I read here, the batget applet is using battery.charge_level.percentage which afaik is the sysfs file called capacity. so it should work /o\ Jun 04 16:10:42 rtp: so what's the [hal|auto|internal] setup in bat-extended then? Jun 04 16:11:15 and YES, with setting internal *it just works* Jun 04 16:11:46 so a keen asumption is : internal==sysfs Jun 04 16:11:55 DocScrutinizer: I'm looking at that : http://trac.enlightenment.org/e/changeset/37646 the problem may be line 327 we have 3 "batteries " Jun 04 16:13:24 I'm guessing the original concept was power_supply would strictly be used for things that supplied power to other parts of the device, but it became a generic term for ac/battery Jun 04 16:13:38 rtp: we've been there, done that. It's known we got one real and two fake empty batteries and thus get 33% for a full bat Jun 04 16:14:30 DocScrutinizer: so to get 1 battery, disable the apm power supply module (apm is dead, no ? :) and patch the batget to ignore the usb one Jun 04 16:14:46 oooouuuuch Jun 04 16:15:15 why not fix the root cause? USB IS NO BAT Jun 04 16:16:29 I agree but you can try to convince the hal devs. You may get the answer to switch to devicekit-power Jun 04 16:16:32 the bat applet is tested and works fine on other platforms. So obviously sth has to be wrong with our FR Jun 04 16:17:44 we can do same as zaurus: silently push upstream ;-) Jun 04 16:17:49 the other platforms probably have no apm emulation enabled and no usb stuff to charge the battery Jun 04 16:18:23 or we can fix for FR and offer the patch to upstream. Then it's up to them to keep a bug, or to apply it Jun 04 16:18:47 rtp: USB IS NO BAT Jun 04 16:19:01 could it be changed to type 'usb-charger'? Jun 04 16:20:02 DocScrutinizer: again, say it to the hal peoples :) Jun 04 16:21:05 no, I won't. We got lenty of patches for FR, pending to go upstream. A lot of them might be rejected, and honestly I don't care. I give a shit for hal-devels first instance Jun 04 16:21:59 I don't need hal-devels' placet to fix a bug for FR Jun 04 16:24:07 au contraire: we will prove our fix is valid. then push upstream. then it's up to them to decide if they like to accept it, or ask for some minor rework, or completely ignore Jun 04 16:24:11 we're using standard power_supply class so every device using the same kind of usb stuff (for instance with the WM8350 module) are affected. it's not FR specific Jun 04 16:24:59 so chances are good they like to accept our patch, if done decently Jun 04 16:26:21 rtp: the kernlejust presents incorrect information Jun 04 16:26:29 it presents 3 batteries Jun 04 16:27:01 literally the /sys/class/power_supply/NAME/type says "Battery" Jun 04 16:27:18 raster: no. read again what I've said. it presents 2 batteries and extra one is from the apm stuff which should be disabled Jun 04 16:27:18 exactly Jun 04 16:27:22 it explicitly shows 3 batteries - fix the kernel. Jun 04 16:27:38 rtp: ti sholuld not show an apmbattery in the /sys/clas/ Jun 04 16:27:45 rtp: ti sholuld not show an apmbattery in the /sys/class/* stuff at all Jun 04 16:28:07 apm is compat code to have /proc/apm display battery info for old userspace code that only can read /proc/apm Jun 04 16:28:26 you have only 1 battery - it should show only 1 battery in /sys/class/power_supply Jun 04 16:28:36 you can have other dirs (power sources) there Jun 04 16:28:38 a device on the system shouldn't be a class device/appear in sysfs? Jun 04 16:28:48 but they should not be of type Battery unless it *IS* a batery Jun 04 16:29:00 tmzt: there is only 1 battery device Jun 04 16:29:05 thus only one should appear Jun 04 16:29:12 USB IS NOT A BATTERY Jun 04 16:29:16 where does it say type battery? I thought the problem is it said type usb Jun 04 16:29:19 technically power supply via usb can b another node Jun 04 16:29:23 but not of the type battery Jun 04 16:29:28 and hal interprets that as a battery Jun 04 16:29:34 /sys/class/power_supply/NAME/type Jun 04 16:29:34 DocScrutinizer: the kernel is not saying that usb is a battery... Jun 04 16:29:42 look in /sys/class/power_supply Jun 04 16:29:44 u wil hve dirs Jun 04 16:29:49 in each dir u have a type file Jun 04 16:29:56 that tells u the type of the power supply Jun 04 16:29:59 the kernel is simply wrong Jun 04 16:30:09 DocScrutinizer: it doesnt need to be ot type BaTTERY Jun 04 16:30:23 rtp: i give a fsck *who* says, but according to you guys usb is of class bat Jun 04 16:30:24 it probably should be of type Mains Jun 04 16:30:37 the baqtget code doesnt look at things not of type Battery Jun 04 16:30:40 it ignore them Jun 04 16:30:45 DocScrutinizer: according to hal not us Jun 04 16:30:52 if u havemultiple things claming to be battery - it assumes u have multiple batteries Jun 04 16:30:59 and that is just what the kernel claims to have Jun 04 16:31:12 rtp: so what????? Jun 04 16:31:14 USB IS NOT A BATTERY Jun 04 16:31:34 rtp the kernel is wrong. fix the kernel Jun 04 16:31:40 userspace code is completely correct Jun 04 16:31:51 it is using the power_class /sys api as it was mant to be used Jun 04 16:32:06 the kernel is simply exposing devices incorrectly/that don't exist Jun 04 16:32:09 aand userspace is not up to workaround kernel/hal bugs Jun 04 16:32:19 DocScrutinizer: yup Jun 04 16:32:19 raster: no. do cat */type |grep Battery|wc -l and you'll see that the kernel is saying that there's only 1 battery in the sysfs class Jun 04 16:32:26 i dont know what hal says about it Jun 04 16:32:30 i DOknow hat e's batget says Jun 04 16:32:32 and it is right Jun 04 16:32:38 the kernel is wrong Jun 04 16:32:51 rtp: incorrect. Jun 04 16:33:13 i've seen it before Jun 04 16:33:31 and the batget code EXPLICITLY does not look at dirs that are not of type Battery Jun 04 16:33:34 told ya, we've been there, done that Jun 04 16:33:36 raster: did you see the hal code linked earlier? Jun 04 16:33:37 i wrote that code. Jun 04 16:33:53 i dont know what hal says about it Jun 04 16:33:53 i DOknow hat e's batget says Jun 04 16:34:03 dirs meaning udi's? Jun 04 16:34:08 raster: the battery.type fields is *not* what's in the sysfs files Jun 04 16:34:08 its an fs Jun 04 16:34:11 they are dirs Jun 04 16:35:02 eh? Jun 04 16:35:07 cat the file Jun 04 16:35:25 http://cgit.freedesktop.org/hal/tree/hald/linux/device.c Jun 04 16:35:26 if it says Battery (or battery - code doest car about case) Jun 04 16:35:39 then its read as a battery device in batget Jun 04 16:35:48 if it isnt battery - it is ignored Jun 04 16:35:55 USB IS NOT A BATTERY Jun 04 16:35:56 raster: please look at that, I can't see how that makes any sense Jun 04 16:36:00 raster: your code in batget is relying on the hal battery.type field and this field is not equal to the sysfs type file Jun 04 16:36:01 tmzt: i cant commnt on hal. Jun 04 16:36:05 imnot talking about hal Jun 04 16:36:10 does getbat use hal? Jun 04 16:36:28 tmzt: http://trac.enlightenment.org/e/changeset/37646 Jun 04 16:36:41 DocScrutinizer: so to get 1 battery, disable the apm power supply module (apm is dead, no ? :) and patch the batget to ignore the usb one Jun 04 16:36:53 "patrch batget to ignore the usb one" <- incorrect Jun 04 16:37:09 "battery module now will use hal - if it finds it" Jun 04 16:37:16 no patchs will be accepted as the code is correct. you are not fixing a bug. you are working around a specific buggy kernel. Jun 04 16:37:31 raster: it's either patch batget to get a quick workaround or patch hal and get it merged (longer path) Jun 04 16:37:34 rtp: batget doesnt use hal at all. Jun 04 16:37:44 rtp: the battery module does. batget has no hal knowledge Jun 04 16:37:48 it doesnt do any dbus Jun 04 16:38:11 the battery module will use the hal batteryu if it find it by default Jun 04 16:38:16 thats automatic mode Jun 04 16:38:18 ok, battery module which is what's being used here right? Jun 04 16:38:21 the battery module has a config panel Jun 04 16:38:23 raster: so what about the commit I gave ? Jun 04 16:38:45 u can set it to use auto-detect (default) internal (batget) or hal. Jun 04 16:39:11 if batget is giving you wrong bttery levels - its not batget's problem Jun 04 16:39:53 there's no way a pda needs a full hal or devicekit though anyway Jun 04 16:39:55 so here come *my hal semantics spec (excerpt)": USB IS NO BAT - period Jun 04 16:39:58 as for hal - battery module just asks hal for all battery devices and uses what hal tells it (of course combining al batteries into 1 to avoid more battery icons) Jun 04 16:40:33 but the concepts make sense, dbus (om already uses), a generic tree with properties, some stuff coming from sysfs Jun 04 16:40:34 tmzt: you want hal. well gta02 no - but in general yes. removable storage for example. you'l need hal for wifi things like network mnanager, or connman Jun 04 16:40:55 if u go to e;s config panel Jun 04 16:41:15 under advanced - u'll find the battery config dialog Jun 04 16:41:25 u can tell it not to use hal explicitly in advanced Jun 04 16:43:42 rtp: the commit simply adds hal support and uses it by default if available or falls back to batget. there is config for explicitly configuring it. you have a choice - configure and ignore kernel / hal bugs, or fix kernel / hal. Jun 04 16:44:09 which one works best in normal cases? Jun 04 16:44:21 ignoring the .type=usb for now Jun 04 16:44:44 there is no way tghat the code is going to have specific hacks in it to go ignore some specific devices just bcause some layer below e has a bug. because this now crates proble,ms for the 1000's of laptops, desktops and other devices it runs on Jun 04 16:45:23 I'm not saying to do it in your code, I'm asking which of the three works best ignoring the current problem for purpose of discussion Jun 04 16:46:12 tmzt: batget looks for devices that are explicitly exposes as battery by hal (for battery % display) Jun 04 16:46:16 e_hal_manager_find_device_by_capability Jun 04 16:46:16 (conn, "battery", _battery_hal_find_battery, NULL); Jun 04 16:46:36 it explicitly has a separate list for "ac adaptors": Jun 04 16:46:44 e_hal_manager_find_device_by_capability Jun 04 16:46:45 (conn, "ac_adapter", _battery_hal_find_ac, NULL); Jun 04 16:47:02 the ac adaptors are note used for battery full cacl Jun 04 16:47:59 if some usb device happens to be a battery (it could be!) then it shouldnt be ignored Jun 04 16:48:10 as long as hal says its a battery - then the code will treat it as such Jun 04 16:48:18 yeah, some mice and some ups's are usb and battery Jun 04 16:48:23 so it's a bug in hal not in the kernel .... Jun 04 16:48:54 but I'm not asking that, I'm asking which method of accesing the charge information is most accurate, up-to-date, and updates asynchronously Jun 04 16:48:57 hoooray Jun 04 16:49:32 rtp: last time i say this - kerel exposed multiple battery devices Jun 04 16:49:42 it's usb mouse I think now, there's just some confusion between kernel and userspace on what type=='usb' means Jun 04 16:49:49 tmzt: hal and batget update asynchronously Jun 04 16:49:57 well nothing does it without polling Jun 04 16:50:00 u have to poll Jun 04 16:50:07 but batget and hal do it in the background Jun 04 16:51:04 raster: the kernel is exposing 2 batteries because someone asked to provide the same battery information through 2 different interfaces :/ Jun 04 16:51:18 bingo Jun 04 16:51:23 and that is wrong Jun 04 16:51:25 rtp, it is still shouldn't be problem Jun 04 16:51:27 there is just 1 battery Jun 04 16:51:32 (x+x)/2 = x Jun 04 16:51:33 http://osdir.com/ml/kde-bugs-dist/2009-04/msg06882.html Jun 04 16:51:45 that interface 9power_class) is not meant for exposing 1 battery multiple ways Jun 04 16:51:58 but we have smth like (x+0+0)/3 = 1/3x Jun 04 16:52:06 its a universal interface for exposing any battery 1 way with lots of standard properties Jun 04 16:52:28 aah fuck Jun 04 16:52:30 wont boot Jun 04 16:53:02 power_supply doesn't have to be just for batteries though Jun 04 16:53:05 max_posedon: then something is exposing 3 battery devices Jun 04 16:53:18 tmzt: its for any form of power suppoly Jun 04 16:53:23 batteries ac adatpors etc. Jun 04 16:53:29 thys why each node has a type Jun 04 16:53:34 thus Jun 04 16:53:36 there is also battery.type == "mouse" so I can't figure out why .type == "usb" would be used Jun 04 16:54:07 oi can sat that batgets code ONLY looks for type "battery" Jun 04 16:54:12 (strcasecmp) Jun 04 16:54:32 can somebody lshal |paste please? Jun 04 16:55:34 woooohoooo, kernel panic :-/ Jun 04 16:55:48 (unrelated lshal) Jun 04 16:55:56 mouse is kinda battery but with power_supply < 0) Jun 04 16:56:11 max_posedon: yup. Jun 04 16:56:20 yeah, it can't supply power only consume it, charge, and discharge Jun 04 16:56:26 thus why for a generic system battery meter it should be skipped unless its type "battery" Jun 04 16:56:45 it's so people's logitech gamer mouses are reported by gnome-power-manager and kde equivalent Jun 04 16:56:49 tmzt: yup. you can measure its power level but cant use thepower from it Jun 04 16:57:56 and for sure don't want to include it in FR bat pwr src computing Jun 04 16:58:10 yup Jun 04 16:59:11 right, but I'm just trying to eliminate possibilities for hal treating type == "usb" as battery Jun 04 16:59:22 it shouldnt Jun 04 16:59:53 but evenj then u also have another apm battery exposed which is wrong Jun 04 17:00:14 there's exactly *one* valid case: bat "usb host" Jun 04 17:00:22 maybe that should be exposed but without the sysfs entries to get the charge, etc. Jun 04 17:00:39 I can't see how it can be only platform bus or another bus without being enumerated in sysfs Jun 04 17:00:46 hal is exposing all insformations it get to if one has /proc/apm and /sys/class/power_supply stuff you get both in lshal Jun 04 17:00:52 tho I don't know of any usb-bat that claims to do host Jun 04 17:01:05 if there is no need for /proc/apm remove it from kernel (freerunner's) Jun 04 17:01:28 DocScrutinizer: no, and I don't know of any udc that actually supports that Jun 04 17:01:41 I guess usb protocol might Jun 04 17:01:47 hehe, this as well Jun 04 17:01:57 yup, sure Jun 04 17:02:12 tmzt: correct. apm should just expose /proc/apm and nothnig more as that was the only use for it. the power_class entry is just wrong :) Jun 04 17:02:28 it shoudl be a misc class Jun 04 17:02:48 since that's what it is, or is that only for things that appear in /dev ? Jun 04 17:03:30 why should it expose ANYTHING in power_class Jun 04 17:03:33 its not another device at all Jun 04 17:03:40 right Jun 04 17:03:40 its a copy of the /proc/apm data Jun 04 17:03:46 /sys/class/misc I mean Jun 04 17:03:53 in fact its simply repseceting the same core data as the single battery you have Jun 04 17:04:03 there is no use for it - it cannto provide extra/more info Jun 04 17:04:17 raster: hal uses apm emulation directly afaict Jun 04 17:04:24 the only point for that code to exist is pretty much to support qtopia (qte) as it only knows /proc/apm Jun 04 17:04:40 raster: the power_supply is meant to be the linux standard way to expose power sources like battery and ac. Like it or not, it's not going to be removed Jun 04 17:04:52 raster: we don't have any extra entries in /sys/class/power_supply. Jun 04 17:04:54 rtp: there is only 1 battery Jun 04 17:04:57 its exposing 2 Jun 04 17:05:01 that is worng Jun 04 17:05:03 the krnel is worng Jun 04 17:05:11 raster: wait. Jun 04 17:05:14 go talk to kernel devs. Jun 04 17:05:17 and why support /proc/apm in getbat anyway? Jun 04 17:05:20 raster: you asked for /proc/apm and /sys/power_supply in kernel configuration, you got it Jun 04 17:05:28 *I* never asked for it Jun 04 17:05:32 raster: kernel is exposing one battery through both ways: apm emulation and power_supply. What is wrong with that? Jun 04 17:05:44 qte requires it as it only knows /proc/apm Jun 04 17:05:50 /proc/apm is dead and buried Jun 04 17:06:07 raster: sure but can we keep it for backward compatibility reasons? Jun 04 17:06:15 it is only capable of exposing a tiny subset of the data you actually have from power supplis/batteries etc. Jun 04 17:06:29 /proc/apm is the VIEW of ALL batteries and power supplies in power_class Jun 04 17:06:37 it shoudl not ALSO add another entry in power_class Jun 04 17:06:39 that is wrong Jun 04 17:06:53 raster: it doesn't. we have only one battery in power_class. Jun 04 17:07:07 PaulFertser: how may do u have Jun 04 17:07:11 yeah, which is why I suggest class misc, but that could be wrong since it wouldn't have a dev entry Jun 04 17:07:14 when plugged into usb you shoul dhave at most 2 Jun 04 17:07:20 ads best i understand there are 3 Jun 04 17:07:27 a bat, a apm emulation AND the usb power supply Jun 04 17:07:35 raster: i have "ac adapter battery usb" in power_supply. Jun 04 17:07:45 tmzt: it already has an entry in power_class Jun 04 17:07:49 he normal battery Jun 04 17:07:52 raster: that's only one battery. Jun 04 17:08:00 raster: and there's apm emulation that exposes the same battery. Jun 04 17:08:03 PaulFertser: 4? Jun 04 17:08:15 raster: 4 power_supplies, 1 battery. Jun 04 17:08:25 whats ac and adapter? Jun 04 17:08:28 raster: I'm saying have whatever is registering /proc/apm be no longer power_supply class but another class or no class Jun 04 17:08:56 PaulFertser: why all of those? Jun 04 17:08:56 raster: they're not online atm anyway. Jun 04 17:09:01 tmzt: that is simply a representation (a simplified one) of whats in power_class/bat/* Jun 04 17:09:04 thats all Jun 04 17:09:08 tmzt: i'm not the one who wrote the code. Jun 04 17:09:25 should pcf* have more pdata to only represent terminals that are in use? Jun 04 17:09:26 what on earth are ac and adapter? Jun 04 17:09:33 i cant think of any hw reasonfor them Jun 04 17:09:36 raster: do you think that the fact something is accessible via apm emulation means that it should be removed from power_supply class? Jun 04 17:09:42 u have usb power or battery on the FR Jun 04 17:09:47 does gta02 use otg detect for any of this? Jun 04 17:09:55 PaulFertser: NOOOO Jun 04 17:09:58 i repeat Jun 04 17:10:07 as best i know from what rtp said Jun 04 17:10:13 there are 2 batteries in power_class Jun 04 17:10:16 the "bat" and "apm" Jun 04 17:10:19 it lists 2 Jun 04 17:10:28 ONLY 1 should exist Jun 04 17:10:32 "bat" Jun 04 17:10:33 tmzt: 2442 is not otg :) Jun 04 17:10:36 rasadapter is the NC hw for second charger path in 50633 afaik Jun 04 17:10:38 there is only 1 battery in the hardware Jun 04 17:10:40 raster: let me explain my vision please. Jun 04 17:10:45 raster: Jun 04 17:11:01 it shouldonly expose "bat" as the battery in power_class Jun 04 17:11:07 raster: we have only one battery, i agree (bupbattery doesn't count). Jun 04 17:11:18 userspace code needs to choose - use /proc/apm or use power_class/* info Jun 04 17:11:19 not both Jun 04 17:11:21 raster: we expose only one battery through power_supply sysfs class. Jun 04 17:11:39 PaulFertser: ok. thats not what i gathered from the above Jun 04 17:11:43 raster: hal uses both /proc/apm and power_supply to get information about the batteries. Jun 04 17:12:01 raster: and hal considers any power_supply that has type usb to be a battery. Jun 04 17:12:07 rtp: the kernlejust presents incorrect information Jun 04 17:12:07 it presents 3 batteries Jun 04 17:12:07 literally the /sys/class/power_supply/NAME/type says "Battery" Jun 04 17:12:08 raster: no. read again what I've said. it presents 2 batteries and extra one is from the apm stuff which should be disabled Jun 04 17:12:16 raster: the last statement was proved by reading hal sources. Jun 04 17:12:18 i was talking only of the power_class info Jun 04 17:12:26 andrtp was telling me you had 2 Jun 04 17:12:33 one from apm, one normal bat Jun 04 17:12:59 raster: E bat gadget sees 3 batteries. Because hal exposes both APM and power_supply battery. And it exposes usb supply as battery too, for whatever reason. Jun 04 17:13:05 ok - that's hal's problem and should be fixed. thats pretty wrong Jun 04 17:13:14 raster: and there's one more problem Jun 04 17:13:25 e's batget would see only 1 as it does it right Jun 04 17:13:34 yes Jun 04 17:13:36 OMG Jun 04 17:13:39 raster: E uses battery properties that are not available from power_supply battery driver on GTA02. Jun 04 17:13:41 usb power supply - if it is type "battery" Jun 04 17:13:43 thats wrong Jun 04 17:14:06 ? Jun 04 17:14:09 wait Jun 04 17:14:11 e or hal? Jun 04 17:14:17 raster: can you say why do you think those properties exactly that are used for computations in E _must_ be provided by the kernel? Jun 04 17:14:18 e just asks hal for all the batery devices that exist Jun 04 17:14:20 I found a version of devices.c without it, but it's a very different structure Jun 04 17:14:27 and uses that - it knows nothing more than what hal tells it Jun 04 17:14:28 raster: it uses battery properties mapped 1-1 by hal to sysfs nodes. Jun 04 17:14:32 or u mean e's batget? Jun 04 17:14:35 there must be a mailing list message about this Jun 04 17:14:43 * DocScrutinizer off for banging head against wall Jun 04 17:14:57 wait Jun 04 17:15:05 e asks hal for all battery devices Jun 04 17:15:09 right Jun 04 17:15:22 so lshal should tell you what's going on Jun 04 17:15:25 then simply uses the valus hal gives Jun 04 17:15:28 Right Jun 04 17:15:50 e;s batget goes to sysfs/proc directly and thus knows what is what Jun 04 17:15:58 it will try power_class first Jun 04 17:16:02 and look for batteries Jun 04 17:16:05 raster: we're are talking about "HAL" method, not "internal". Jun 04 17:16:13 if it finds 1 or more - it will use that Jun 04 17:16:18 if not it uses /prco/apm Jun 04 17:16:23 ok Jun 04 17:16:29 raster: and via HAL it uses some properties. That are mapped 1-1 by hal to sysfs nodes. That we lack. Jun 04 17:16:29 internal method is correct Jun 04 17:16:40 Internal is correct, true. Jun 04 17:16:44 PaulFertser: how are the mapped 1:1? Jun 04 17:16:45 hmm Jun 04 17:16:55 e's halcode asks for list of all battery devices Jun 04 17:17:16 tmzt: you request a value of the property, hal reads it from corresponding sysfs node without mangling or computations. If the node doesn't exist -- it returns 0. Jun 04 17:17:30 if IS_BATTERY == TRUE: Jun 04 17:17:54 raster: and lshal shows 3 devices. Two power_suppy, one apm emulation. And we get 33% because only apm emulation (ironic, yes?) works with current E code. Jun 04 17:17:55 hal_device_property_set(d, "battery.type", battery_type) Jun 04 17:18:23 yeah, it's 1:1, battery.type becomes usb Jun 04 17:18:37 if foo == true is baaad style anyway :-/ Jun 04 17:18:46 after that it asks for the the properties - like if it is present, its sdesign and last full levels and current level etc. Jun 04 17:18:51 if /sys/class/power_supply/*/* type was usb Jun 04 17:19:14 raster: is it everything with battery.* is considered a battery? Jun 04 17:19:19 if any property changes signals com it - it re-gest properties Jun 04 17:19:40 raster: yes, and some of the properties used to compute actual charge are unavailable with current kernel. Jun 04 17:19:51 if ((foo == true) == true ) == true Jun 04 17:20:33 better style (more safe) ;-D Jun 04 17:20:44 I think they did that to distinguish from NULL, but whatever Jun 04 17:20:54 or FALSE maybe Jun 04 17:21:03 it's glib code Jun 04 17:21:11 tmzt: it asks for devices with capability "battery" Jun 04 17:21:19 e_hal_device_query_capability(conn, udi, "battery", Jun 04 17:21:19 _battery_hal_is_battery, strdup(udi)); Jun 04 17:21:39 raster: yes, USB is a battery according to hal. Probably it needs fixing. Jun 04 17:21:41 you can follow the code Jun 04 17:21:43 don't see where it sets that in devices.c Jun 04 17:21:48 but it uses Jun 04 17:21:49 msg = e_hal_device_call_new(udi, "QueryCapability"); Jun 04 17:22:25 raster: can you tell me why you think that particular properties of batteries (you count on in charge computations) must be available for any non-broken kernel? Jun 04 17:22:35 ok, if IS_BATTERY == TRUE, it adds that capability Jun 04 17:22:41 PaulFertser: hal should be adervtising 3 batteries. only 1. thats the problem Jun 04 17:22:43 and IS_BATTERY is true in case of usb Jun 04 17:22:44 not the missing properties Jun 04 17:22:54 the propwerties are missing from the devies hat are not batteries Jun 04 17:22:54 :) Jun 04 17:22:56 devices Jun 04 17:22:57 :) Jun 04 17:23:06 raster: do you agree that hal should advertise only one battery and it should be power_supply battery? Jun 04 17:23:16 yes Jun 04 17:23:20 agree 100% Jun 04 17:23:26 if it doesnt ant to do that Jun 04 17:23:30 also, info.category = "battery" Jun 04 17:23:31 advertise /proc/apm Jun 04 17:23:33 but not both Jun 04 17:23:50 raster: ok Jun 04 17:24:03 I can't see why there is c code for this anyway, it's policy and should be in fdi Jun 04 17:24:04 raster: if hal advertised only power_supply battery, it won't work with current code anyway. Jun 04 17:24:18 PaulFertser: which code? e's? Jun 04 17:24:27 raster: yes. Either E or kernel. Jun 04 17:24:39 raster: either E shouldn't count on those properties or kernel should provide it. Jun 04 17:24:45 hmm e's code will be perfectly happy with 1 battery only Jun 04 17:24:57 ? Jun 04 17:25:00 which properties? Jun 04 17:25:02 raster: it will happily compute 0 charge because of the missing properties. Jun 04 17:25:05 e asks hal for a bunch of them Jun 04 17:25:06 PaulFertser: I'm going back $HOME. If you can find the missing property, please say it here so that I can get it in the logs :) Jun 04 17:25:08 it doesnt use all of them Jun 04 17:25:16 rtp: ok Jun 04 17:25:25 but it uses design full and current level Jun 04 17:25:31 PaulFertser: thanks Jun 04 17:25:41 raster: i know you tested on laptop and other devices. My laptop has them. My FR doesn't. Let me show you. Jun 04 17:25:58 which ones tho? Jun 04 17:26:31 i actually made e's batget work perfectly on fr long ago (while aslo telling andy to fix the power_class exposure of it as it was wrong) Jun 04 17:26:32 raster: http://paste.debian.net/38046/ Jun 04 17:26:52 PaulFertser: yesd. i know all of them Jun 04 17:26:59 raster: we don't have design_full and current_level Jun 04 17:27:06 dude Jun 04 17:27:12 you NEED current_level Jun 04 17:27:23 raster: who says? ;) Jun 04 17:27:25 that is how you know how full/empty it is Jun 04 17:28:08 in fact the code will use last_full chareg - unlss its 0 Jun 04 17:28:12 then use desgin_charge Jun 04 17:28:24 Is this required behaviour documented somewhere? Jun 04 17:28:29 current_level is the only thing that lets you measure percentage Jun 04 17:28:40 how will u calculate it then? Jun 04 17:29:07 a battery device not giving a current level is pretty useless for measuring Jun 04 17:30:36 raster: looks like we give current charge in percentage in "capacity" node. Jun 04 17:31:32 raster: so basically you want to have 100 in design_full and the same as capacity in current_level. Then the code will work. But is there really any standard for that? Jun 04 17:31:35 can't that be computed from the other nodes? Jun 04 17:31:56 or does pcf only report percentage? Jun 04 17:32:17 tmzt: no, we can do that however we want. It's just a matter of following some standard. Jun 04 17:32:57 PaulFertser: and % is a direct result of current level / total capacity Jun 04 17:33:15 nb Jun 04 17:33:23 raster: we already expose % in "capacity" node. You seem to believe that's incorrect. Can you prove that? Jun 04 17:33:28 \the code - if degin and last full charge are 0 Jun 04 17:33:36 it uses the perecnt property Jun 04 17:33:50 if (hbat->last_full_charge > 0) Jun 04 17:33:50 full += (hbat->current_charge * 100) / hbat->last_full_charge; Jun 04 17:33:50 else if (hbat->design_charge > 0) Jun 04 17:33:50 full += (hbat->current_charge * 100) / hbat->design_charge; Jun 04 17:33:50 else if (hbat->percent >= 0) Jun 04 17:33:51 full += hbat->percent; Jun 04 17:34:00 the codealready has lots of fallbacks for missing info Jun 04 17:34:02 Saw that code several times. Jun 04 17:34:12 but exposing a % full masn u have the current charge data and he ful charge data Jun 04 17:34:15 We miss more info than your code accounts for ;) Jun 04 17:34:16 they are directly related Jun 04 17:34:27 We have, but we don't expose it (yet). Jun 04 17:34:28 u cant know % full without knowing the other 2 Jun 04 17:34:32 Sure Jun 04 17:34:53 if the kernel driver is not exposing alk the data it has - then it smells to me of a driver bug Jun 04 17:35:05 if basically u dont have enough info to know how ful lthe battery is, if its charging or not etc. Jun 04 17:35:25 tmzt: charge_current comes from bq27k chip in bat Jun 04 17:35:37 not from pcf50633 Jun 04 17:35:37 raster: no, you have percentage in "capacity" node, you have charging status in "status" node. Jun 04 17:35:39 like w1 or i2c? Jun 04 17:36:16 PaulFertser: then there is enough data Jun 04 17:36:21 falling back to percentage makes sense Jun 04 17:36:37 and percentage to m looke like some kernel dev simply not wanting to expose the current charge and full charge Jun 04 17:37:11 raster: probably. But must he? Jun 04 17:37:21 if it exists - he should Jun 04 17:37:28 thats the point of the interface Jun 04 17:37:33 expose as much data as exists Jun 04 17:37:48 let userspace figure out what to do with it. Jun 04 17:37:49 don't unix principals apply here? Jun 04 17:37:54 raster: ack Jun 04 17:38:00 I'm not sure. Not every interface must expose all the data available. Jun 04 17:38:11 the krenle shoudl expose as much as is safe/secure to userspace in a raw form Jun 04 17:38:15 linux/Documentation/power/power_supply_class.txt Jun 04 17:38:27 userspace is there to spend the cycles doing divisions to figure out a percentage Jun 04 17:38:42 Q: Suppose, my battery monitoring chip/firmware does not provides capacity... Jun 04 17:38:45 max_posedon: what's that? Jun 04 17:39:06 http://pastebin.ca/1447779 Jun 04 17:39:58 in short, kernel can but didn't have to provide capacity Jun 04 17:40:04 explanation in docu Jun 04 17:40:32 s/didn't/don't Jun 04 17:41:26 max_posedon: but the battery in the gta02 DOEs provide it Jun 04 17:41:29 DocScrutinizer: it's written that power_supply drivers shouldn't try to provide anything that is not directly measurable. Jun 04 17:41:30 it has a coulomb counter Jun 04 17:41:37 it literally counts coulombs Jun 04 17:41:42 the data is there Jun 04 17:41:48 raster, so, this is kernel bug of course in this case Jun 04 17:41:56 PaulFertser: hat's fine with me Jun 04 17:41:57 raster: ok, i guess i'll try to fix the kernel soon. Who's talking with HAL guys to stop exporting two other "batteries"? ;) Jun 04 17:41:59 if your battery is a dumb apm bios that only exposes a % full - then u dont have it Jun 04 17:42:06 the gta02 does have the info Jun 04 17:42:26 but E souldn't expect that *all* batteries will do this. Jun 04 17:42:40 just don't run hal, doesn't that solve the issue? ;) Jun 04 17:42:53 max_posedon: you saw, E has a good fallback mechanism for that so probably the kernel is really wrong here. Jun 04 17:42:56 especially it's written theres NO % values, only uAh Jun 04 17:43:22 max_posedon: it doesnt. it has fallback code all the way back to percentage Jun 04 17:43:41 lindi-: you still have a usb "battery" as best i understand Jun 04 17:43:44 there is still a kernel bug Jun 04 17:43:54 raster: no, usb battery is HAL bug! Jun 04 17:44:00 PaulFertser: is it? Jun 04 17:44:03 raster: it's hal that considers usb to be a battery. Jun 04 17:44:10 so in power_class sysfs whats the type? Jun 04 17:44:20 raster: it looks at battery types, sees USB and considers it to be a battery. Jun 04 17:44:27 (sorry - no working/booting gta02 here) Jun 04 17:44:39 raster: cat usb/type gives USB. Jun 04 17:44:42 yo, yo folks Jun 04 17:44:49 raster: reading hal code gives "USB" is battery. Jun 04 17:44:53 hi stefan :) Jun 04 17:45:00 hi DocScrutinizer Jun 04 17:45:14 sepultina: :) Jun 04 17:45:17 stefan_schmidt: :) Jun 04 17:45:33 hi PaulFertser Jun 04 17:46:10 PaulFertser: ok. then it is a hal prob indeed Jun 04 17:46:33 PaulFertser: the batery moule has config to go to internal mode (baget) so you can happily use that if you want Jun 04 17:46:36 raster: do you know somebody from hal team to make bugreporting easier? Jun 04 17:46:41 raster: and i do :) Jun 04 17:46:44 batget should report correct valus then Jun 04 17:46:49 stefan_schmidt: steffie! :) Jun 04 17:47:06 PaulFertser: nup. hal guys are opaque to me Jun 04 17:47:15 [2009-06-04 17:57:11] if hal semantics specs fail to convince me on this being the only way to handle, I'd rather start a war against those specs Jun 04 17:47:21 (thus why i'm not volunteering) :) Jun 04 17:47:22 raster: yeah, with internal it works as it should. Jun 04 17:47:33 cool Jun 04 17:47:37 thats good Jun 04 17:47:55 i'e just been a bit confused as i've had differing reports on whats in power_class Jun 04 17:48:06 if that works - then i know whats going on Jun 04 17:48:42 We know that for like 2 months. Jun 04 17:48:50 [2009-06-04 18:39:54] so here come *my hal semantics spec (excerpt)": USB IS NO BAT - period Jun 04 17:48:57 hehehe ok Jun 04 17:48:58 :) Jun 04 17:49:09 DocScrutinizer: it's a hal problem Jun 04 17:49:16 lets all kick hal together for fun Jun 04 17:49:16 :) Jun 04 17:49:23 If somebody (probably i) fix the kernel we'll have 66% with hal still broken. Jun 04 17:51:08 hahaha Jun 04 17:51:10 stefan_schmidt: ping Jun 04 17:51:17 shoragan: ping Jun 04 17:51:22 alphaone|gone: ping Jun 04 17:51:28 * DocScrutinizer really would like to have a persistent log for IRC channel, to point to 8 weeks old quotes Jun 04 17:51:39 onen|openBmap: pong Jun 04 17:51:49 stefan_schmidt: hallo Jun 04 17:51:55 ~logs Jun 04 17:52:01 onen|openBmap: hi Jun 04 17:52:03 ~log Jun 04 17:52:16 hmm, where is our bot gone? Jun 04 17:52:27 ~botsnack Jun 04 17:52:27 DocScrutinizer: aw, gee Jun 04 17:52:35 onen|openBmap: yo! Jun 04 17:52:35 stefan_schmidt: did you see a new thread started today between obm, ch and as always our father to all of us, oci? Jun 04 17:52:44 raster: hi dude! Jun 04 17:52:44 DocScrutinizer: looking for one in particular? Jun 04 17:52:50 onen|openBmap: duuuude! Jun 04 17:53:10 raster: wrong, it's maaaate Jun 04 17:53:14 bzzbot: log Jun 04 17:53:22 tmzt: the ancient conclusions about bat applet and hal Jun 04 17:53:24 e.g. Jun 04 17:53:29 DocScrutinizer: hmm, seems that one does not have logs :( Jun 04 17:53:30 DocScrutinizer: you can find logs in google Jun 04 17:53:40 onen|openBmap: android/google have data base of their own, their is an opt in to submit data and GetNeighbors was mentioned Jun 04 17:53:44 onen|openBmap: just catching up with mail Jun 04 17:53:49 dos1: pointer? never managed Jun 04 17:54:07 stefan_schmidt: ok, wait for your reading finished... Jun 04 17:54:10 "openmoko-cdevel log" Jun 04 17:54:19 * dos1 runs browser Jun 04 17:54:22 onen|openBmap: which list? Jun 04 17:54:30 stefan_schmidt: community Jun 04 17:54:38 tmzt: hi Jun 04 17:54:44 * stefan_schmidt searches... Jun 04 17:54:44 btw - i have almost working selector of shr-splash theme in shr-settings :) Jun 04 17:54:46 dos1: stefan_schmidt: been here as well ;-) Jun 04 17:55:03 (no logs) Jun 04 17:55:18 saw something about HAL irc channel Jun 04 17:55:28 DocScrutinizer: http://logs.nslu2-linux.org/livelogs/openmoko-cdevel/ Jun 04 17:55:32 DocScrutinizer: i think bip server has enough logs. Jun 04 17:55:45 tmzt: yes they have a db, (I bet built from their streetview cars driving all over the place), but this is closed, and you can only use it through web (AFAIK) Jun 04 17:56:20 dos1: :-))) Jun 04 17:56:27 thnx Jun 04 17:56:50 no idea what went wrong last time I searched for it Jun 04 17:56:51 tmzt: what do you mean with opt in to submit data? (with maps they proposed people to draw maps, like openstreetmaps, but the data would belong to them, and if there is legal liability involved, it is the fault of the contributor) Jun 04 17:57:26 tmzt: ah, neighbours, you mean, there is talks about extending the android framework to get neighbours? Jun 04 17:57:33 stefan_schmidt: oh i thought steffie was good for you! :) Jun 04 17:58:27 raster: I should call you big pixel then :) Jun 04 17:59:23 onen|openBmap: to submit data from the gsm stack I think, it says it's required to use A-GPS or something, there was just a discussion about it in #android a few days ago Jun 04 18:00:33 tmzt: I try to follow (from far away) the android stuff. regularly look at api to see if a logger could be built on top of it. What would be a first thing Jun 04 18:00:56 I can only grep one thing at a time, but I'll look next Jun 04 18:01:01 it seems the api is there now Jun 04 18:01:06 tmzt: but after the maps story of google, I want to see the license and so forth before believing anything Jun 04 18:01:40 tmzt: you will look next? what do you mean? Jun 04 18:01:44 onen|openBmap: mails found, answering now. Jun 04 18:01:56 stefan_schmidt: awesome. big pixel. that's all me! Jun 04 18:02:03 stefan_schmidt: perfekt. I was about to ask you if you would like to jump in. Jun 04 18:02:25 raster: hehe :-D I *knew* this would be the response Jun 04 18:03:06 stefan_schmidt: by the way, the sentence from sebastian about collaboration/discussion with us sounds strange to me. I wonder if the english is approximate, or if he tries to imply he did try, but we refused ;-) Jun 04 18:03:35 onen|openBmap: well, we should not overreact. Buys us nothing. Jun 04 18:03:54 onen|openBmap: Will repeat what we want to make it clear. Jun 04 18:04:27 stefan_schmidt: I think the same. I have been wondering the way to answer. I don't want to be the one writing a list of complains about ch and oci. I want to propose collaboration Jun 04 18:05:00 stefan_schmidt: but to be honest, I did try several times already, and I don't know if I did it wrong, or if we just don't see things the same way... Jun 04 18:05:22 onen|openBmap: well, I'm not sure we can arrange a collaborations. Everyone keeps his opinion. Jun 04 18:05:55 onen|openBmap: As soon as there is progress with Nick I bet alphaone|gone and shoragan will just go with it. Jun 04 18:05:58 * PaulFertser thinks Sebastian is mad Jun 04 18:06:12 PaulFertser: heh Jun 04 18:07:25 stefan_schmidt: as you can see, oci import is now done. which makes openBmap the biggest cell db now (which cut the argument from ch ;-) ) Jun 04 18:08:00 mrmoku: moinmoin! :-) Jun 04 18:08:38 stefan_schmidt: Nick next task will be exactly that: propose our data for download. I myself, kind of wait to use next gear with alphaone|gone and shoragan about work together, because I bet they will only really jump on the boat once data is there (I would do the same) Jun 04 18:08:58 onen|openBmap: yup Jun 04 18:08:59 onen|openBmap: what do you think the equivalent for cdma would be? is there any? Jun 04 18:09:22 tmzt: how are the cells of CDMA managed? Jun 04 18:09:36 tmzt: I would think there is not much difference to GSM Jun 04 18:09:44 not sure, I don't even get notifications about that without asking Jun 04 18:09:54 well, I'm not moving much now anyway Jun 04 18:09:59 tmzt: As long as you have some unique cell id it can be used the same way Jun 04 18:10:05 tmzt: what did you mean with: I can only grep one thing at a time, but I'll look next Jun 04 18:10:08 I think so Jun 04 18:10:10 stefan_schmidt, as I know it much different Jun 04 18:10:11 onen|openBmap: logs Jun 04 18:10:23 cdma protocol allows get coordinates from provider Jun 04 18:10:24 DocScrutinizer, yo Jun 04 18:10:29 max_posedon: oh, really? Never done anything with CDMA yet Jun 04 18:10:41 max_posedon: even better :) Jun 04 18:10:41 tmzt: cdma, don't know :-( US is moving to modern technology (gsm) anyway :-P Jun 04 18:10:54 yayeah well, Jun 04 18:11:01 gsm modern, cdma - no?))) Jun 04 18:11:10 onen|openBmap, are you kidding?) Jun 04 18:11:41 max_posedon: no, just talking without knowing :-P Jun 04 18:11:44 cdma is the more modern technology, even umts uses it Jun 04 18:11:56 but cdma2000 is not the newest implementation Jun 04 18:12:05 and we still have a variant of that Jun 04 18:12:52 max_posedon: tmzt: jokes aside, I don't know about cdma, but I will ask Nick, to see if he has some knowledge Jun 04 18:13:44 well, I don't know much about cdma too, but I used it 3 years, and know person who did some programming for it(for brew). nothing more. Jun 04 18:13:46 tmzt: it seems Nick thinks we should be able to make sth with it, the same way as gsm Jun 04 18:14:05 thanks, unfortuanately all of our towers are owned/registered by different companies so fcc is of no help Jun 04 18:14:09 nick? Jun 04 18:14:32 tmzt: nick is the server side guy from openBmap Jun 04 18:14:39 oh ok Jun 04 18:14:54 I think I have to use DIAG protocol to get this stuff though, not AT commands Jun 04 18:14:58 so it will come later Jun 04 18:15:43 tmzt: not sure, we have a windows mobile client, which logs 3G cells, but gets gsm data out of it. I am not sure how all of this works. would need some searching Jun 04 18:16:04 afaik cmda has a way to more accurately determine mobile's position. this is an active triangulation though which has to be supported by provider. usually they don't afaik Jun 04 18:16:14 it has to to work Jun 04 18:16:36 the cell has to know what sector you are in I believe Jun 04 18:17:49 tmzt: if cdma allows other positioning system, my logger will be glad to try to log it :-). If we can use cdma cell and apply the same approach as what we are trying now to make a map of cell coverage, then good to! Jun 04 18:17:58 cmda has a way to determine time skew for a set of concurrently receiving BTS. it's not about sectors Jun 04 18:18:35 DocScrutinizer: hallo! by the way. I did some commits about timing advance for you. Are you still interested in this? (my problem is the fact I need an open connection for ta to make sense) Jun 04 18:18:45 onen|openBmap: ok, was just wondering, I have to get my gps data from some rpc protocol anyway if it works at all (carrier blocks it) Jun 04 18:18:49 and BTS have to establish a special communication among them to sync their timebases Jun 04 18:19:05 BTS? Jun 04 18:19:32 Base Transmitter Station Jun 04 18:19:39 tmzt: of course I would love to see you jump on the boat and build sth around cdma ;-) Jun 04 18:20:20 I hope to when phone calls with sound actually work and can expose the DIAG port to userspace Jun 04 18:20:32 max_posedon: is cdma the mobile technology the USA has been using so far, or am I mixing? Jun 04 18:20:54 FYI the hal commit adding USB as a battery: http://cgit.freedesktop.org/hal/commit/?id=bed698872323c46fc6b44ffde10b1b2244b7e228 Jun 04 18:20:57 two of the major carriers in the US use it and some of the minor ones Jun 04 18:21:23 DocScrutinizer: is there a a good resource to learn more about this? Jun 04 18:21:26 onen|openBmap: sure, I'm still interested in this topic. You can establish a open connection by sending an invalid GSM-opcode (dunno right word), e.g. "*123456**#" Jun 04 18:21:43 tmzt: nobbi.com Jun 04 18:21:59 for a starting point Jun 04 18:22:05 I hope cdmatech comes back after the settlement Jun 04 18:22:11 ok, thanks Jun 04 18:22:30 yes, g-p-m related, thought so Jun 04 18:22:45 tmzt: wtf g-p-m? Jun 04 18:22:51 gnome-power-manager Jun 04 18:22:57 DocScrutinizer: yes, suggestion has been made to call an inexisting number. I was thinking about calling my answering machine, which allows to let the phone in communication while logging. but I would like to optimize battery usage Jun 04 18:22:58 onen|openBmap: at least this works for nokia 6250 Jun 04 18:23:00 onen|openBmap, I don't know anything from cdma in USA, I'm from Belarus, you know) Jun 04 18:23:39 if you kill the audio will it transmit less? Jun 04 18:23:44 max_posedon: ;-) Jun 04 18:24:50 USB power supply has to be for hid devices, wish I could find in the kernel where the power_supply node is registered Jun 04 18:24:51 tracfeed: Ticket #474 (cannot reply sms in native language) closed Jun 04 18:26:14 raster: hey, in fact the problem is that we have too many nodes: Jun 04 18:26:15 if (hbat->last_full_charge > 0) Jun 04 18:26:15 full += (hbat->current_charge * 100) / hbat->last_full_charge; Jun 04 18:26:24 raster: we have last_full_charge :) Jun 04 18:26:44 raster: but battery.charge_level.current is 0 always. Jun 04 18:27:08 onen|openBmap: a USD msg (guess that's the word) will establish minimum data transfer I guess -> minimum TX, minimum power consumption Jun 04 18:27:35 onen|openBmap: of course a single ping via gprs would serve as well Jun 04 18:27:45 kazer, ping Jun 04 18:27:51 PaulFertser: culd you have a glance at http://wiki.openmoko.org/index.php?title=WM8753&diff=0&oldid=63862 please? Jun 04 18:28:01 DocScrutinizer: ok. but will I be sure that between sending it, and reading the ta, the ta will be for sure sth which makes sense? Jun 04 18:28:33 dunno, it worked for nokia. no idea about calypso Jun 04 18:29:10 by concept TA should be sticky, no? ;-) Jun 04 18:30:00 hmm, 32G sd for $99US Jun 04 18:30:07 DocScrutinizer: sticky? Jun 04 18:30:08 almost tempting Jun 04 18:30:10 duh!!! Jun 04 18:30:36 onen|openBmap: persistent until new value is actually calculated Jun 04 18:30:42 tmzt: you seems interested in android, maybe you would like to build a client for obm on top of it? 0:-) Jun 04 18:31:03 DocScrutinizer: (wiki edit) if the page is about sound card then link is sort-of-right because it uses wrong commit (too old). Jun 04 18:31:25 onen|openBmap: not really interested in the api/userland, more kernel Jun 04 18:31:41 PaulFertser: k, thanks Jun 04 18:31:42 DocScrutinizer: what I understood from conversation in Essen: ta makes sense only when active connection (ok I am quite unprecise about what this actually is). some phones gives only a value when it makes sense Jun 04 18:31:58 onen|openBmap: I'm working on the port to htc msm devices and g1 kernel is a good basis, we are working in #htc-linux on that I mean Jun 04 18:32:07 DocScrutinizer: but, calypso gives always a value. and when 0, you don't know if this is a true value or nothing. Jun 04 18:32:27 DocScrutinizer: or probably it's fully correct, i can't understand how to use webgit properly yet. Jun 04 18:32:28 onen|openBmap: so what's he duration of "active communication" for a GPRS ping? ;-) Jun 04 18:32:31 DocScrutinizer: but it makes me think... then everytime ta is different from 0, I could already log it! Jun 04 18:33:04 yup Jun 04 18:33:38 DocScrutinizer: that is the whole point! I try to figure out a way to trigger a real value, long enough to be sure of quality of wha t I read, and in a way which save battery (and ideally would allow people to still use their phone normally) Jun 04 18:34:10 GPRS is the way to go then I'd guess Jun 04 18:34:12 DocScrutinizer: ok good, code is all there for a out of call ta reading. I will try it. only for you ;-) Jun 04 18:34:27 cool :-) Jun 04 18:34:31 DocScrutinizer: but in France you pay for using it :-( Jun 04 18:34:57 onen|openBmap: actually for time of usage? o.O Jun 04 18:35:38 DocScrutinizer: you mean, ping would still not count as time of usage, and would cost nothing? Jun 04 18:35:59 stefan_schmidt: should I wait for your answer before jumping in the conversation Jun 04 18:36:12 raster: About time to add elementary docs to docs.enlightenment.org? Jun 04 18:36:18 well, it takes the network a certain time to answer a USD (even a malformed one), even better you do sth like "*#61#". I'd think this is for free and still should yield a TA value Jun 04 18:36:41 onen|openBmap: would say so. If you have something to correct jump in, if not, wait how it turns out Jun 04 18:36:57 onen|openBmap: nah, only if it's mere volume of data, a oing isn't that expensive Jun 04 18:37:08 s/oin/pin/ Jun 04 18:37:10 DocScrutinizer meant: onen|openBmap: nah, only if it's mere volume of data, a ping isn't that expensive Jun 04 18:37:12 onen|openBmap: We should spent less time on writing emails about this topic again and again. Not technical emails that is. Jun 04 18:37:32 moin alphaone Jun 04 18:37:57 moin Jun 04 18:38:01 f*cking lenovo support Jun 04 18:38:04 moin alphaone Jun 04 18:38:16 oooh? :-/ Jun 04 18:38:18 They send an inverter card as repair Jun 04 18:38:32 I clearl stated I have a LED backlight Jun 04 18:38:42 ouch Jun 04 18:38:43 The model number clearly states the same Jun 04 18:38:54 idiots Jun 04 18:39:02 Lucky I still got my X40 Jun 04 18:39:16 alphaone: new date with the tech dude? Jun 04 18:39:18 Never had any real problems with that one Jun 04 18:39:23 stefan_schmidt: Not sure Jun 04 18:39:26 maybe tomorrow Jun 04 18:39:29 alphaone: you're supposed to fix it yourself? Jun 04 18:39:32 if the display is there Jun 04 18:39:37 * stefan_schmidt had two motherboard changes with his T40p Jun 04 18:39:45 DocScrutinizer: no, it came with the ibm tech Jun 04 18:39:50 alphaone: Apple next time? ;) Jun 04 18:39:51 aah Jun 04 18:39:54 haha Jun 04 18:40:29 Okay, gtg karate Jun 04 18:40:33 might be on later Jun 04 18:40:34 alphaone: See it as option to use you desktop more :) Jun 04 18:40:35 bye Jun 04 18:40:39 alphaone: have fun Jun 04 18:40:49 panasonic toughbook - never breaks. never stress with repair dudue ;-) Jun 04 18:40:50 (btw you're right about me waiting for the public data) Jun 04 18:41:01 Yeah, I'm thinking about it Jun 04 18:41:40 DocScrutinizer: yeah, it's also slow, heavy, pricy and ugly :) Jun 04 18:42:29 ugly is the nice thing about it. my CF-27 had the hostname "Panzermine" Jun 04 18:42:40 mickey|sun: ping Jun 04 18:43:03 DocScrutinizer: lol Jun 04 18:43:03 heavy - you can't catch bullets with a sheet of paper ;-) Jun 04 18:43:29 DocScrutinizer: sure, nano-paper. Give me vc for some solid research :) Jun 04 18:43:39 hehe Jun 04 18:45:08 actually I triggered a hype here with my CF-27 Jun 04 18:46:48 it's considered maximum geek to own one (and shock ppl at 25C3 when accidentally knocking their glass waterbottle really hard with it - it's not the CF-27 that breaks ;-) Jun 04 18:49:16 DocScrutinizer: (bullet-proof) made some enemies during your career ? ;-) Jun 04 18:49:35 DocScrutinizer: do you have any solid experience with bq7000? Do you know is there a register to read current charge to compare it with last_full_charge (currently read from BQ27000_LMD_L)? Jun 04 18:49:50 well it was the guy with the bottle hitting my friend's cf27, still he looked like being attacked Jun 04 18:50:04 wpwrak: It's not a career if not, right? Jun 04 18:51:01 * stefan_schmidt pokes raster do document the elementary entry module Jun 04 18:51:15 DocScrutinizer: sorry for late answer. well I will first try to see how calypso works, to already log ta > 0. then I will come back to you, to list possibilities, if you don't mind (ToDo list is getting crowded :-( ) Jun 04 18:51:25 PaulFertser: sorry, nothing beyond datasheet Jun 04 18:51:55 onen|openBmap: any time you like Jun 04 18:52:06 tmzt: that's great! I have a bunch of htc phone and glofiish at work, and would love to finally see one of them run android/SHR+FSO nicely Jun 04 18:52:17 what phones? Jun 04 18:52:35 DocScrutinizer: i meant if you know the answer without looking it up in the DS, i could use it, if not, well, i'll read the datasheet Jun 04 18:53:12 there is max-charge in sysfs Jun 04 18:53:14 DocScrutinizer: or maybe mail me the approaches you have in mind, I can write it down either on obm wiki, or om wiki, or anywhere you think this could fit Jun 04 18:54:08 DocScrutinizer: it's called "charge_full". And is read from BQ27000_LMD_L Jun 04 18:54:18 DocScrutinizer: I am interested in finding a way to make, that is gratis. Even is this is different regarding countries and/or operators. otherwise I will need to put huge warning for user on GUI ;-) Jun 04 18:54:36 stefan_schmidt: good point ;-)) Jun 04 18:55:09 stefan_schmidt: ok then I wait for you email response to seb. I will then additionaly answer mails from others, who ask question about obm api and so on... Jun 04 18:55:26 onen|openBmap: ok Jun 04 18:55:29 wpwrak: :) Jun 04 18:55:35 stefan_schmidt: he he, you are loosing patience even faster than I did :-P Jun 04 18:55:54 onen|openBmap: the approach is simple: have a database with one recording per location, not one per BTS. Each location has as many properties (including TA) as you can get for it Jun 04 18:56:11 onen|openBmap: I like to get this settled. No way to please everyone involved. Jun 04 18:56:30 onen|openBmap: USD should be free all over the world Jun 04 18:57:05 s/USD/$ (hehe)/ Jun 04 18:57:05 DocScrutinizer meant: onen|openBmap: $ (hehe) should be free all over the world Jun 04 18:58:31 tmzt: oh, name one: htc tytn, tytn2, p3600, diamond, touch hd, eten x500 Jun 04 18:58:35 PaulFertser: back. from what I understand, capicity is not enough and thus we need more sysfs info ? Jun 04 18:58:36 Do we have libglade in OE? Jun 04 18:58:52 rtp: well, now i'm investigating what we have and what we don't Jun 04 18:59:10 rtp: it appears that E's fallback mechanism is mislead by weird kernel interface. Jun 04 18:59:38 rtp: if (hbat->last_full_charge > 0) full += (hbat->current_charge * 100) / hbat->last_full_charge; and we have last_full_charge but lack current_charge. Jun 04 19:00:03 DocScrutinizer: sure thing, raw data will bring you exactly this. Now for db, don't know if Nick is willing to spend time on ta approach. But this can be discussed later, right? Jun 04 19:00:44 PaulFertser: I see.. so with current_charge add, it should be ok ? Jun 04 19:00:55 DocScrutinizer: well the exchange rate with our currency goes in that direction ... ;-) Jun 04 19:00:58 rtp: yes. I'm currently investigating this possibility. Jun 04 19:01:20 Heinervdm: I do use glade, yes Jun 04 19:01:45 onen|openBmap: diam and blak are coming, tytn2 is kaiser right? Jun 04 19:02:04 onen|openBmap: I should say phone functionality is coming, linux works now Jun 04 19:02:15 tmzt: diam and black are coming (you mean support is getting close to working?) Jun 04 19:02:38 onen|openBmap: yes, umts should be working now with the latest patches Jun 04 19:02:41 PaulFertser: great :) Jun 04 19:02:49 onen|openBmap: thx i think i found the package Jun 04 19:03:04 tmzt: tytn == Hermes (Mercury) Jun 04 19:03:20 onen|openBmap: tytn2 Jun 04 19:03:38 tytn 2 == kaiser, yes Jun 04 19:03:56 it's working as well, dzo who did vogue is supporting it in his tree Jun 04 19:04:14 tmzt: awesome! where could I follow progress, xda wiki pages? Jun 04 19:04:44 onen|openBmap: #htc-linux, htc-linux.org I think is the main wiki for new stuff, androidhtc.com, not sure what else Jun 04 19:05:22 tmzt: |-( come on guys, could you make only one place to follow :P Jun 04 19:05:51 I only follow #htc-linux so I don't know, but some people want the others updated Jun 04 19:06:03 I mean expect the others to be updated Jun 04 19:09:52 tmzt: thanks Jun 04 19:10:53 stefan_schmidt: sorry to bother again, when do you plan to send your answer? (I don't want to make seb right, by being late to answer people ;-) ) Jun 04 19:11:40 onen|openBmap: I don't even have checked mails again :) Jun 04 19:12:11 onen|openBmap: oh, you mean his first mail? Jun 04 19:12:50 missed that, will ask for more details Jun 04 19:34:22 every time I read RTC clock kernel spams my logs. I see ./drivers/rtc/rtc-pcf50633.c: dev_dbg(dev, "RTC_TIME: %u.%u.%u %u:%u:%u\n", -- any idea how to make this dev_dbg not print these? Jun 04 19:35:20 lindi-: i'll have a look Jun 04 19:36:54 PaulFertser: CONFIG_RTC_DEBUG=y Jun 04 19:37:37 (I'm just going through bugs that have accumulated during the last month) Jun 04 19:38:14 lindi-: exactly. Will send a patch to remove it from gta02 configs promptly, are you ok with that? Jun 04 19:38:34 PaulFertser: no need to change the default if you don't want Jun 04 19:38:52 PaulFertser: now that I know how to disable it here Jun 04 19:38:53 lindi-: i think it's not something that should be in released kernels. Jun 04 19:39:06 PaulFertser: ok, then go ahead, thanks! Jun 04 19:54:44 raster: ok, i've sent a patch fixing kernel interface. Now we need to somehow fix HAL :-/ Jun 04 20:00:52 I'm having trouble connecting to the GSM modem on the phone so I can send AT commands, can anyone help? Jun 04 20:02:17 here is better Jun 04 20:02:58 I tried mickeyterm and it said there were no channels available Jun 04 20:03:31 actually, now it's saying DBus.Error.NoReply Jun 04 20:04:34 PaulFertser: the next bug is gps power on issue: https://docs.openmoko.org/trac/ticket/2293 Jun 04 20:06:55 lindi-: good analisys :) BTW, why don't we receive trac updates on kernel ML anymore? Or do we? Jun 04 20:07:19 lindi-: ah, Opened 85 seconds ago Jun 04 20:07:20 :) Jun 04 20:07:45 PaulFertser: I keep a personal bug list on the phone which I dump to trac when I have time :) Jun 04 20:08:19 PaulFertser: if only somebody wrote a distributed bug tracking tool... I'd love to be able to checkout the whole trac Jun 04 20:10:21 now the only major issue is wlan. I guess I need to start bisecting when and what broke it Jun 04 20:12:55 lindi-: what if it's transition to linux SDIO stack? Jun 04 20:13:49 PaulFertser: it isn't. I have a kernel after SDIO stack transition that worked for two months without trouble Jun 04 20:14:07 PaulFertser: (without wlan trouble) Jun 04 20:14:28 lindi-: i had a kernel panic because of wlan recently. But it mostly worked for me. Jun 04 20:14:43 PaulFertser: to help in bisecting. do you know if Qi would accept a patch that change the boot order as follows: 1) if (first SD part)/boot/multiboot exists then using AUX will cycle between (first SD part)/boot/uImage-GTA02-{0,1,3}.bin instead of SD partitions 1, 2 and 3? Jun 04 20:14:56 PaulFertser: I hit wlan panics with current andy-tracking too Jun 04 20:15:03 PaulFertser: especially if I try to unbind it when its stuck Jun 04 20:15:59 PaulFertser: I'd like to avoid having to create three dummy partitions just to have a way to boot the kernel with three different boot options. And yes, I know you'd suggest kexec here :) Jun 04 20:16:02 lindi-: i'm afraid a patch like that is a bit too weird... Jun 04 20:16:33 is dfu still supported? Jun 04 20:16:39 tmzt: by u-boot Jun 04 20:16:55 PaulFertser: yes it's bit weird but Qi does not have a configuration file so :/ Jun 04 20:16:56 but you need to bisect modules as well? Jun 04 20:17:00 lindi-: can you just automatically adjust symlink after every boot? Jun 04 20:17:14 tmzt: I want to bisect without PC :) Jun 04 20:17:33 PaulFertser: yeah if it boots Jun 04 20:17:34 ah Jun 04 20:18:00 lindi-: is our kernel non-bisectable because it doesn't always boot? Jun 04 20:18:01 PaulFertser: but my kernel hacking skills are bit rusty, I crash the system 80% of the time :) Jun 04 20:18:12 PaulFertser: no, but my debug prints can kill it :) Jun 04 20:19:01 but well, I guess I could add at least one very small extra partition to the end of SD card Jun 04 20:21:22 SHR people, anyone? I would like to know if testing is the right choice for me (I want sth to run my app, stable if possible), and would like to know if WPA works on testing and/or unstable through gui? Jun 04 20:22:02 PaulFertser: working: b8b36e5ec3db71d5 Wed Jan 7 09:39:02 2009 Jun 04 20:22:05 PaulFertser: broken: 9ecc089861ab238e Sat May 23 17:54:00 2009 Jun 04 20:22:38 onen|openBmap: is it gtk? Jun 04 20:22:45 not that matters Jun 04 20:23:07 tmzt: yes it is Jun 04 20:24:19 or another way to see things, FSO M5.1 makes connection to a windows box not working (kernel problem?). I use the image, without update. Is this a know problem, and is it corrected now? Jun 04 20:24:33 onen|openBmap, I would suggest unstable instead Jun 04 20:26:16 mrmoku: is it? why? Jun 04 20:27:01 wasn't there some rumour abot a "stable" SHR-oemerge available by today? ;-) Jun 04 20:27:10 mrmoku: budfive and I hunt down a bug yesterday, and it was the gsm monitoring interface for neighbour cells which was timing out to my dbus call. I have never experienced this with FSO5.1. Thus I wonder if unstable would be a good choice ;-) Jun 04 20:28:40 onen|openBmap: there's a nasty bug in dbus-libs, which FSO is suffering from Jun 04 20:28:58 what's the url to that bug? Jun 04 20:29:00 DocScrutinizer: what kind of bug? Jun 04 20:29:41 FSO guys are struggling hard to find and fix it. It's sth like msgs going to dev/null randomly Jun 04 20:29:50 lindi-: have you reported the panic message? Is there any? What is that wlan failure you're talking about? Jun 04 20:31:13 onen|openBmap, hmm... we have some problems with dbus... yes :( Jun 04 20:31:14 Arhuaco: hey Jun 04 20:31:26 PaulFertser: "#2277 Wireless does not work with the 2.6.29 kernel" Jun 04 20:31:41 Arhuaco: hey, how's sao paulo ? having fun ? Jun 04 20:31:47 DocScrutinizer: that sounds like something I could have hit. do you remember the report? Jun 04 20:32:00 sorry no Jun 04 20:32:00 wpwrak: No. I don't like to travel I found. Jun 04 20:32:13 Hello PaulFertser. Jun 04 20:32:33 DocScrutinizer: but it should be in trac.freesmartphone.org? Jun 04 20:32:40 onen|openBmap, dunno then... try testing :P Jun 04 20:32:45 I'd say yes Jun 04 20:32:48 but my guess would be its just the same Jun 04 20:32:58 lindi-: you're exceptionally good at bugreporting, thanks Jun 04 20:33:24 mrmoku: DocScrutinizer: to be honest, I personnaly use Linux, and it works enough for me. no need for gui. Nick only need a usb connection working with windows. then we only want to use it for obm. real phone will come later Jun 04 20:34:48 DocScrutinizer: was it mentioned on IRC? I have full IRC logs so I could search those Jun 04 20:35:07 mrmoku: DocScrutinizer: I will give it a try. it should not make much difference if FSO M5.5 or SHR (unstable) because they use same framework, right? Jun 04 20:35:37 Arhuaco: still suffering from the flu ? or is it just that sao paulo isn't interesting ? Jun 04 20:35:45 onen|openBmap, don't think so. Jun 04 20:35:56 (depends what you mean with fso ms5.5) Jun 04 20:36:15 onen|openBmap, if you mean the branch in OE... or the image Jun 04 20:37:04 DocScrutinizer: at least none of http://trac.freesmartphone.org/query?status=accepted&status=assigned&status=in_testing&status=new&status=reopened&summary=%7Edbus&order=priority ring a bell Jun 04 20:37:23 wpwrak: I'm better from the cold, thanks. Since yesterday. It's just I'm too lazy to go out :-) I've doing the normal stuff. Having lunch, dinner, etc. Jun 04 20:37:27 mrmoku: ok you lost me :-P well dont bother, I will try one, and if I don't run through the bug, then it is fine enough for me :-) Jun 04 20:37:44 onen|openBmap, :) ok Jun 04 20:37:46 lindi-: iirc it was on irc Jun 04 20:37:50 DocScrutinizer: no problem, found #openmoko-cdevel.05-30.log:22:18 < DocScrutinizer> mickey|bbl: what's current status of this nasty dbus-lib bug? Jun 04 20:37:52 PaulFertser: cool. now you've become a regular kernel hacker. welcome to this exclusive club ! ;-) Jun 04 20:37:57 * mrmoku hopes to find onen|openBmap again... some day :P Jun 04 20:38:16 Arhuaco: yeah, winter is a good time for being lazy :) Jun 04 20:38:18 wpwrak: thanks :) actually i haven't. Jun 04 20:38:33 lindi-: k, :-) Jun 04 20:38:48 was off my log here Jun 04 20:38:56 * onen|openBmap will find my way back for sure, but navit uses osm maps, and some times, it makes you take longer ways, because does not know all the roads exist Jun 04 20:39:19 PaulFertser: the number of patches with your name on it is growing day by day. i'd say that counts :) Jun 04 20:39:21 lindi-: you already know that i got python hang on some futex and couldn't find any way to debug that? Jun 04 20:39:33 PaulFertser: nope, I didn't hear about that Jun 04 20:39:46 navit works with openmoko? For me it was extremely slow and couldnt find any street name in budapest Jun 04 20:40:26 khiraly1: --enable-soft-float? Jun 04 20:40:30 I used tangogps instead. Jun 04 20:40:43 khiraly1: dont know, I simply installed the .ipks Jun 04 20:40:45 wpwrak: the nastiest bugs (wifi-related) are still there and it doesn't look like i'll be able to do anything about it. Jun 04 20:40:53 khiraly1: navit is bit confusing to configure. surely nothing to do with freerunner hardware fortunately :) Jun 04 20:41:06 khiraly1: grep the source for how it calls ./configure Jun 04 20:41:19 PaulFertser: this #2277? Jun 04 20:41:26 lindi-: If there is a premade .ipk file for freerunner, I will happily try it out Jun 04 20:41:43 lindi-: no, reports about some APs working with .24 and not working with .28/.29. Jun 04 20:41:55 PaulFertser: Can you help me with a non-working Qi on Openmoko? Jun 04 20:42:12 flohack: probably. What's the problem? Jun 04 20:42:13 PaulFertser: the really deep ones will probably never get fixed :-( i sound try to find some time some day to add (and test - that's the messy part) that restart-on-crash logic, though. Jun 04 20:42:31 wpwrak: yes, i was basically hinting at that. ;) Jun 04 20:42:40 khiraly1: nope i don't use ipkg Jun 04 20:42:49 khiraly1: just check how your ipkg was built Jun 04 20:43:06 PaulFertser: ok, that's more challenging to debug Jun 04 20:43:22 PaulFertser: I'm trying to install android-koluu b7, but Qi just vibrates and flashes the red LED and then sits there and does nothing (backlight off). Jun 04 20:43:38 PaulFertser: The same happens when I try to boot without an SD card into OM 2009 Jun 04 20:43:43 flohack: i've heard koolu uses a qi fork for some reason. Jun 04 20:43:57 PaulFertser: it's not forgotten ... :) Jun 04 20:44:39 (qi fork) sounds bad. that shuold be merged back. there's no conflicting development going on in our branch anyway Jun 04 20:44:43 PaulFertser: AFAIR I tried the stock Qi from OM2009 as well Jun 04 20:44:48 In fact what bothers me most with my FR atm is that i have to restart frameworkd after almost every incoming call. Jun 04 20:45:00 PaulFertser: I'll try that again Jun 04 20:45:05 wpwrak: they "repartitioned" nand even. Jun 04 20:45:21 flohack: have you read the wiki page carefully? Jun 04 20:45:49 PaulFertser: ah, that would explain it. yeah, nand just sucks :) Jun 04 20:46:03 wpwrak: (conflicting development) it'd be nice if Andy announced his new branch on our ML for us to send patches there. Jun 04 20:46:08 PaulFertser: The one about Qi or android? Jun 04 20:46:13 flohack: Qi Jun 04 20:46:21 PaulFertser: he probably doesn't even want us to bother him :) Jun 04 20:46:37 flohack: because if you read it very carefully, you'll be able to boot from SD. Jun 04 20:47:05 wpwrak: Don't you think Qi is feature-complete already? Jun 04 20:47:58 wpwrak: btw, i need your opinion about Qi tweaks: Jun 04 20:47:59 PaulFertser: Do you know if stock Qi should boot the Android beta7 as well? Jun 04 20:48:45 PaulFertser: (feature-complete) no. i think it should have text output on the lcm. and i think there may be valid use cases that need FAT. Jun 04 20:49:27 wpwrak: when i was at emdete's i made Qi boot from his SDHC card on his gta01. What was problematic is that i had to adjust delays and after that to lower the frequency. It is possible that his SD slot was a bit damaged and it is possible that it's his SD card is just picky (after all, we have special code in kernel to start slowly). What should we do with Qi? Jun 04 20:49:28 PaulFertser: and there's probably a number of minor issues as well. also, we don't have that boot menu mini-distro yet. Jun 04 20:50:14 flohack: yes, it can boot the kernel and then the kernel will work like intended, provided it doesn't need any tricky parameters that can't be overwritten in append-GTA02 file. Jun 04 20:50:27 wpwrak: (mini-distro) not Qi problem. Jun 04 20:50:35 wpwrak: it's just not needed Jun 04 20:50:40 PaulFertser: unless the difference is too radical, i'd say qi should just use conservative settings. if you have to make it 10% slower, nobody will really notice. Jun 04 20:50:43 (enough for someone to bother) Jun 04 20:51:30 wpwrak: our kernel starts accessing the card with 10 times (or more) slower freq. Jun 04 20:51:51 PaulFertser: (mini-distro) well, it fills a few holes in the architecture. better to do it before you need it badly, because it needs a bit of work to do properly. otherwise, people will just try to find band-aids and things get complicated and fragile. Jun 04 20:52:46 PaulFertser: can you just dynamically adjust the frequency ? try at X, if that fails, try at X/2, and so on. give up and move on to the next option at X/16 or such. Jun 04 20:53:44 wpwrak: well, that would be a good Qi improvement... Jun 04 20:53:53 PaulFertser: Ok, I flashed Qi from http://downloads.openmoko.org/distro/testing/, removed the Sd card, checked that the device boots from NAND using NOR u-boot. Qi still hangs after the flash and vibrating Jun 04 20:54:04 wpwrak: or better implement exactly what our kernel does. Jun 04 20:54:17 flohack: flash kernel again Jun 04 20:54:19 flohack: are you sure it hangs? Jun 04 20:54:25 dos1: no, he boots from NOR Jun 04 20:54:29 flohack: how do you tell? Jun 04 20:54:57 PaulFertser: backlight is off, Wiki says it should be on as soon as a kernel is booted Jun 04 20:55:14 flohack: yes, backlight should be on... Jun 04 20:55:41 PaulFertser: Anything I can try to do to get more clues? Jun 04 20:56:14 flohack: hm, let me check.. Jun 04 20:56:49 PaulFertser: (implementation) yes, that may be safer. whatever is easier to do :) Jun 04 20:59:49 TVP (polish television)... they didn't show "rock you like a hurricane" in Scorpions concert :( Jun 04 21:00:01 the best songs are as bis... and they cut bis :/ Jun 04 21:04:35 flohack: no, i think i have no ideas. The kernel boots from NAND with NOR u-boot but Qi can't start it... Very weird. If only you have a debug board... Jun 04 21:04:40 had Jun 04 21:05:03 PaulFertser: Unfortunately I don't Jun 04 21:05:27 Too bad there is no serial console for early boot :-( Jun 04 21:06:30 wpwrak: probably another difference between Qi and NOR u-boot bad block practicies? Jun 04 21:07:37 PaulFertser: i wouldn't be surprised ... i vaguely remember that we had one such issue. not sure if it was actually resolved. Jun 04 21:08:00 wpwrak: i guess it wasn't. Discussed in details and forgotten. Jun 04 21:08:01 PaulFertser: a dump of the bad block map may help. ah, where did i put that utility ... Jun 04 21:08:30 svn.openmoko.org/developers/werner/badnand Jun 04 21:08:48 wpwrak: we should compare bad block information in OOB and in BBT. Jun 04 21:09:05 SHR: 03mok 07shr-makefile * r78fcff78fd49 10/Makefile: Makefile: remove shr overlay from BBFILES for shr-unstable Jun 04 21:09:11 PaulFertser: i'd be afraid that you may find something ;-))) Jun 04 21:09:33 PaulFertser: I remember reading a few bad block messages during the automated Android installation Jun 04 21:10:09 is AT+CRSM supported? Jun 04 21:11:09 flohack: i'll give you a binary Jun 04 21:16:46 flohack: https://paulfertser.is-a-geek.org/files/badnand Jun 04 21:17:09 PaulFertser: Copy to Freerunner and execute it I suppose? Jun 04 21:17:11 flohack: i'll be unable to analise the output, will be afk for several days. Jun 04 21:17:14 flohack: yes. Jun 04 21:17:31 flohack: probably wpwrak will have some time to look at it. Jun 04 21:18:01 PaulFertser: I'll get the results and mail it to wpwrak Jun 04 21:18:20 wpwrak: Can you please give me you email address (private chat)? Jun 04 21:18:37 DCJacket: the firmware image at least mentions it Jun 04 21:18:42 flohack: werner@openmoko.org (no secret about that one ;) Jun 04 21:19:32 wpwrak: Sorry, I'm not familiar with the IRC nicknames of openmoko VIPs :-) Jun 04 21:19:34 lindi - I see that, and AT+CRSM=? returns "OK" but nothing else Jun 04 21:19:46 and I can't figure out a set of parameters that it likes Jun 04 21:20:46 * PaulFertser waves goodbye Jun 04 21:20:56 bye PaulFertser Jun 04 21:21:14 Zorkman: hi, how are you doing? Jun 04 21:21:24 Zorkman: have you seen that stuff on ML? The guy reflashed his kernel properly and got SHR back. Jun 04 21:21:56 DCJacket: did you google for it? Jun 04 21:22:12 Zorkman: Ainulindale and I brought three operators cells for going through your country (Belgium right?) Jun 04 21:22:35 lindi - yea, I found this - http://www.g1sat.com/files/HNS_9201_AT_Reference.htm#AT_plusCRSM - but it didn't like that at all Jun 04 21:23:27 Zorkman: so you got a nice increase of data there :-) Jun 04 21:23:33 PaulFertser: Thanks for your help! Jun 04 21:24:00 mrmoku: Which parameter would I have to pass to badnand? Jun 04 21:24:48 SHR: 03dos 07shr-themes * rb35d70e7211c 10/shr-splash/ (6 files in 2 dirs): shr-splash-theme-*: provide more theme information Jun 04 21:24:53 flohack: /dev/mtd6 Jun 04 21:30:10 DCJacket: i'd love to be able to have the source for that part Jun 04 21:31:21 onen|openBmap: yes indeed :D i saw it Jun 04 21:31:43 just have my FR back (since yesterday, so not yet done any new mapping) Jun 04 21:32:02 having some problems with my NAND, but i'm sure they're not here to stay :) Jun 04 21:33:19 onen|openBmap: you merged with opencellid? Jun 04 21:34:14 flohack: ;-) Jun 04 21:36:12 Zorkman: we have imported oci data in our database Jun 04 21:36:37 Zorkman: Nick is finishing tests. So we did not communicate about it so far. Jun 04 21:36:41 wpwrak: I just sent the email. Jun 04 21:37:28 Zorkman: there is no merge, and no collaboration out of exchanging raw data so far. Today someone started a new thread about this on community ML. I wait for Stefan to answer before jumping in Jun 04 21:38:12 Zorkman: by the way, the guy on that thread asks for users comments about the two projects ;-) ... Jun 04 21:38:32 onen|openBmap: read it, and i'm going to comment on it Jun 04 21:38:44 it also find it strange they tell you are agains collaboration Jun 04 21:39:00 correct me if i'm wrong, but i thought you were a supporter of this Jun 04 21:39:12 Zorkman: the idea is: we try to bring people use our logs, because we believe it will bring bette rquality. but to bring right now coverage for positionning, we imported oci data. with time, the idea is to replace it with "pure" obm data Jun 04 21:39:25 i'm personally all in favour for openBmap because it loggs a lot more (and i'm looking forwar to when you are also using TA) Jun 04 21:39:47 Zorkman: ta code commited to my git Jun 04 21:39:52 onen|openBmap: i find it a very good strategy, better to have "not-so-precise" data then no data at all Jun 04 21:39:56 impressive Jun 04 21:40:20 now i have to go, quality-time with gf Jun 04 21:40:22 Zorkman: I talked about it with DocScrutinizer, and will keep working on it (even if we (obm) don't plan to work with this for the moment) Jun 04 21:40:29 keep up the good work! Jun 04 21:41:26 Zorkman: well sure I am willing to collaborate, but on code, not only on data. I think ch gives another meaning to collaboration... we'll see Jun 04 21:41:52 Zorkman: he does not say we don't want, he says, the only outcome of the discussion would be that obm could use the ch data Jun 04 21:42:25 Zorkman: which to me is close to no collaboration, as the license of data allows it Jun 04 21:42:31 Zorkman: good night, have to go too Jun 04 21:42:36 good night everyone Jun 04 21:43:52 I'll get some sleep too, see you! Jun 04 21:45:17 grr, now I get why my mails don't arrive Jun 04 21:45:38 * stefan_schmidt should switch his sender address from openmoko.org to datenfreihafen.org Jun 04 21:46:21 stefan_schmidt: :-D problem with your alter-egos? Jun 04 21:47:04 onen|openBmap: to many email addresses and different list subscribes Jun 04 21:49:55 * onen|openBmap applauses stefan_schmidt Jun 04 21:50:30 * mrmoku figures stefan_schmidt finally got his mail through... and onen|openBmap likes the content :P Jun 04 21:51:01 stefan_schmidt: I am glad you put the history here, because if I would have done the same, I would have feared to look like the child who complain the older boys don't want to play with Jun 04 21:51:37 * onen|openBmap is impressed by mrmoku human understanding Jun 04 21:52:19 onen|openBmap: data is expensive to gather => we should not throw away any data that has been gathered. in this light what you said in 00:39:12 sounds good Jun 04 21:52:26 onen|openBmap, btw.... I did my first GPRS connection with my FR... and I did that just for *you* :) Jun 04 21:53:06 * mrmoku forgot to install the bmap logger before leaving for a bike trip :P Jun 04 21:53:13 onen|openBmap: can openbmap run a script to start gps when it detects an unknown gsm cell? Jun 04 21:54:13 lindi-: It can only detect if the cell is unknown once we have the data offline available Jun 04 21:54:20 lindi-: Not there yet Jun 04 21:54:34 lindi-: But I like the idea :) Jun 04 21:54:34 stefan_schmidt: aha Jun 04 21:54:54 * onen|openBmap hugs mrmoku who is ready to do anything weird to get some love Jun 04 21:55:01 stefan_schmidt: you should be able to compress it pretty well if you just include cell ids and not their locations Jun 04 21:55:50 lindi-: well euh... no, not now. or do you mean, would it be possible? Jun 04 21:56:01 lindi-: Sure. It's more a problem to get all people involved to come up with the needed pieces for offline use. Jun 04 21:56:42 onen|openBmap: of course it's possible. With the db on the device you can lookup this fast and start gps Jun 04 21:57:32 lindi-: stefan_schmidt: actually we don't need the raw data for that. we only need the generated cell coverage. which is available (but I did not publicly talked about it so far). The prototype I showed to shoragan in Essen is using this Jun 04 21:58:07 onen|openBmap: ah, cool. Missed that. Need to catchup with shoragan then. Jun 04 21:58:25 onen|openBmap: note that the program needs to be able to update that data base when it finds those cells Jun 04 21:59:02 onen|openBmap: so if you hit new cells on your way from A to B it won't start gps again when you travel back from B to A and see the same cells again Jun 04 21:59:54 mwester: (since you seem to be on irc right now) any comments on the wlan comments I added to http://docs.openmoko.org/trac/ticket/2277 ? this wlan issue is one of the only serious kernel issues for me now Jun 04 22:00:04 stefan_schmidt: lindi-: sure thing. this is would of course be possible. Only if you see a cell unknown, for sure logging it is worth it. But, if you know the cell you are connected to, how do you know if where you have has been logged in the db? maybe the db does not know that the cell goes so far. Thus I wonder what would be the benefit from turning gps on when you see an unknown gsm cell, out of some specific Jun 04 22:00:04 cases. don't you think? Jun 04 22:00:09 lindi-: yup, local storage and sync with online db from time to time is also on the agenda. Not very high on the priority list. Jun 04 22:00:14 * onen|openBmap writes too long messages Jun 04 22:01:10 onen|openBmap: parse error :) Jun 04 22:02:42 stefan_schmidt: lindi-: my prototype uses a local db, but the update system is not implemented. It was more a proof of concept, to start discussion with shoragan. Jun 04 22:03:06 onen|openBmap: good. update can come later. Jun 04 22:03:20 onen|openBmap: ok. a local database is also needed for AGPS so it's highly useful Jun 04 22:04:10 *yawn* time to sleep for me Jun 04 22:04:14 night guys Jun 04 22:05:23 hey guys Jun 04 22:05:30 lindi-, I don't know how it's supposed to work, and it seems from the bug report that few others do either. Jun 04 22:06:22 mwester: you mean how wlan internals in kernel are supposed to work? Jun 04 22:08:11 The bug report goes on and on about wpa_supplicant, and iwlist, and iwconfig, etc etc etc. What is expected behavior is what is missing from that report. I think we need a new, proper, bug opened -- one with a single, simple "expected" vs "observed" sequence that we can do a git bisect to pinpoint. Jun 04 22:09:46 mwester: yes the report is messy Jun 04 22:09:59 That's an understatement. Jun 04 22:10:09 mwester: my contribution is that "kernel crash is not expected behavior" Jun 04 22:10:22 mwester: see the panic message Jun 04 22:10:30 Ok. But that doesn't help me. I don't know where to start to reproduce this. Jun 04 22:10:44 mwester: same problem here Jun 04 22:11:37 The panic seems to be a locking issue, which usually indicates something went very very wrong indeed, often in the timing or sequence of events. Hence, without a repeatable sequence of events, it's hunting in the dark for something that may not even be there. Jun 04 22:12:08 mwester: yep Jun 04 22:12:23 i'll try to figure out a way to reproduce this reliably (but i'm afraid there isn't one)= Jun 04 22:12:43 I was aware of that issue, and I was rather hoping that someone would report problems with a distro's network manager solution -- something that could be reproduced. Jun 04 22:13:13 I haven't had much (or any) play time lately... too busy I'm afraid :( Jun 04 22:13:51 lindi-: feel free to add your idea to the sourceforge site, where discussion could continue. so far, I don't see much benefit to your idea Jun 04 22:14:24 lindi-: even if I like the idea, we need to log data all the time anyway. So why only turn gps on uppon unknown cell Jun 04 22:15:02 lindi-: plus, I fear the time the gps gets a log, you are connected to another cell... Jun 04 22:17:44 onen|openBmap: is there an online viewer for this database? Jun 04 22:17:47 can somebody tell me how consistent the wifi bug (2277) is supposed to be? It works fine for me with 2.6.29 Jun 04 22:17:50 like openstreetmap.org Jun 04 22:27:27 khiraly1: yes: http://realtimeblog.free.fr/with_osm.php Jun 04 22:27:55 khiraly1: here with g earth http://realtimeblog.free.fr/maps/with_google_earth.php Jun 04 22:35:00 hmm Jun 04 22:35:07 cant really figure out how it works Jun 04 22:35:15 I have semi-transparent poligons Jun 04 22:35:29 which country the best to discover openbmap? Jun 04 22:35:37 france? Jun 04 22:37:16 khiraly1: I was seeing the polygons appear only some of the time. zooming in and out made them show up usually Jun 04 22:37:55 yeah, just dont know what Im looking for exactly Jun 04 22:38:04 what is the symbols of towers? Jun 04 22:38:06 dots? Jun 04 22:38:08 color? Jun 04 22:44:15 khiraly1: sorry for late answer Jun 04 22:44:49 khiraly1: you talk about g earth or the osm based one? Jun 04 22:44:56 osm Jun 04 22:45:15 is there a difference? Jun 04 22:45:19 khiraly1: you must first select a country, then a network provider Jun 04 22:45:43 208, 01 Jun 04 22:45:45 khiraly1: yes, I think g earth is much easier way and nice Jun 04 22:45:48 paris, orange Jun 04 22:45:53 I have seen on a screenshot Jun 04 22:47:24 khiraly1: ok, this would need some love to be improved. gsm cells belong to a lac (a lac has many cells), a network has many lacs Jun 04 22:47:53 hi everyone Jun 04 22:48:03 khiraly1: but the OSM interface lets you see lac and/or cells you select. so basically you have to know which lac/cid you want to see Jun 04 22:48:35 khiraly1: so if you want to see what are the cells around a place it sucks Jun 04 22:49:08 khiraly1: try g earth. you select a country, an operator, then download the google earth network link Jun 04 22:49:29 khiraly1: it will always get updated through the network while watching it in g earth Jun 04 22:49:42 google earth does not seem like working Jun 04 22:49:45 there is no map Jun 04 22:49:47 there you can browse the country, and see the dots of cells pops up Jun 04 22:49:49 nothing, just numbers Jun 04 22:50:22 ahh, I need the google earth desktop application Jun 04 22:50:25 oh, dear Jun 04 22:50:33 khiraly1: yes I know :-( Jun 04 22:51:07 just forget about google earth and concentrate to osm Jun 04 22:51:12 khiraly1: I have to go really soon Jun 04 22:51:15 would be nice to have the map in tangogps Jun 04 22:51:18 and seems doable Jun 04 22:52:02 khiraly1: yes, and would allow people to go in place where we do not have data for (this idea comes from cell hunter, he already started to work on this) Jun 04 22:52:53 please have some really strong indications about the symbols. Hard to notice anything on the map Jun 04 22:53:02 strong red polygon, etc Jun 04 22:53:41 khiraly1: I think the right way is browse a map, and see all the cells if you have selected a country+operator Jun 04 22:53:56 khiraly1: but we have plenty to do before this Jun 04 22:54:11 ok Jun 04 22:54:20 khiraly1: that is the reason I advise people to use g earth atm Jun 04 22:54:24 and what country+operator is the most complete? Jun 04 22:54:42 to see something Jun 04 22:54:43 ;) Jun 04 22:54:46 khiraly1: oh, tough one. Jun 04 22:55:06 hungary, does not have any... Jun 04 22:55:18 dont even know all the three operator here Jun 04 22:55:34 khiraly1: start from Paris, (in g earth you sometimes need to be at a specific zoom level for it to display all the cells) Jun 04 22:55:52 dont have google earth Jun 04 22:56:00 needs a gfx card for it Jun 04 22:56:02 ;) Jun 04 22:56:12 khiraly1: :-( Jun 04 22:56:42 something nvidia lacks. (im talking about the open source one. The closed is pita to install with every new kernel) Jun 04 22:57:14 so I stuck with nv, which is fine for desktop;) Jun 04 22:58:29 khiraly1: select 208, 1, 16384 Jun 04 22:58:40 khiraly1: on OSM Jun 04 22:59:04 then look south of paris near Massy Jun 04 22:59:25 khiraly1: this is on lac Jun 04 22:59:35 khiraly1: then select a cell to see its coverage Jun 04 23:01:09 i see Jun 04 23:01:57 khiraly1: some cells are very linear (probably points gathered along a straight road) Jun 04 23:01:57 hard to use. need different colors (to distinct lac and cell), needs to write the cellid into the cell polygon just like the street names are on the map Jun 04 23:02:07 khiraly1: some other will have real shape Jun 04 23:02:39 khiraly1: completely agree Jun 04 23:03:33 khiraly1: I try to find a nice one ... :-( Jun 04 23:03:38 and it works inversement. So you select the cell to see where it is. Normally it is the other way around: you browse the map to discover which cells are near by me Jun 04 23:03:55 me->you Jun 04 23:05:44 khiraly1: 4526 is nice Jun 04 23:06:09 khiraly1: exactly. this is what I meant earlier Jun 04 23:07:06 khiraly1: what do you think, isn't it nice? ;-) Jun 04 23:09:17 yeah looks nice Jun 04 23:09:30 but hard to believe the coverage are so straight Jun 04 23:09:31 ;) Jun 04 23:10:36 khiraly1: :-) Jun 04 23:10:47 khiraly1: ok have to *really* go Jun 04 23:11:09 khiraly1: feel free to get in touch if you have questions/suggestions! Jun 04 23:11:44 goog night (again but this time for real) everyone! Jun 04 23:12:00 good night onen|openBmap Jun 04 23:14:06 khiraly1: and of course map your neighbourhood, upload, and a few hours later you will browse your area ;-) **** ENDING LOGGING AT Fri Jun 05 02:59:57 2009