There was a brief BoF session in San Francisco conference around future ideas for sensor framework (http://sf2011.meego.com/program/sessions/bof-future-sensor-handling). We hoped to gather some ideas for future improvements, and had a good chat with the people present. I'll summarize here few of the improvement ideas that were discussed in the BoF, things that have been discussed with the folks involved in sensor framework development, and also what's been cooking in my head.
a) Dynamic sensor availability. Currently we have a static list of sensors available from the API. It would be very useful to have the list of available sensors reflect reality. Sensors that are not available should not be offered, and all sensors that are available should be available through the API. b) Hot-pluggability. Although HW is mostly static and can be given by configuration, there are situations where a sensor might be attached on the fly (e.g. for TV). It would be nice to recognize the sensor automatically (udev rules?). This type of approach would automatically solve issues like BMC#16395 (drivers not loaded at sensord start time). c) Sensors of the same type. Currently there is no concept of sensor type in sensor framework, which makes having e.g. two accelerometers at the same time a bit difficult. In IVI-world, there are sensors e.g. in wheels, of which there are more than one in most vehicles. d) Extensibility. Currently adding a new sensor type requires a bit too much work, and is hindered by the structure of client side library (daemon side works by plugins, client side does not). It should be possible to add a new sensor type by just introducing new plugins with an additional package. Especially in the IVI world there is bound to be quite a bunch of sensors and adding them should be made easy. (discussion also starting at IVI-list: http://lists.meego.com/pipermail/meego-ivi/2011-June/000548.html). e) Improved configurability. There are still some hard coded things in the code. Device specific changes should be possible through configuration rather than addition of new plugins whenever possible. Especially adaptors talking to driver interfaces should be made generic to avoid nearly similar copies. A good and generic adaptor implementation could even guide the driver interface design later on. Those are the current problem areas in a very high level nutshell, most of which revolve around similar structural changes. As the whole sensor handling area is a bit too large to be handled in a single email, I'll go ahead and start sketching 'this is how I feel it should work' -type of wikipage at http://wiki.meego.com/User:Ronksu/SensorfwFutureVisions. So far it contains only few preconference lines, but I'll start filling it in with high level issues, hopefully getting more technical over time. If anyone has a suggestion where this type of planning should be done for real, let me know and I'll move the wiki there. Any help in figuring out the real current requirements for sensor framework would be appreciated. Architects ohoy! Also, if some (other) activities around future development of sensor framework exist, let me know. // Timo (Ronksu @ IRC) -- Timo Rongas _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
