Hey, Issue #1: I believe we will start working on this in the next sprint (starting on 16th). I hope we can get a basic version out quickly, so that some adaptation can actually be made in a reasonable way. Fine tuning afterwards.
Issue #3: I'll propose fixing the contextfw sensor structure to the next sprint as well. Issue #4: An init script has been done by another team for their purposes. Should be included in the main tree soon. // Timo >-----Original Message----- >From: Zhang, Xing Z [mailto:[email protected]] >Sent: Friday, June 11, 2010 9:25 AM >To: [email protected]; Rongas Timo >Cc: [email protected]; [email protected]; >[email protected]; [email protected]; >[email protected] >Subject: RE: issue of enabling accelerometer in sensor framework > >thank you your quick reply > >> >> HI Timo: >> I am working on enabling our accelerometer in Nokia's sensor >> framework. Here are some issues i met: >> >> 1. hard coding of adaptor name. accelerometer chain and >accelerometer hard >> codes the adaptor name to >> "accelerometer". If all adaptors have same name, sensord >failed to distinguish >> right one to load. >> >> You are correct, that's an issue. We are currently trying to >figure out a nice >> solution which would allow sensorfw to always load the >correct plugin. There >> will either be a configuration file providing links between metanames >> ("accelerometer") and real adaptors ("accelerometer-<devicename>") or >> somekind of automatic detection of available sensors. In any >case, we need to >> add the use of meta-adaptors/plugins to manage the dependencies. >> >> 2. non-industry data format. For accelerometer, the generic >data format is [-Xg, >> Xg] in float, while Nokia SF >> uses integer for each axis value. If the framework will >persist in integer, there >> should be a document describes >> how should another driver map its data. Otherwise >accelerometer adopters >> can't feed their data into systems (e.g filter system) > >[Wing] OK, the mg is good. I just thought its hardware >specific format before. > >> >> The hardware drivers we have had in use have provided values >as integers, in >> [-XmG, XmG]. Thus integers were used for sensorfw as well. I >have no strong >> feelings about this though. >> >> 3. context sensor requires too many sensors. Context sensor requires >> accelerometer, compass, orientation sensor, which >> means at least needs accelerometer adaptor and magnetic >adaptor. For me >> only have an accelerometer, how can I play >> with context sensor to provide screen rotation property? >> >> The design of the contextfw sensor should be altered so that >it does not require >> everything it could possibly use to be present. And it >definitely should not list >> itself as a provider for some property it can not calculate. >Definitely needs >> fixing. >> >> In the meantime, it shouldn't be too hard to remove the >compass related parts >> from the context sensor. Comment out the dependency to >compassplugin in >> contextplugin and the construction of CompassBin in >ContextSensor. That >> *should* get it running nicely without having a magnetometer around. >> >> 4. while Nokia SF require root to run, there should be a >init.d service file to >> make it start during system boot. I didn't find it in source. >> >> There used to be one, but it was taken out when it became >unnecessary for us. >> Don't see any harm in having one around though, so if >there's a need I guess >> we could put it back. > >[Wing] for others, what time will you expect they are fixed? >Especially issue 1, >it is hard worked around. If I hard code my adaptor in >sensord, the N900 adaptor >is blocked > >> >> // Timo >> >> -- >> Timo Rongas <[email protected]> > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
