Vibration motor — pineport

Identity


Part	Eccentric-rotating-mass vibration motor
Role	Haptic feedback / silent-mode notification
Bus / address	n/a — single GPIO output
GPIO / IRQ	GPIO3_B1 (active-high, drives `VIB_EN` net)
Datasheet	none — discrete motor + transistor switch
Pine64 wiki	PinePhone Pro Hardware
Schematic	sheet 14 (`VIB_EN` net)

The canonical Linux DTS — arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts, search for vibrator — names the pin as <&gpio3 RK_PB1 GPIO_ACTIVE_HIGH>. Earlier hand-counted bring-up notes called this GPIO1_C7; that was wrong (different bank/group entirely). Trust the upstream binding.

Status — ● working

The motor has a real FreeBSD haptics driver instead of the temporary gpioled(4) shim. src/sys/dev/evdev/gpio_vibrator.c binds the Linux-compatible compatible = "gpio-vibrator" node, claims enable-gpios = <&gpio3 RK_PB1 GPIO_ACTIVE_HIGH>, registers an evdev device, advertises EV_FF / FF_RUMBLE, stores a small effect table, and uses a callout only for replay timing. The actual GPIO and optional vcc-supply toggles run in taskqueue_thread, matching Linux’s sleepable gpio-vibra workqueue shape.

Verified live on 2026-05-03 (mise run debug:vibrator:rumble with LENGTH_MS=5000, MAGNITUDE=0xc000): EV_FF upload + play reaches gpio_vibrator, the motor physically rumbles for the requested duration, play_count and stop_count advance, and last_error=0. Both the bench’s 300 ms and a hand-tested 5 s rumble felt as expected.

What remains for userspace integration

The driver is fully working; everything below this line is about feeding events to it from compositors and apps:

No system-side haptics policy yet. Sway/Hyprland have no notion of “vibrate when the foreground app asks”. Apps that want haptics today have to open /dev/input/eventN and EVIOCSFF directly.
Mobian-style feedbackd analogue would be the right shape — a small daemon that maps semantic events (“notification”, “ringtone”, “long-press”) to FF_RUMBLE effect parameters, so apps don’t poke the device node directly. Out of scope for the kernel.
Notification routing: nothing in our overlay routes incoming Bluetooth call ringer / notification events to the vibrator yet. Likely small, just hasn’t been written.

Driver

Our tree: src/sys/dev/evdev/gpio_vibrator.c, enabled by device gpio_vibrator in src/sys/arm64/conf/PINEPHONE_PRO, with the standalone DTS node in src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-pinephone-pro.dts.
Linux mainline: drivers/input/misc/gpio-vibra.c (binding: gpio-vibrator, FF_RUMBLE-capable).
FreeBSD upstream: no dedicated vibrator driver, and stable/15’s evdev force-feedback ioctls were stubs. The local patch set adds just enough EV_FF support for simple rumble devices: advertised capability bits, effect count reporting, upload, erase, and play/stop writes.

DTS shape:

vibrator {
    compatible = "gpio-vibrator";
    enable-gpios = <&gpio3 RK_PB1 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&vib_en_pin>;
};

The leds {} child was removed in the same change. The motor GPIO must have one consumer; re-adding /dev/led/vibrator beside gpio-vibrator would double-claim gpio3 PB1.

sys/dev/evdev/cdev.c

@@ -51,6 +51,12 @@

51 51

52 52 #define DEF_RING_REPORTS 8

53 53

54 + /*

55 + * FreeBSD historically defined EVIOCSFF as _IOW like Linux, but our ioctl

56 + * dispatcher only copies the updated effect id back for _IOWR commands.

57 + */

58 + #define EVIOCSFF_LEGACY _IOW(EVDEV_IOC_MAGIC, 0x80, struct ff_effect)

59 +

54 60 static d_open_t evdev_open;

55 61 static d_read_t evdev_read;

56 62 static d_write_t evdev_write;

@@ -536,7 +542,26 @@

536 542 case EVIOCSFF:

543 + case EVIOCSFF_LEGACY:

544 + if (!evdev_event_supported(evdev, EV_FF))

545 + return (ENOTSUP);

