**** BEGIN LOGGING AT Thu Dec 12 02:59:59 2013 Dec 12 09:12:57 qtmoko v58 is out now http://lists.openmoko.org/pipermail/community/2013-December/069117.html Dec 12 09:53:38 \o/ Dec 12 09:54:45 great job! I've seen you load module joydev. No surprise *this* doesn't play nice with lis302, it's actually for joysticks as the name suggests Dec 12 09:57:19 accelerometer is more than a joystick HID. It can detect freefall, doubletap and whatnot else. The joystick funtion is only one of many features, and a rather non-embedded one too. It delivers a continuous stream of orientation data, for low latency games and the like Dec 12 09:59:10 DocScrutinizer05: hi, IIRC they joydev is because of the accelerometer QtMaze game Dec 12 10:00:04 DocScrutinizer05: if i recall well they joydev was giving better data? maybe the joydev triggered faster sampling speed? Dec 12 10:00:11 for proper handling of lis302 you need a middleware that manages the resource and allows multiple apps to register for a certain accuracy and frequency of status reports resp events. Like one app asking the middleware to report when freefall, while another app asking for orientation-change reports with a precicion of 5° Dec 12 10:01:01 DocScrutinizer05: yup i downloaded the lis302dl datasheet - it has quite nice features - it would be nice to have wake on screen double tap Dec 12 10:01:08 yes, most likely joydev uses maximum freq and unconditional reporting from lis302 Dec 12 10:02:17 hmm i wonder if am brave enough to switch from N900 to Freerunner after years :) Dec 12 10:03:02 i guess i will run the automatic suspend/call/resume/hangup test first.. Dec 12 10:04:33 omg Dec 12 10:05:40 the middleware in turn needs to do: *: read out lis302 X,Y,Z *: set the local buffers aka sysfs node content to those values *: send message to all processes that registered for this condition of orientation data *: aggreagte all requests from processes and find smallest common denominator, calculate what would be the needed filter and trigger configs for satisfying those *: set up lis302 IRQ to e.g. report when Dec 12 10:05:41 orientation changed by minimum 5° *: "go to sleep" Dec 12 10:06:48 *: "go to sleep" and wait for next IRQ from either lis302 or timer Dec 12 10:06:50 DocScrutinizer05: hmm i wonder if Qt aready can handle this... Dec 12 10:07:09 hardly, Qt sensors is brainfscked Dec 12 10:07:48 could be - i really havent checked, i am using Qt only for GUI... Dec 12 10:08:06 frankly, i think qt implements smallest common denominator between all possible platforms Dec 12 10:08:29 and that's joydev I guess Dec 12 10:09:06 oooh, you even can adjust the sampling rate when you're lucky, in QtM accelerometer Dec 12 10:09:50 aiui Qt has no idea of a thing like middleware, since that wouldn't be sth linked into the app Dec 12 10:11:19 recently it seems for HARMATTAN and nemo7mer they did something to employ sersorfw, but that is flawed by design as well, since it triggers in software, not by IRQ from peripherals Dec 12 10:11:39 maybe that changed since I last checked Dec 12 10:12:05 which is like 12 or 18 months ago Dec 12 10:13:10 the only *proper* handler I might think of *might* be in FSO Dec 12 10:13:38 and a semi-working one is in maemo MCE Dec 12 10:17:45 the problem with joydev is: it basically emulates or acts like a absolute (or maybe even relative) HID aka mouse/trackpad/etc Dec 12 10:18:12 this is basically rape of the nice chip and the capabilities it has Dec 12 10:18:49 yup, for games it's probably ok, but for something power friendly it needs better abstraction... Dec 12 10:18:57 yes Dec 12 10:19:19 my dream is to have ONE open phone that is easy to produce and which has 100% working HW Dec 12 10:19:32 then there would not be any abstraction needed Dec 12 10:19:40 just hardcode everything for that phone :) Dec 12 10:19:42 hmmm Dec 12 10:19:59 yeah, that's the microsoft way Dec 12 10:20:25 and even more so the apple way Dec 12 10:20:26 i'd be surprised if iPhone is not done that way too Dec 12 10:20:37 :-) Dec 12 10:20:40 :) Dec 12 10:23:12 but I'm pretty sure even cryPhone has a middleware/handler that has a proper API for the accel, and processes can register to e.g only get notified when a true orientation change from landscape to portrait (or vice versa) happened. NOT poll the accel all the time and then decide in sw of "the app" whether or not to rotate screen Dec 12 10:26:19 hmm i am not sure if there is API for this - if this isnt handled by OS automatically... Dec 12 10:26:42 but i have never checked any Apple api :) Dec 12 10:26:58 you'd need to define a nice API that allows apps to register for *) relative changes of orientation in excess of a certain minimum speed and minimum orientation change (degrees) *) absolute orientation reached (define a range that is "hot", like 80°..100°) *) register for joydev type coninuous reports on a given pace/freq *) special "gesture" detection like doubletap or freefall Dec 12 10:27:07 it can be that the app is just notified that it has rotated Dec 12 10:29:32 ooh, for absolute you also need a debounce time, like "report when orientation Y=$[80°..100°] for >$2seconds" Dec 12 10:33:52 the middleware/driver will *usually* set up the lis302 to report any change in orientation, and then the driver will decide if that real orientation change would qualify to report an event to any of the processes that registered Dec 12 10:35:01 the sensitivity of the change-detector in lis302 gets adjusted by the driver according to all the registrations Dec 12 10:36:27 when there are only orientation change (portrait/landscape) registrations, then the allowed range the device may rotate without lis302 firing an IRQ will be something like 45° Dec 12 10:39:34 an app can populate as many of the fields of one notification registration as it wants, I.E only set Xmin and Xmax and leave Y|Z-min|max and all the other values on a dont-care value Dec 12 10:40:40 for logical OR an app can have multiple registrations, like one for portrait and one for top-down portrait Dec 12 10:41:30 and a third one for "flat on desk, no applicable orientation neither landscape nor portrait" Dec 12 10:42:12 btw the absolutely identical principle should aply to GPS postitions Dec 12 10:42:42 rather, geographical locations Dec 12 10:44:02 an app should register for either relative changes of a certan minimum difference to last pos, or for absolute changes, or for reaching a certain area on this globe, or for continuous reporting Dec 12 10:44:38 same principle actually should apply to all sensors Dec 12 10:45:11 except mere binary switches Dec 12 10:45:26 like button press Dec 12 10:47:38 ooh, this actually faintly resembles crontab entries Dec 12 10:48:43 :) Dec 12 10:48:52 ooops, for geolocation you of course need both: reaching and leaving a certain area Dec 12 10:49:00 it's not easy to do stuff properly... Dec 12 10:49:43 well, I thought about all that for 5 years now, I think my take on it is relatively mature Dec 12 10:50:14 now you need ~100 slaves that implement it :) Dec 12 10:50:37 we should start a movement to define a universal sensor API Dec 12 10:53:15 would integrate nicely into FSO Dec 12 10:54:48 for a registration for continuous reporting, the dbus answer should point to a socket or fifo from which to read the strem of data Dec 12 10:54:54 stream* Dec 12 10:56:35 since you don't want to send 400 dbus msgs per second to report e.g. about accelerometer data Dec 12 10:56:53 btw does reading input device by multiple processes work? or do they steal the input events between them? Dec 12 10:57:06 that depends, I think Dec 12 10:57:32 hmm for touschreen it works IMO Dec 12 10:57:37 yep Dec 12 10:57:49 for mouse too afaik Dec 12 10:58:10 it will for accelerometers proably too... Dec 12 10:58:17 probably Dec 12 10:59:08 for /dev/urandom for example I'm pretty sure it doesn't work Dec 12 10:59:36 for device orientation there seems to be something in fso Dec 12 10:59:48 yup, I think so Dec 12 10:59:50 http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD Dec 12 11:00:02 don't know how good it works.. Dec 12 11:00:15 or if it works at all :) Dec 12 11:02:02 btw device orientation != display orientation. The latter *may* be in sync with the former, but it may as well get locked to a certain value (by user switching a orientation lockswitch), or even follow something completely different, like eyetracker via frontcam Dec 12 11:02:30 FSO should deliver both Dec 12 11:02:49 device o. and display o. Dec 12 11:06:30 radekp: try removing uSD? ;-) (for GPS check) Dec 12 11:07:05 yeah I know. Maybe pivotroot to a USB stick? Dec 12 11:11:21 radekp: is there a guide for upgrading from old squeeze based versions without losing data? Dec 12 11:57:00 DocScrutinizer05: i tried without uSD some time ago - i can try again, but not now (in city) Dec 12 11:57:43 pabs3: i'd recommend backup /home/user and do fresh install, i havent tried the upgrade... Dec 12 13:39:16 radekp: you messed my surname twice already ;) I know it's unconventional so np, just so you know :) Dec 12 13:40:42 PaulFertser: damn i am reading your name wrongly for years, sorry :) Dec 12 13:43:02 PaulFertser: we have street named "Fersters's street" and when i go by bus i hear it every day Dec 12 13:43:04 radekp: i think I tried running without uSD but I'm not sure anymore. Dec 12 13:43:10 :)) Dec 12 13:43:17 PaulFertser: that must be why i never read it correctly Dec 12 13:43:24 That's ok :) Dec 12 13:44:11 PaulFertser: i think i tried without SD card too - but the symptoms looks like it could be the capacitor... Dec 12 13:44:52 radekp: without SD card capacitor doesn't matter Dec 12 13:46:10 ahh well ok Dec 12 13:56:18 PaulFertser: what do you think about setting up a gerneral purpose sensor API definition? Dec 12 13:57:02 DocScrutinizer05: tbh, I'm sceptical. It would be a very good thing to establish one but there's nobody to follow, I'm afraid. Dec 12 13:57:07 Hopefully yet. Dec 12 13:57:43 yeah, I'm aware setting one up is one thing, implementing something or getting somebody to implement it is another Dec 12 13:59:04 FSO API was quite nice (sans absence of high-level telephony api) but somehow didn't get any traction at all :( Dec 12 18:07:31 DocScrutinizer05: btw, I'm still really puzzled about radical degradation of sensitivity of my GPS inside gta02. Tried two different internal antennas, tried lowering SD card clock, tried running without SD, tried cleaning both internal and external connectors, pushing the antenna connector etc, all in vain. **** ENDING LOGGING AT Fri Dec 13 03:00:00 2013