**** BEGIN LOGGING AT Mon Jul 17 03:00:04 2017 Jul 17 03:29:53 Anyone tried "shake to wake" (lockd.py)? I guess it would exhaust resources/battery? Jul 17 09:52:27 yes and yes Jul 17 10:11:55 moin :) Jul 17 14:00:48 My last phone got broken and I'm using n900 again from now. But as far as I can see repos are not working any longer. Jul 17 14:01:00 I know that I have to replace repos with community ones Jul 17 14:02:03 but I'm prrety exhausted because I installed fremantle from repository.maemo.org/community as interned said me to do Jul 17 14:02:10 and it's still not working. Jul 17 14:02:36 could anyone link me a working repos catalogue? Jul 17 14:12:28 ~maemo-repos Jul 17 14:12:29 rumour has it, maemo-repos is http://wiki.maemo.org/Repository#List_of_Maemo_repositories Jul 17 14:21:29 ss942: ^^ Jul 17 14:23:06 sicelo: thanks Jul 17 15:28:51 shake to wake - drains battery only when implemented without a clue Jul 17 15:29:25 this is exactly the point how embedded differs massively from coding for a standard desktop PC Jul 17 15:30:28 it's a pity not even the maemo lis302 kernel driver is really a comprehensive decent implementation Jul 17 15:31:33 for "shake to wake" you'd basically need to use your own kernel driver or go for I2C plus your own IRQ handler Jul 17 15:35:16 correct way to implement: set up the filters and thresholds in LIS302 so it triggers IRQ on shake (use high pass filter to detect fast movements rest changes in orientation), set up an IRQ handler that reads out LIS302 (to filter out false positives) and wakes the device. For this you need to tell MCE to keep its fingers off the LIS302 Jul 17 15:36:06 what MCE does to LIS302 filters is total brainfart Jul 17 15:38:14 s/MCE/MCE and lis302dl.ko kernel driver/ Jul 17 15:38:15 DocScrutinizer05 meant: what MCE and lis302dl.ko kernel driver does to LIS302 filters is total brainfart Jul 17 15:39:23 ~tell sicelo about jrrepos Jul 17 15:49:05 ~jrrepos Jul 17 15:49:05 from memory, jrrepos is http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/ Jul 17 15:50:06 * DocScrutinizer05 seems to still have to learn "you NEVER must change a URL on your server" Jul 17 15:55:36 It's python so basically has a loop polling the accel while locked. I tested it but cannot justify the battery drain. Jul 17 15:56:40 loops and polling are both absolute nogo on embedded Jul 17 15:57:15 sixwheeledbeast^: it means core keeps exiting sleep / low power states Jul 17 15:57:22 you *always* have to use event driven design, here event=IRQ Jul 17 15:57:36 exactly Jul 17 15:58:01 actually _always_ event=IRQ Jul 17 15:58:12 even on touch events and keypress events Jul 17 15:58:42 that's embedded programming Jul 17 15:59:28 it SHOULD be generic concept for all platforms/environment. But on desktop often developers get away with crappy polling Jul 17 16:01:41 a busy loop should throw an error in compiler already ;-P - A fat WARNING if the loop event is a timer (with less than 5 seconds interval) Jul 17 16:03:56 on kernel level in maemo, processes that don't stop on a IRQ for at least 99% of time during one minute should get terminated hard with BUSERR or somesuch Jul 17 16:05:20 OHM should take care Jul 17 16:08:31 you know those "the program is not responding within time, do you want to wait longer or terminate it?" requesters (KDE for example)? Similar requester on maemo Hildon should be "the process is using more than 50% of time slots available to it, during last 60s. Do you want to stop the process, or allow for another minute, or allow permanently for all processes with this name?" Jul 17 16:09:34 #s/permanently/for one week/ Jul 17 16:12:16 s/stop/stop, or kill/ Jul 17 16:14:47 prolly a selection offering 1, 5, 60 minutes, 6h, 24h, 1 month (, forever with root password) - should be sufficiently versatile Jul 17 16:17:34 plus "[_] apply to whole process group" and "[_] apply to all processes with name regex '_________' " with the regex already preset to the process name of the triggering process, but editable Jul 17 16:19:31 *might* need patches to scheduler Jul 17 16:21:38 well, you _could_ check CPU-time elabsed for all processes every minute and compare to last check, to detect those processes that together consumed more than 30s CPU time and blame the one of them with highest CPU time increase Jul 17 16:23:13 problem arises when one or more of those processes are already whitelisted for high CPU usage Jul 17 16:24:35 it's tricky to handle the situation where 4 processes hog the CPU 100% and one of them is whitelisted Jul 17 16:25:51 the other three might actually be humble and only use all their available CPU time because there isn't much CPU time left for them due to the whiteliszed hog process Jul 17 16:30:22 btw it's one of the major tasks in maemo-testing evaluation to check for those CPU hogs and kick their ass Jul 17 16:30:44 ~pkg Jul 17 16:30:57 pkg is, like, http://maemo.org/packages/ Jul 17 16:32:29 no freking f*ing clue how http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/shaketowake2/2.2.3-2/ made it into extras Jul 17 16:33:03 would be council's duty to remove it from maemo-extras Jul 17 16:34:05 http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/shaketowake2/2.2.3-2/ even ivgalvez OMG Jul 17 16:34:39 >>There have been no comments so far.<< tells a story Jul 17 16:35:01 people think testing evaluation is a sympathy contest Jul 17 16:36:21 @council: please consider removing http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/shaketowake2/2.2.3-2/ since evaluation in testing (see above) failed to detect a major flaw - CPU hogging - in this app Jul 17 16:37:14 didnt he say he reduced cpu usage? Jul 17 16:38:26 from 100% to 50% ? ;-P Jul 17 16:38:40 better than original, so that's improvement? Jul 17 16:38:54 anyway, 2011, seems to be long time ago Jul 17 16:39:08 that's no argument Jul 17 16:39:09 wonder if maintainer is still alive in maemo Jul 17 16:39:48 all packages in maemo-extras are supposed to be safe to use, not cause any issues like massive battery drain Jul 17 16:39:59 unless obvious, like in games etc Jul 17 16:40:24 or audio player :P Jul 17 16:40:56 the average user has no means to find out why their phone only stays as short as 10h with one battery charge, after they installed a dozen packages Jul 17 16:41:29 audio player must at least provide a maybe 10h Jul 17 16:41:45 yeah, and no resource drain when paused/idle Jul 17 16:41:50 yep Jul 17 16:42:19 this is the basic rule for ALL apps Jul 17 16:42:32 which means keeping evilaudio in the kennel when not playing anything, as i've found out few years ago Jul 17 16:42:37 shake2waje violates it Jul 17 16:43:04 maybe there should be a page with violators Jul 17 16:43:13 and versions tested Jul 17 16:43:30 easier than contacting authors purging packages (that might be useful otherwise) Jul 17 16:43:30 this page is "testing", basically Jul 17 16:45:17 * DocScrutinizer05 ponders a generic patch to preinstall script that opens up a requester with bold fat "WARNING! this app is not recommended to use, since it has the following issues: ....*)...." Jul 17 16:45:32 easy to add to existing packages Jul 17 16:46:18 though I actually would prefer that stuff getting purged from maemo-extras. Back to maemo-extras-testing Jul 17 16:49:51 i would vote for warning with a list of pkg-ver Jul 17 16:50:13 as long user knows what drains the battery he/she might choose it consciously Jul 17 16:50:22 or even fix Jul 17 16:50:26 huh? the warning requester is bound to the particular version's pre-install script Jul 17 16:51:05 when user want to "choose conciously" they are free to use the package from maemo-extras-devel or -testing Jul 17 16:51:38 such package has no place in maemo-extras (plain) Jul 17 16:52:07 I'm not going to fix a package that is broken by design Jul 17 16:53:09 particularly this package that's basically impossible to fix without massive fixes/improvements to the kernel driver for lis302 Jul 17 16:57:13 juiceme: ^^^^ Jul 17 16:57:18 sicelo: ^^^^ Jul 17 16:57:54 @council: please consider removing http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/shaketowake2/2.2.3-2/ since evaluation in testing (see above) failed to detect a major flaw - CPU hogging - in this app Jul 17 16:58:59 should go back to maemo-extras-testing, with comment "promoted based on flawed evaluation, please fix CPU hogging" Jul 17 17:02:33 * DocScrutinizer05 is temped to take adminustrative measures already, on the packages web Jul 17 17:07:23 *COUGH* Jul 17 17:07:25 def get_rotation(self, widget=None): Jul 17 17:07:27 f=os.popen('cat /sys/class/i2c-adapter/i2c-3/3-001d/coord').read() Jul 17 17:09:58 now WHAT THE FUCK?!? http://paste.ubuntu.com/25113245 Jul 17 17:11:48 this is so terribly wrong, I have no wards for it. Best part: it actually doubles what mce already does, just waaaay inferior Jul 17 17:13:17 coor = self.get_rotation() Jul 17 17:13:18 y = coor[1] Jul 17 17:13:20 if y<-1300 or y>1300 : Jul 17 17:13:21 state = self.get_proximity() ....... Jul 17 17:14:53 THIS is something you get from MCE already, and MCE at least does The Right Thing[TM] which is: set uf filters in lis302 exactly like that (y<-1300 or y>1300) and waiting for IRQ from the filters Jul 17 17:15:13 set up* Jul 17 17:17:24 well, almost exactly like that Jul 17 17:19:07 this isn't very smart in MCE, but it's totally braindead in the way shake2wake does it by *polling* the accel and then only checking for Y axis Jul 17 17:20:13 hint: iirc 1000 is 1g aka "device has no other acceleration than gravity" Jul 17 17:21:51 MCE uses static threshold of iirc 900 somesuch on Y - without any highpass filters - to detect if device is facing up (>900) or down (<900) Jul 17 17:21:55 iirc Jul 17 17:22:08 actually the kernel driver does that Jul 17 17:23:22 should have used highpass filters and same threshold (like 100/s) on two axes to trigger the IRQ Jul 17 17:23:33 s/same/sane/ Jul 17 17:23:33 DocScrutinizer05 meant: should have used highpass filters and sane threshold (like 100/s) on two axes to trigger the IRQ Jul 17 17:26:08 plus MCE and kernel driver should have API to modify the filters. MCE must keep a list of requests for filter settings from userland and choose the most sensitive one. Much like liblocation Jul 17 17:29:07 see http://wiki.maemo.org/PyMaemo/Using_Location_API Jul 17 17:37:03 >>Location resources are shared between applications, and applications can request different location methods. Fixes for all requested methods are sent for all applications listening to GPSDevice's "changed" signal, therefore application should judge whether fix it is receiving, is one that it needs. See GPSDeviceFix section for discussion.<< and >>An application receiving a fix cannot know if the fix is a result from location method Jul 17 17:37:04 it requested. Therefore application should study whether fix is accurate enough to satisfy application's needs.<< s/fix/acceleration event/ s/location method/lis302 filter/ Jul 17 17:57:23 the kernel driver must expose the filter settings, the middleware (MCE) must have an API with abstract filer settings for the userland to register for an event based on those filters. The middleware will keep a list of those registrations and adjust the filers in kernel driver to the most sensible ones. with no active registrations the middleware will disable the accel sensor Jul 17 18:01:40 if a userland process requests filer settings that collide with the ones in effect, the response from middleware will notify to the userland process which filter setting are in effect and which failed on the request. For example LIS302 has only two engines to monitor sensors and trigger IRQ, so only 2 of the XYZ axes can get monitored. If filers monitor X,Y then a request for X,Z will return with "Z ignored, resouce occupied" Jul 17 18:06:58 logical consequence: the API in middleware allows to request the theoretical maximum for filters/triggers, I.E "Xmin,max,hp_parameters Ymin,max,hp_parameters Zmin,max,hp_parameters Xclick Xdoubleclick Yclick Ydoubleclick Zclick Zdoubleclick " Jul 17 18:08:23 obviously some sort of plaintext interface is best suited for that, to have the most generic interface design suitable for other sensors as well Jul 17 18:14:55 "X:<-1300,>1300,abs;Y:>30,hpwindow=2s;Z:>-5,<5,abs" Jul 17 18:17:00 X triggers when value outside the interval -1300..+1300; Y triggers when value change is >30 in 2 seconds; Z triggers when value inside interval -5..+5 Jul 17 18:20:46 parameters in request are satisfied from left to right. so for the lis302 the response from middleware could be "X*:>50,hpwindow=10s;Y:>30,hpwindow=2s;Z:EAVAIL" Jul 17 18:23:57 this is due to existing filter for X from another app, which overrides the mere left to right. a request "X:<-1300,>1300,abs" might get response "X*:>50,hpwindow=10s;X:<-1300,>1300,abs" however, when the resource "2nd engine" wasn't occupied previously Jul 17 18:24:31 There is no requirement for packages to be tested for CPU usage. As a package tester you QA to the guidelines set. Jul 17 18:25:02 I thought the guidlines explicitly mention excessive resource usage Jul 17 18:25:34 Not that I recall, also define excessive. Jul 17 18:25:45 I even thought this was first prio for test evaluation Jul 17 18:27:34 https://wiki.maemo.org/Extras-testing/QA_checklist just to refer to what we're talking about. Now reading... Jul 17 18:28:23 8. [ ] No power management issues. Jul 17 18:28:36 7. [ ] No performance problems. Jul 17 18:30:42 Power management issues Jul 17 18:30:44 Battery life is diminished beyond acceptable standards by having the application running in the background Jul 17 18:31:03 But still it's in the package testers opinion. It's not a set amount like say 0.3MB of root space. Jul 17 18:31:24 this is pretty much common sense Jul 17 18:31:25 but did anyone measured battery drain of it? Jul 17 18:31:59 As long as the package does not cause the battery to drain within a day, it could be seen as a pass but not ideal. Jul 17 18:32:16 also you got >>The use case of a full day without charging should not be compromised.<< Jul 17 18:32:44 but that system('cat') instead of read is fubar Jul 17 18:34:00 I noticed a drop in battery life when I tested it but never did my full package test procedure on it to rate the package. This was several years ago. Jul 17 18:34:21 * sixwheeledbeast^ has to run bbl Jul 17 18:34:51 shake2wake polls accel with a 1s period aiui and it does a lot of nonsense with a 0.05s period during each cycle http://paste.ubuntu.com/25113635 Jul 17 18:36:19 honestly for such code you should get banned from civilized world, to an island what only has a ZX81 and an old b&w TV, and an ergometer dynamo to power it Jul 17 18:36:29 for at least one year Jul 17 18:36:56 nah, zx81 has basic, not a good educational example Jul 17 18:37:05 indeed Jul 17 18:38:59 anyway for 'cat /sys/class/i2c-adapter/i2c-3/3-001d/coord' alone, it should get rated down due to risks in that Jul 17 18:40:52 if not for risks then for ugliness despite gaving better alternative Jul 17 18:41:02 having Jul 17 18:49:30 what the.... Jul 17 18:49:33 # Regular cron jobs for the stow2-2.2.2 package Jul 17 18:49:34 # Jul 17 18:49:36 0 4 * * * root stow2-2.2.2_maintenance Jul 17 18:49:53 ARRRGH Jul 17 19:05:38 I should eventually create that sanity checker I planned for so long. One of the checks would look at CPU time total of all processes and check the topmost 2 or 3 that are not whitelisted, then notify user about them Jul 17 19:06:03 http://wstaw.org/m/2017/07/17/plasma-desktopyX8317.png Jul 17 19:07:52 the problem with shake2wake: it's an applet so won't even show up in there >:-( Jul 17 19:09:46 * DocScrutinizer05 idly wonders if sleep() is allowed at all in applets Jul 17 19:11:29 that's prolly the reason for that >> while gtk.events_pending(): gtk.main_iteration(False) time.sleep(0.05)<< madness Jul 17 19:15:14 so hildon desktop gets a chance to axt on a (me counts)... 10 events during 0.5s Jul 17 19:15:21 act* Jul 17 23:48:54 somehow I missed this https://lkml.org/lkml/2016/12/19/313 Jul 17 23:49:04 sweet. should try that. Jul 18 00:26:07 Wizzup: well, that's H-E-N Jul 18 00:40:16 help me out! is >> if (test == MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS) << actually equivalent to >> if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS)) << ?? Jul 18 00:43:34 lets assume MUSB_TEST_FORCE_HOST = 0x01 and MUSB_TEST_FORCE_FS=0x02 then >>test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS)<< was sth like 0xf7 & 0x03; while the if (test == MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS) is If (0xf7 == 0x03) Jul 18 00:44:23 if my c fu doesn't evade me, the first evaluates TRUE while the second evaluates FALSE Jul 18 00:48:24 I also wonder hwy not rather using a case here Jul 18 00:49:16 https://lkml.org/lkml/2016/12/15/777 https://lkml.org/lkml/2016/12/19/300 Jul 18 00:52:18 honestly, the whole code in https://lkml.org/lkml/2016/12/19/300 looks incorrect Jul 18 01:04:22 iirc and aiui the if bit0 then print "bit0 "; if bit1 then print "bit1 "; ... is what been meant to happen there. What's now happening is if register==0x01 then print "bit0\n" ELSE if register==0x02 then print "bit1\n". This is a completely different logic and won't work Jul 18 01:07:12 also what's this comment >>since multiple tests at the same time are not allowed.<< re >>if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))<< this is _not_ "multiple tests" Jul 18 01:08:47 honestly why didn't pali ask me to sign it off resp review it Jul 18 01:16:14 the funny detail in this: I think it was me who wrote that particular code segment originally Jul 18 01:20:54 `test == a | b` is always non-zero if `b` is non-zero Jul 18 01:22:31 ah, that's not what's in the patch. **** BEGIN LOGGING AT Tue Jul 18 02:14:51 2017 Jul 18 02:45:47 psst Oksana Jul 18 02:46:53 how it's going people **** ENDING LOGGING AT Tue Jul 18 03:00:03 2017