Android vibrator (haptic feedback) support

Products Support HiKey 960
#1

I’m trying to get haptic feedback working on a Hikey 960. I hooked up a Ti DRV2605L driver IC with a LRA motor and enabled kernel support for it. On boot up, the motor gives a brief buzz, so it seems to kernel has it working. However, I cannot use it in Android yet. Calling Vibrator.hasVibrator() returns false.

I guess I have to set up the android.hardware.vibrator HAL, but I cannot really figure out how to go about it. Is there anybody that has been succesful in getting this to work? Any help would be much appreciated.

#2

Well basically, you fork the default vibrator hal into the device tree and modify it to control your hardware. And don’t forget the sepolicy, init won’t start the hal service without it, even in permissive mode.

https://android.googlesource.com/platform/hardware/interfaces/+/master/vibrator/1.0/default/

#3

Thanks! Meanwhile I took a few steps into the right direction. Turned out the kernel driver in AOSP for the drv2605 is not the driver TI recommends to use in Android. So I took one from TI’s GIT, which in turn was way too old to compile under Pie (timed_output and wakelock deprecated), so I had to fix that up. But now I can at least trigger the vibrator from the sysfs. Then I looked over the fence in device/google/marlin and found a HAL implementation that I should be able to convert into something that’ll work. Will keep you posted!

#4

Spent all day trying to get it to work, only to find out that the one thing I needed to do was add a hidl entry to the device manifest referencing the default vibrator…

I can’t use the chip’s built/in effects library yet but that should be doable now that I have a useable device :slight_smile:

#5

@doitright Still struggling with this. When I fork the default implementation, I have to rename the HAL to android.hardware.vibrator@1.0-impl.hikey otherwise the compiler complains about duplicates. And consequently I have to change that name in the related PRODUCT_PACKAGES in device-common.mk. So now it also builds a android.hardware.vibrator@1.0-impl.hikey.so and android.hardware.vibrator@1.0-service.hikey.so. Sounds good to me?

But now during init, I get stuck with this:

[ 14.470211] init: Received control message ‘interface_start’ for ‘android.hardware.vibrator@1.0::IVibrator/default’ from pid: 2128 (/system/bin/hwservicemanager)
[ 14.485867] init: Could not find ‘android.hardware.vibrator@1.0::IVibrator/default’ for ctl.interface_start

What is this again? I have no clue how to get rid of this and make the build use my fork…

#6

I thought you said you had it working with the marlin HAL as a pattern? In using the default HAL, you would have to modify it into something much more like the marlin HAL anyway, otherwise you would be stuck writing a new legacy HAL, which would be kind of silly.

#7

Being completely new to this HAL stuff, it’s pretty difficult to distinguish between what is legacy and what isn’t. I was happy I got something working at all, so decided to try to take what worked. But I’ll try that marlin route again knowing what I’ve learned so far and will report back when that goes horribly wrong again :slight_smile:

#8

I’ve rebuilt it now using the marlin implementation instead of the legacy one, but I get the exact same error.

dmesg: [ 19.523687] init: Could not find ‘android.hardware.vibrator@1.0::IVibrator/default’ for ctl.interface_start

logcat: 01-01 21:18:33.295 2355 2355 I ServiceManagement: getService: Trying again for android.hardware.vibrator@1.0::IVibrator/default…

lshal is not listing the vibrator HAL (while it did when I was still using the default) and ps is also not listing the new service. So I guess Iĺl have to figure out why it doesn’t start…

– edit –

ok got a bit further now (forgot to update sepolicy like you warned me for), but now the service exits with status 243. No idea what that is but I’ll get there eventually :slight_smile:

– edit –

ok that actually made sense because the service was trying to open the sysfs path for vibrator amplitude control, which the kernel driver doesn’t create yet…

#9

Regarding legacy vs current HALs… Basically what you are looking for is this;
https://source.android.com/devices/architecture/hal-types

Or more specifically about LEGACY HALs, this;
https://source.android.com/devices/architecture/hal

So basically, they’ve maintained certain default HALs in a way where they will be able to load old HAL libraries, allowing a hardware vendor to upgrade to 8.0 without having to rewrite all of their HALs.

It sounds like you have the situation under control. Now you just need to modify the HAL to actually manipulate your hardware.

#10

yup got amplitude control working as well. now adding support for playing effects from the fx library built into the chip. thanks for your help!