+75
−0
Loading
sensors: Add support for old libsensors HAL
Enable with TARGET_USES_OLD_LIBSENSORS_HAL:=true Change-Id: Ib430d8305148f337dd111c80be60ddd151ea5926 sensors: Improve support for old libsensors HAL Some devices (harmony, at least) claim to support the nuSensors SENSORS_HARDWARE_POLL, which was breaking the compatibility check. This removes that check from runtime and makes it exclusively a compile-time option.. Change-Id: Ide4262e5dec296d96aa896d676a06985fe09aef1 sensors: Fix sensorId/sensorType logic in back-compat layer As it was, the code was only working on devices where the ID matched the the sensorType. This isn't necessarily true on every device (and definititely isn't on some) Change-Id: I70a5d827c5a6406b5edacc334705edb43e6f5638 sensors: Simplify the data translation in the back-compat hook Since the sensor data comes in a union, we don't need to do a copy for every possible entry, we just need one per type. This cuts us down from 6 data copies on every poll to just 2. Change-Id: I755f3018ad38be1b7fa04528143507204b4df605 sensors: More compatibility fixes Some of the old HAL "magic values" aren't magic anymore, so discard them instead of trying to react like the pre-2.3 implementation. This had the potential of causing infinite loops on some libsensors (it was doing it on yamaha's) Change-Id: Id792faa6a454428040ae2973e386f3a25c904c8e sensors: Add handle-to-type mapping in back-compat layer The result of the old API data_poll is an int, which should represent a handle to the actualy sensor. That handle must be mapped to the sensor type, which is required by the new API. I was wrongly assuming the handle and the type were the same, and that isn't necessarily true; the only reason this was working is because the java client API appears to be still doing its own handle-to-type mapping and mostly ignoring the type value set at the native layer Change-Id: Ibe6209b91cf96aa885a05d6091155ee7ef929211 sensors: Add workaround for Foxconn's broken sensor data FIH has a tendency to add in-kernel "shortcuts" for stuff that's usually controlled in userspace, and disabling the screen+backlight on proximity was one of those. That implementation is, however, buggy, and on top of that it's colliding with the standard userspace implementation. This should be corrected at the sensors HAL, but reimplementing that has been a work-in-progress for quite some time now and still isn't functional. So, for now, toggle a workaround with TARGET_HAS_FOXCONN_SENSORS, and convert the data into the kind of values the framework expects. Change-Id: Ib974af729ce0511668c835b9078831330b874a1f Add TARGET_SENSORS_NO_OPEN_CHECK for betelgeuse (Folio100) support sensors.tegra.so on betelgeuse return -22 on both sensors_control_open, sensors_data_open, but sensors are OK after those two calls. Change-Id: Iabe14f9ed26ff182041f447cf278408ada62ef81 sensors: Fix ALS and PS lag on back-compat layer These 2 sensors only report values on change, instead of continuously generating samples at 'setDelay' intervals like most others. If only these 2 (or any one of them is enabled), we can't wait for the usual 64 samples to be taken before reporting them to the framework, since that'll make them visibly laggy. This patch causes any sample from these sensors to trigger an immediate report to the client. Change-Id: Id5932376858c30323bff07ac4b38856dc200d074 sensors: Add dummy light sensor for p990/p999 This is necessary for the rest of userspace to recognize its existence and toggle it for auto-brightness. It doesn't generate actual light values, though; all backlight adjustments are made in-kernel. Change-Id: I0e546b4740720bd34d1e1d85a96b295fcc697106 sensors: Allow target to override max range of proximity sensor If a proximity sensor rarely or never reaches its maxRange, the device will frequently lock up after the sensor is triggered (by a call, for example), since it'll get stuck in the "active" state. Set TARGET_PROXIMITY_SENSOR_LIMIT := <value> with the distance from which the sensor will turn off to override those cases Change-Id: I31fa2e5b9bd40ed6d80a1d5b0c147ed265f94c3a Change-Id: Ib430d8305148f337dd111c80be60ddd151ea5926a