No! But now it is! This app can replace memsicd: You are not allowed to view links. Register or LoginSource: You are not allowed to view links. Register or LoginInstall: overwrite the memsicd on /system/bin/ with the new daemon. Make a backup before... For testers:With a sensor app running (like speedx) you can open a terminal and type:1. su2. killall memsicd // I supose that memsicd is the new daemon...3. memsicd <delay_ms> // delay_ms is the delay in miliseconds - default is 25...
Perhaps I'm missing something here...I thought that this sensor daemon was already included in the current release for Europa (barring recent changes of course)...but when I compare, the file present in the ROM is approximately one third the size of the binaries available in the first post.[Saint]
How to instal this sensors?
OuNao,Nice with as always with the daemon code improvements.I'm wondering if you noticed some odd behaviour related to sensors on the G5. Although it happens with your daemon, it's not your daemon's fault, as the memsicd binary shows the same problem.If you have sensor rotation active, screen on, no apps open (just on the home screen with no active widgets etc.) and using the ondemand CPU governor with no overclock, the CPU frequency will always alternate between 122Mhz and 600Mhz. While this is happening there is unusual CPU activity noticeable in top - the phone really seems to be idle. This is definitely caused by the kernel i2c / sensor drivers.I tried testing some of the sensors in isolation using the Sensor List app from the market, and it seems that both the bma023 and mmc31xx drivers individually cause this problem (I tested by disabling screen rotation, and activating just one sensor at a time in the app).I'm assuming the problem is due to the high I2C bus activity or some problem with the actual sensor drivers. I tried some silly stuff, such as replacing all instances of "mdelay" with "msleep" in the sensor kernel drivers (no effect), and increasing the poll delay in your daemon (doesn't really help even if you double the delay). I wonder if there's anything we can do to reduce the problem?
Yes! I only need to remove all i2c calls from code... kidding... There´s some way to change the cpu governor code to avoid scale up the CPU frequency on i2c call? I´m don´t know how the cpu governor work, maybe we can change the cpu scale trigger...