**** BEGIN LOGGING AT Fri Nov 13 02:59:59 2015
Nov 13 03:37:33 <pabs3> PaulFertser: any luck?
Nov 13 03:39:48 <pabs3> https://lwn.net/Articles/664179/ Firefox OS 2.5
Nov 13 06:12:08 <PaulFertser> pabs3: I had luck compiling it but in the process of apt-getting the deps I've lost Xorg, then ran out of space. Will repair and continue.
Nov 13 06:12:29 <pabs3> ouch!
Nov 13 06:12:47 <pabs3> cross-compiling might be a better option
Nov 13 06:13:02 <pabs3> https://wiki.debian.org/CrossCompiling
Nov 13 06:15:03 <DocScrutinizer05> pabs3: http://paste.opensuse.org/68867461
Nov 13 06:16:54 <DocScrutinizer05> IroN900:~# uname -a
Nov 13 06:16:56 <DocScrutinizer05> Linux IroN900 2.6.28-omap1 #1 PREEMPT Fri Aug 6 11:50:00 EEST 2010 armv7l GNU/Linux
Nov 13 06:18:36 <DocScrutinizer05> actually I think /dev/input/accel is broken by design. Since it samples at a constant rate afaik, which is a nogo for battery-powered embedded
Nov 13 06:20:29 <DocScrutinizer05> it at very least should be a relative input device (only delivering data when changes happened), NOT an absolute device which afaik it is
Nov 13 06:21:32 <DocScrutinizer05> and then you need a way to define the noise level which should _not_ be gonsidered a change and thus should not deliver a new data record
Nov 13 06:21:55 <DocScrutinizer05> considered*
Nov 13 06:32:27 <PaulFertser> After freeing up space it even started to work faster, heh. Back in business^W being spied on, as with any cellphone user.
Nov 13 06:38:07 <DocScrutinizer05> mokomaze how it should work: wait for new changed data from accel or timer expiry. Check and read and store new accel data. Calculate new ball position based on old accel data and old ball velocity and delta-t since last run. Check if new pos is >=1pixel different from old pos. If no, calculate timer for the time when ball moved one pixel and go asleep again. Else: Display ball at new pos. Calculate new ball velocity. calculate 
Nov 13 06:38:08 <DocScrutinizer05> whatever is larger: time til ball moved 1 pixel or 0.05s (max frame rate), use this time value for timer and go to sleep again
Nov 13 06:39:54 <PaulFertser> pabs3: doesn't work without modifications, I'll keep investigating.
Nov 13 06:45:37 <DocScrutinizer05> hi PaulFertser
Nov 13 06:46:42 <PaulFertser> DocScrutinizer05: hey Joerg!
Nov 13 06:50:06 <PaulFertser> pabs3: it sort of worked after I typed /dev/input/event4 in the config file but with one axis inverted. 
Nov 13 06:50:46 <PaulFertser> pabs3: also, I can't enter the menu, and I do not hear the sounds (I'm not running PA).
Nov 13 06:57:34 <DocScrutinizer05> well, I hope nobody does on FR ;-)
Nov 13 06:58:06 <PaulFertser> pabs3: so with "invert_y":true , "fname":"/dev/input/event4" it's playable on gta02, and vibration on bumping works.
Nov 13 06:58:55 <PaulFertser> pabs3: but the readme is misleading, it has -i freerunner but the app wants -i accelerometer
Nov 13 06:59:04 <DocScrutinizer05> hmm, the vibration been an issue a few decades ago, since it needs access to some node in /sys and that's root-only
Nov 13 06:59:43 <PaulFertser> I'm running as root, heeh
Nov 13 07:00:42 <DocScrutinizer05> yeah, the "we can add user accounts later" policy, which I always thought is a red herring since - like on mokomaze - a bazillion of apps will hinder that
Nov 13 07:02:47 <DocScrutinizer05> correct low-effort approach: /dev/input/accel root:vibra. addgroup vibra /bin/mokomaze
Nov 13 07:03:03 <DocScrutinizer05> err sorry
Nov 13 07:03:36 <DocScrutinizer05> correct low-effort approach: /sys/foo/bar/led-vibrator root:vibra. addgroup vibra /bin/mokomaze
Nov 13 07:05:09 <DocScrutinizer05> PaulFertser: could you please check a `cat /dev/input/event4` and see if it stops when you don't move the device?
Nov 13 07:06:15 <DocScrutinizer05> it definitely shouldn't report 100 or 400 times per second the identical data set
Nov 13 07:12:16 <PaulFertser> DocScrutinizer05: no, it doesn't. It's the old 2.6.39 driver. I do not think I remember how to configure the report thresholds.
Nov 13 07:13:12 <DocScrutinizer05> well, when it's a relative device then all fine. Setting the thresholds is via /sys nodes
Nov 13 07:13:30 <DocScrutinizer05> by setting the filters and interrupt thresholds in LIS302
Nov 13 07:13:57 <DocScrutinizer05> at least that's what it *should* do
Nov 13 07:14:54 <DocScrutinizer05> I hope the kernel driver module doesn't poll resp run in timer mode and then compare to last value to see if it's a changed new value
Nov 13 07:15:48 <DocScrutinizer05> you can set up the lis302 to vreate a 100 or 400 (iirc) IRQ/s for continuous sampling
Nov 13 07:16:06 <DocScrutinizer05> that would be the absolute nogo I mentioned above
Nov 13 07:16:39 <DocScrutinizer05> easiest way to check: cat /proc/irq
Nov 13 07:17:04 <DocScrutinizer05> and see if there's a runaway on the IRQ for the I2C that lis302 is on
Nov 13 07:17:34 <DocScrutinizer05> cat /proc/interrupts ;# that is
Nov 13 07:19:49 <DocScrutinizer05> quite funny on N900:  ls -f /proc/irq/*/*
Nov 13 07:20:52 <DocScrutinizer05> sorry,  ls -lF /proc/irq/*/*
Nov 13 08:24:13 <DocScrutinizer05> (thresholds, driver) actually the correct approach would be to have the kernel driver calculate new thresholds around +/-N of most recent absolute XYZ data and send that to the accel chip's IRQ logic
Nov 13 08:29:23 <DocScrutinizer05> the lis302 has only 2 window discriminators, so  exactly one absolutelly linear acceleration would theoretically not be possible to detect. In real world such a situation never will happen. Nevertheless it's probably smart to set the 2 monitoring circuits to those two of X Y Z that have the lowest values, which would result in exactly up/down acceleration not getting detected if and only if up/down vector is exactly in line with 
Nov 13 08:29:24 <DocScrutinizer05> one of the 3 axes of accel meter
Nov 13 08:30:37 <PaulFertser> pabs3: I can't enter menu because my touchscreen doesn't work at all.
Nov 13 08:39:24 <PaulFertser> DocScrutinizer05: I agree that all makes sense. I'm afraid it's not implemented like that though.
Nov 13 08:40:10 <DocScrutinizer05> I'm sure it's not implemented like this
Nov 13 08:40:42 <DocScrutinizer05> I looked into all existing variants of the lis302 kernel driver for week - years ago
Nov 13 08:42:23 <DocScrutinizer05> the mainline driver is brainfart idiocy, the Openmoko driver is... well not bad (I admit I don't recall this one much), and the N900 Nokia driver is a nice approach but only 60% implemented
Nov 13 08:42:39 <DocScrutinizer05> none of then works like it should
Nov 13 08:42:48 <DocScrutinizer05> of them*
Nov 13 08:47:05 <DocScrutinizer05> alternatively to kernel driver calculating and using dynamic new threshold to send them to lis302, you could set lis302 filters to highpass and thus only detect *differences* which means movements. Then read out the absolute values, send them to /dev and reset the IRQ. Maybe even smarter, though it wouldn't detect very slow movements, no matter how large the absolute difference after minutes. I.E. the latter concept wouldn't 
Nov 13 08:47:06 <DocScrutinizer05> ever trigger when you tie the lis302 device to minute hand of a clock
Nov 13 08:48:48 <DocScrutinizer05> anyway the latter concept would work with N900 driver, if only it was complete and had not omitted resp hardcoded many of the filter settings
Nov 13 14:11:57 <PaulFertser> pabspabspabs: what other testing do you want from me?
Nov 13 15:56:41 <PaulFertser> pabspabspabs: so in current state it seems playable; challenging too
**** ENDING LOGGING AT Sat Nov 14 02:59:59 2015