546 + if (evdev->ev_methods == NULL ||

547 + evdev->ev_methods->ev_upload_effect == NULL)

548 + return (ENOTSUP);

549 +

550 + return (evdev->ev_methods->ev_upload_effect(evdev,

551 + (struct ff_effect *)data));

552 +

537 553 case EVIOCRMFF:

554 + if (!evdev_event_supported(evdev, EV_FF))

555 + return (ENOTSUP);

556 + if (evdev->ev_methods == NULL ||

557 + evdev->ev_methods->ev_erase_effect == NULL)

558 + return (ENOTSUP);

559 +

560 + return (evdev->ev_methods->ev_erase_effect(evdev,

561 + *(int *)data));

562 +

538 563 case EVIOCGEFFECTS:

539 − /* Fake unsupported ioctls */

564 + *(int *)data = evdev->ev_ff_effects_max;

540 565 return (0);

541 566

542 567 case EVIOCGRAB:

@@ -712,13 +735,9 @@

712 735 bitmap = evdev->ev_sw_flags;

713 736 limit = SW_CNT;

714 737 break;

715 738 case EV_FF:

716 − /*

717 − * We don't support EV_FF now, so let's

718 − * just fake it returning only zeros.

719 − */

720 − bzero(data, len);

721 − td->td_retval[0] = len;

722 − return (0);

739 + bitmap = evdev->ev_ff_flags;

740 + limit = FF_CNT;

741 + break;

723 742 default:

724 743 return (ENOTTY);

725 744 }

Parity verification

After the next kernel build + reboot, confirm:

dmesg | grep gpio_vibrator shows the GPIO vibrator attach. There should be no gpioled attach for a vibrator LED.
sysctl dev.gpio_vibrator.0.active dev.gpio_vibrator.0.active_effect dev.gpio_vibrator.0.play_count dev.gpio_vibrator.0.last_error exists and starts at inactive / no active effect / no error.
evtest /dev/input/eventN for the new device reports EV_FF and FF_RUMBLE. EVIOCGEFFECTS should report 8.
The checked-in bench helper should upload and play one 300 ms effect:
```
mise run debug:vibrator:rumble
```
Optional knobs:
```
LENGTH_MS=500 MAGNITUDE=0xffff mise run debug:vibrator:rumble
VIBRATOR_EVENT=/dev/input/event3 mise run debug:vibrator:rumble
```
The wrapper copies tools/test-vibrator-ff.c to the phone, compiles it with the phone’s cc, runs it, then compares play_count, stop_count, last_error, active, and active_effect. The driver also exposes suspended, suspend_count, and resume_count; across a future sleep cycle, active should be forced to 0, active_effect should be -1, and a play request while suspended should leave last_error=16 (EBUSY).

The harness uploads the equivalent of:

struct ff_effect e = {
    .type = FF_RUMBLE,
    .id = 0,
    .u.rumble.strong_magnitude = 0xc000,
    .replay.length = 300,
};
ioctl(fd, EVIOCSFF, &e);
write_ev(fd, EV_FF, 0, 1);

The motor should buzz for about 300 ms, play_count should increment, and active should return to 0.

Falsifier: if mise run debug:vibrator:rumble says the sysctls are missing, the new kernel is not running or the driver did not attach. If it cannot find an EV_FF / FF_RUMBLE event device, the evdev patch set did not apply or the kernel was built without device gpio_vibrator. If the command passes but the motor does not move, check last_error, then verify that the standalone DTS node has enable-gpios = <&gpio3 RK_PB1 GPIO_ACTIVE_HIGH> and that no gpioled child still owns the pin.

Remaining work

Decide whether the local EVIOCSFF _IOWR fix is acceptable upstream or should be handled as a FreeBSD-specific compatibility ioctl.
Bench suspend/resume once system sleep exists: confirm an in-flight rumble is cancelled, VIB_EN stays low, and post-resume rumble still works.
If a future DTS adds vcc-supply, bench that the rail enables only while an effect is active and shuts back off after timeout, explicit stop, suspend, and detach.

Where we are now — system peripherals status snapshot.
Front-panel RGB LEDs — sibling gpio-leds consumer the vibrator now joins.
Hardware reference — full chip manifest.