**** BEGIN LOGGING AT Tue Jul 29 03:00:00 2014
Jul 29 09:23:15 <Aspi> there are lots of entries of phones world wide promoting "UNLOCKED". what is this "unlocked" really, can a vendor lock a device, especially a N900 that will be flashed?
Jul 29 09:25:02 <kerio> Aspi: rapuyama don't care, rapuyama don't give a fuck
Jul 29 09:25:21 <kerio> you can flash as hard as you want, the n900 will stay oplocked/simlocked
Jul 29 09:26:00 <Aspi> so it's done in some ROM?
Jul 29 09:29:57 <hurrian_> there are locked N900s?
Jul 29 09:31:08 <Aspi> that's what I don't know. I dunno if "unlocked" is Chinese marketing scam.
Jul 29 09:31:48 <hurrian_> the Hong Kong refurbished N900s are unlocked, but are probably reballed with cigarette lighters
Jul 29 09:33:19 <Aspi> so, I have the dilemma that if I buy second hand, previous owner might in turn have bought a HK :)
Jul 29 09:34:07 <hurrian_> do you already have a N900?
Jul 29 09:34:17 <Aspi> no
Jul 29 09:34:21 <hurrian_> reusing HK N900s isn't too bad if you just want spare parts
Jul 29 09:34:35 <hurrian_> welp, that's pretty risky then
Jul 29 09:34:38 <fizzie> There's an "Enter code to remove operator lock" option in the title-bar-menu of the "Settings" application, which kind of sounds like they sold operator-locked N900s somewhere. Unless it's there just in case.
Jul 29 09:35:34 <Aspi> ah, okay. I'm just gonna ask seller if I buy.
Jul 29 09:36:06 <Aspi> are y'all excited about the Neo900? or will you live with the N900 to your death? :)
Jul 29 09:37:11 <hurrian_> my N900 was swiped, and all the N900s on the local equivalent of eBay are dead/sold as-is.
Jul 29 09:37:43 <Aspi> ditto, so I look international
Jul 29 09:38:29 <hurrian_> unfortunately, I won't be happy with just an OMAP3730, having been totally spoiled by how powerful octa-core balls out Android phones are.
Jul 29 09:38:39 <Aspi> I might take a chance on a HK refurb if I can't get something else, as they are not extremely expensive, and I might get lucky and get a reasonably working item (?)
Jul 29 09:39:47 <hurrian_> I'll probably just run NeoFremantle on my N9, when it materializes.
Jul 29 09:40:51 <dos1> [02:24:25] <DocScrutinizer05> and http://openbittorrent.com/  reports "Error: invalid data from tracker"
Jul 29 09:41:07 <dos1> this url is for the browser, tracker url is on the page :)
Jul 29 10:08:54 <Aspi> kerio: after reading the logs about rapuyama O_o maybe I'll need a second thinkthrough about N900
Jul 29 10:16:38 <DocScrutinizer05> hurrian_: good luck! I doubt anybody will backport the N9-BB5 cmt stack to fremantle
Jul 29 10:18:15 <DocScrutinizer05> other than that, you're right that N9 has basically exactly same SoC and Storage/Memory chip like Neo900
Jul 29 10:18:45 <hurrian_> isn't the BB5 comm rather similar?
Jul 29 10:22:49 <DocScrutinizer05> I don't think so. N9 BB5 is responsible for handling aegis certs/tokens and actually this is what forbids downgrading of HARM "firmware"
Jul 29 10:24:07 <hurrian_> that's something interesting to test, unlzo'ing PR1.2 and running it on N9.
Jul 29 10:24:47 <hurrian_> as far as I've read in the kernel hooks for aegis, I haven't seen any calls to BB5, but it might be in userland
Jul 29 10:26:02 <hurrian_> besides, if BB5 doesn't get it's aegis fix, what's it gonna do, shut down the device? Nemo clearly works without it* (ofono as the RIL instead of Nokia's stuff, but hey, it works)
Jul 29 16:00:47 <bencoh> hm, looking at scim_panel_gtk code ... no wonder scim eats battery ...
Jul 29 16:00:52 <bencoh>     _check_exit_timeout = gtk_timeout_add (500, check_exit_timeout_cb, NULL);
Jul 29 16:01:24 <bencoh> couldnt get uglier
Jul 29 16:03:17 <bencoh> (checks every 500ms whether it should exit or not)
Jul 29 17:17:02 <infobot> DocScrutinizer: infobot joined!
Jul 29 17:47:15 <DocScrutinizer05> bencoh: every 500ms is almost OKish
Jul 29 17:50:36 <DocScrutinizer05> also aiui it passes a callback to some gtk_timeout_add () function, which - depending on the way this function works - could cancel the previous callback registered. When it does, then this is an absolutely correct way to implement a 500ms timeout
Jul 29 17:51:38 <DocScrutinizer05> however when it doesn't cancel the previous check_exit_timeout_cb registration then that's terribly broken indeed
Jul 29 17:53:25 <DocScrutinizer05> I guess the real problem happens somewhere else, prolly in some busy loop that polls for input
Jul 29 18:05:53 <bencoh> DocScrutinizer05: well according to powertop it does fix the issue
Jul 29 18:06:14 <DocScrutinizer05> what does fix which issue?
Jul 29 18:07:01 <bencoh> removing this timer let the cpu go to c4
Jul 29 18:07:08 <bencoh> lets*
Jul 29 18:07:17 <kerio> isn't it c0
Jul 29 18:07:24 <kerio> no wait, it goes the other way right
Jul 29 18:07:42 <bencoh> yeah the other way
Jul 29 18:08:58 <DocScrutinizer05> well, randomly removing timers for sure fixes some timer-caused issues eventually, but it prolly will introduce some severe other breakage
Jul 29 18:10:28 <bencoh> it doesnt break a functionality as such (and newer versions of scim have this line commented as well) .... but it wont die on sigterm anymore
Jul 29 18:11:05 <bencoh> sigs are processed in another thread which updates a global var (ugly)
Jul 29 18:11:28 <DocScrutinizer05> I cannot tell for sure what's the root problem from a single line of code (in this case), but I can *guess* that the code registers 100 timer callbacks per second and never cancels a single one of them. And when push comes to pull it will register a new timer callback event when the callback function of a previous timer event gets called
Jul 29 18:14:33 <bencoh> this line gets executed once and the _cb doesnt seem to register a timer .... but meh :)
Jul 29 18:14:56 <DocScrutinizer05> the line >>  _check_exit_timeout = gtk_timeout_add (500, check_exit_timeout_cb, NULL); << doesn't look like it could cancel a previously registered timer, since for that it would need the _check_exit_timeout handle to that previous instance as a parameter handed to the function
Jul 29 18:16:33 <bencoh> http://scim-for-maemo.googlecode.com/svn-history/r162/trunk/scim-1.4.7-maemo/extras/panel/scim_panel_gtk.cpp :)
Jul 29 18:19:03 <DocScrutinizer05> >> gtk_timeout_add has been deprecated since version 2.4 and should not be used in newly-written code. Use g_timeout_add() instead.<<
Jul 29 18:19:23 <bencoh> it's a 5yo code ;)
Jul 29 18:19:55 <bencoh> but yeah, looks like others patched it to use g_timeout_add() as well
Jul 29 18:20:15 <DocScrutinizer05> http://www.gtk.org/tutorial1.2/gtk_tut-17.html#ss17.1  mhm
Jul 29 18:20:39 <DocScrutinizer05> >>...can create a timeout function that will be called every "interval" milliseconds.<<
Jul 29 18:21:01 <bencoh> hmm actually they also removed this callback as well
Jul 29 18:21:06 <DocScrutinizer05> so it's a recurring timer
Jul 29 18:21:10 <bencoh> yeah it is
Jul 29 18:21:25 <DocScrutinizer05> that's pretty odd
Jul 29 18:21:26 <bencoh> (that's actually what I was implying, sorry)
Jul 29 18:22:07 <bencoh> it's an ugly recurring timer to check "should I die now ?"
Jul 29 18:22:11 <DocScrutinizer05> The return value is an integer "tag" which may be used to stop the timeout by calling:
Jul 29 18:22:12 <DocScrutinizer05>  void gtk_timeout_remove( gint tag );
Jul 29 18:22:30 <DocScrutinizer05> braindamaged code
Jul 29 18:22:33 <bencoh> yup
Jul 29 18:22:58 <DocScrutinizer05> HAHA >>You may also stop the timeout function by returning zero or FALSE from your callback function.<<
Jul 29 18:23:18 <bencoh> I might try to update scim to 1.4.14 (part of it has been rewritten and it should behave better)
Jul 29 18:23:32 <bencoh> but I cant even build 1.4.7 in sb
Jul 29 18:23:45 <bencoh> I half-baked the tool from binary lib
Jul 29 18:24:03 <bencoh> I wonder how it got built at first
Jul 29 18:24:50 <DocScrutinizer05> I'd not be surprised to find gtk do a busy loop for every instance of timer event registered via gtk_timeout_add()
Jul 29 18:34:45 <DocScrutinizer05> I honestly wonder why this code needs such nonsense instead of doing it right in signalhandler(int sig)
Jul 29 18:37:39 <bencoh> they eventually had it write
Jul 29 18:37:55 <bencoh> the author was probably on heavy drug .... or just sleep deprived ;)
Jul 29 18:38:27 <bencoh> s/write/right/ : https://bugzilla.redhat.com/show_bug.cgi?id=444150
Jul 29 18:39:25 <bencoh> funny thing is we got a borked version for maemo, and people started writing a kludgy menu applet "switcher" instead of patching/looking for a patch
Jul 29 18:39:35 <bencoh> (this bug ticket predates n900)
Jul 29 18:39:37 <DocScrutinizer05>  if (!_panel_agent->run ())
Jul 29 18:39:39 <DocScrutinizer05>         std::cerr << "Failed to run Panel.\n";
Jul 29 18:39:40 <DocScrutinizer05>     G_LOCK (_global_resource_lock);
Jul 29 18:39:42 <DocScrutinizer05>     _should_exit = true;
Jul 29 18:39:43 <DocScrutinizer05> WTF?
Jul 29 18:39:47 <bencoh> exactly
Jul 29 18:40:22 <bencoh> told you it was ugly
Jul 29 18:40:29 <DocScrutinizer05> this whole code has more cruft and commented-out lines of code than actually meaningful ones
Jul 29 18:41:49 <DocScrutinizer05> and this coude looks to me pretty similar to a chinese PCB
Jul 29 18:41:55 <DocScrutinizer05> code*
Jul 29 18:42:11 <bencoh> :))
Jul 29 18:42:30 <bencoh> considering scim is mostly used for cjk input .... it probably is
Jul 29 18:42:39 <bencoh> (or japanese code, maybe)
Jul 29 18:42:49 <DocScrutinizer05> apply random changes until it starts to work. then cut out components until it stops working. Revert last component removal. Produce
Jul 29 18:43:08 <bencoh> hm no, definitely chinese, from the names
Jul 29 18:47:04 <DocScrutinizer05> God, I hate such uninspired code
Jul 29 18:47:25 <DocScrutinizer05> reading it feels like drinking sour milk
Jul 29 18:48:18 <DocScrutinizer05> and thinking of that code maybe running on my machine gives me a feeling like in a restaurant where I know they cook with rotten milk
Jul 29 18:49:32 <DocScrutinizer05> ugh, meeting today
Jul 29 18:58:28 <bencoh> I'm pretty sure half (most ?) of desktop software looks or looked like that at some point
Jul 29 18:58:37 <bencoh> and maemo prolly isnt an exception
Jul 29 19:03:24 <DocScrutinizer05> I'm quite sude most of KDE looks similar, yes
Jul 29 19:03:29 <DocScrutinizer05> sure*
Jul 29 19:04:21 <DocScrutinizer05> most (core) maemo code I've seen isn't all that bad
Jul 29 19:04:45 <bencoh> look at hildon-desktop then :>
Jul 29 19:05:02 <DocScrutinizer05> some stuff (hildon for example) could use some more love for parameter checking etc
Jul 29 19:05:09 <bencoh> or just the fact that you cant have desktop widgets without waking cpu
Jul 29 19:05:24 <DocScrutinizer05> err wut?
Jul 29 19:05:33 <bencoh> (I mean, waking cpu more than is needed)
Jul 29 19:06:09 <bencoh> I spotted a few loops/condition inversion in hildon-home
Jul 29 19:06:27 <bencoh> (or hildon-desktop, I dont remember where this part of the code sits)
Jul 29 19:07:19 <bencoh> basically it loops through widgets and checks whether display is *inside* the loop for each widget
Jul 29 19:07:27 <bencoh> and I suspect there is more
Jul 29 19:08:36 <DocScrutinizer05> you mean hildon executing all widget code frequently to do display updates as long as desktop is visible? well, that's not exactly nice but sort of tolerable
Jul 29 19:09:49 <DocScrutinizer05> the fact that a single segfaulting or freezing widget makes whole desktop go south is more severe
Jul 29 19:09:49 <bencoh> depending on the widget it can get pretty heavy
Jul 29 19:10:18 <bencoh> true, that's quite bad as well, but this is more of a design thing
Jul 29 19:10:44 <DocScrutinizer05> display update for all widgets is as well
Jul 29 19:11:26 <bencoh> on a different level/of a different nature
Jul 29 19:11:28 <DocScrutinizer05> since the widgets are executed in hildon context, as simple function calls, there's no reasonable way for them to announce they don't need to update their display
Jul 29 19:12:15 <DocScrutinizer05> a widget simply returning as fast as possuble when nothing to do is the most lightweight way to handle this in this architecture
Jul 29 19:13:48 <DocScrutinizer05> and anyway since the homescreen and thus the widgets are visible, there's a certain system load anyway, and particularly a certain energy consumption by backlight and mere display data bus. So a 10 wakeups per second for CPU don't really hurt
Jul 29 19:13:50 <bencoh> anyway ... now to build http://tomoe.sourceforge.jp against scim in sb
Jul 29 19:14:12 <bencoh> DocScrutinizer05: actually I was talking of display status check
Jul 29 19:14:22 <bencoh> s/of/about/
Jul 29 19:14:24 <infobot> bencoh meant: DocScrutinizer05: actually I was talking about display status check
Jul 29 19:14:26 <DocScrutinizer05> display status check?
Jul 29 19:14:40 <bencoh> "is display on" "is desktop visible" "is device unlocked"
Jul 29 19:14:43 <bencoh> that kind of things
Jul 29 19:14:58 <DocScrutinizer05> that's supposed to get done in hildon 
Jul 29 19:15:21 <DocScrutinizer05> makes absolutely no sense to do it in every widget
Jul 29 19:15:41 <bencoh> that's done in hildon but in reverse order/in a peculiar way
Jul 29 19:15:47 <bencoh> lemme find the source
Jul 29 19:16:11 <DocScrutinizer05> when display of homescreen isn't visible, not a single widget is visible, so why should hildon run any wiget code in that sitation?
Jul 29 19:17:16 <DocScrutinizer05> as soon as display status changes from invisible to visible, all widgets need to update their display content, and then every 50ms or whatever
Jul 29 19:18:05 <DocScrutinizer05> as soon as status changes from visible to not visible (aka background, or locked), hildon should stop executing +any* widget code
Jul 29 19:18:36 <bencoh> hd_comp_mgr_update_applets_on_current_desktop_property
Jul 29 19:19:17 <DocScrutinizer05> every widget in turn is supposed to check early if there's actually sth to update and return when e.g. last (seconds) digit of the clock didn't change
Jul 29 19:19:21 <bencoh> it goes through widgets twice and make Xlib calls whether display is on or not
Jul 29 19:20:00 <bencoh> which roughly means going through X11 crazy codepath
Jul 29 19:20:17 <DocScrutinizer05> I never checked that hildon code. I'm talking from mere best practice which I'd expect to see in hildon
Jul 29 19:21:26 <bencoh> well ... I'd definitely love to see more best practice everywhere :)
Jul 29 19:21:29 <DocScrutinizer05> and I'm pretty sure hildon does NOT do what you say it does, when screen is locked. Otherwise my battery wouldn't stay a 5h even
Jul 29 19:22:30 <bencoh> I didnt say it would really update widgets when locked, but it would do some X calls
Jul 29 19:22:56 <DocScrutinizer05> X calls are as worse as display updates
Jul 29 19:23:14 <jaska> i guess i need to look up the dual bl-5j hack, my mugen is getting shorter
Jul 29 19:26:03 <bencoh> DocScrutinizer05: well some widgets (hello qwb !) can do much worse ... but yeah, X calls arent free, that's my point ;)
Jul 29 19:29:42 <DocScrutinizer05> my point is that I honestly doubt they happen while screen locked
Jul 29 19:30:15 <DocScrutinizer05> if they actually do, then that's prolly a bug
Jul 29 19:30:23 <bencoh> I think it does at least for XDeleteProperty
Jul 29 19:30:51 <bencoh> though I didnt rebuild hildon/mb to trace that
Jul 29 19:31:43 <bencoh> but then again, powertop has different output with and without widgets (be it one simple widget)
Jul 29 19:32:01 <DocScrutinizer05> that's bad
Jul 29 19:32:29 <DocScrutinizer05> at least when you talk about locked screen
Jul 29 19:32:36 <bencoh> yup
Jul 29 19:33:14 <DocScrutinizer05> actually with a locked screen hildon itself shouldn't run anymore
Jul 29 19:33:58 <DocScrutinizer05> unless some idiotic widget scheduled a timer
Jul 29 19:34:58 <DocScrutinizer05> you know, one of the kind that sends a signal to wake up the process on expiry
Jul 29 19:35:44 <DocScrutinizer05> "the process" is hildon here, and of course it needs to run *all* widgets so the idiotic one has a chance to service the timer expiry
Jul 29 19:36:18 <bencoh> I think I tested with DCE widget at that time
Jul 29 19:36:32 <bencoh> (which behaved better than qwb, but still)
Jul 29 19:36:34 <DocScrutinizer05> whatever that is
Jul 29 19:36:46 <bencoh> desktop cmd exec
Jul 29 19:36:55 <bencoh> and I checked the source as well
Jul 29 19:37:09 <DocScrutinizer05> umm well
Jul 29 19:38:08 <bencoh> I stopped using widgets at that point
Jul 29 19:38:09 <DocScrutinizer05> I dunno what QBW does, but it prolly shouldn't run any timers. it has nothing that needs a timed execution
Jul 29 19:38:23 <bencoh> qwb has timed functionality (as well as dce)
Jul 29 19:38:39 <bencoh> but qwb is heavier in everything
Jul 29 19:39:26 <DocScrutinizer05> ~qbw
Jul 29 19:39:51 <DocScrutinizer05> ~qwb
Jul 29 19:41:03 <DocScrutinizer05> it's probably an absolutely idiotic idea to implement something like a daemon that get executed 10 times per second in a widget
Jul 29 19:41:37 <DocScrutinizer05> I can't think of any such function that would need that
Jul 29 19:41:50 <bencoh> it is, but ... looks like some people found it neat
Jul 29 19:41:57 <bencoh> I dont understand either :)
Jul 29 19:53:34 <DocScrutinizer05> I mean, sure I could integrate the fan control of my PC into xeyes.... BUT...
Jul 29 19:54:37 <DocScrutinizer05> shouldn't a widget do *only* stuff that's actually visible on display? And particularly shouldn't it STOP doing this as soon as the display isn't visible?
Jul 29 19:56:35 <DocScrutinizer05> a maemo widget isn't just an arbitrary X-app with a funny shaped window
Jul 29 20:01:42 <kerio> DocScrutinizer05: X has a way to figure out whether or not you're drawn
Jul 29 20:03:38 <DocScrutinizer05> kerio: so what?
Jul 29 20:03:54 <DocScrutinizer05> you're aware that all widgets run as "hildon" ?
Jul 29 20:04:00 <kerio> so even if it was an arbitrary X program, it doesn't really have an excuse to waste cpu
Jul 29 20:04:23 <bencoh> :)
Jul 29 20:05:00 <DocScrutinizer05> kerio: that's completely off the point we discussed, which is timer ALARM
Jul 29 20:05:13 <kerio> "shouldn't a widget do *only* stuff that's actually visible on display? And particularly shouldn't it STOP doing this as soon as the display isn't visible?"
Jul 29 20:05:30 <kerio> i expect every fucking program to do that, not only widgets
Jul 29 20:05:40 <DocScrutinizer05> aha
Jul 29 20:05:57 <DocScrutinizer05> kerio: that's completely off the point we discussed, which been daemons
Jul 29 20:06:33 <DocScrutinizer05> and those for sure don't give an F that they are not visible usually
Jul 29 20:08:00 <DocScrutinizer05> lemme put it simple: you MUST NOT make an X program out of crond
Jul 29 21:16:44 <bencoh> is there a place to set envvars for programs started from X (I'd use .xinitrc, but I'm not sure it's honoured on maemo) ?
Jul 29 23:47:52 <DocScrutinizer05> hmmmm, some apps get started by the original binary acme (which in fact is a symlink to maemo-invoker(?) ) sending a dbus cmd to maemo-launcher(?) which then invokes the real binary acme.launch
Jul 29 23:48:25 <DocScrutinizer05> or some similar names and scenario. Hard to believe in any env vars getting set for the final binary in this
Jul 29 23:48:53 <DocScrutinizer05> I guess global envs can get set though, somewhere in the initscripts
Jul 29 23:58:57 <bencoh> nothing per-user then
**** ENDING LOGGING AT Wed Jul 30 03:00:01 2014