Madhav KavuruThis design is unpatented and will stay that way
Here is the paper trail so you don't have to take my word for it.
I filed US provisional patent application 63/819,460 on June 6, 2025, titled "Virtual Scroll Wheel Input Device with Adaptive Touch Sensing and Modular Haptic Feedback." I let it lapse — no non-provisional was filed, and the twelve-month window closed on June 6, 2026. In August 2025 I released the full specification and figures as open source, posting them at several online locations including LinkedIn, together with the one-page sell sheet in the gallery above. That publication is now more than a year old, which under US law bars me from patenting this and makes it prior art against anyone who files after that date. Patent searches turned up no prior art that would block implementation. A defensive publication is on file at Technical Disclosure Commons so the record is indexed and searchable by patent examiners.
So: if you make laptops, mice, touch controllers, or haptic drivers, you can build this. You owe me nothing. I would like attribution and I would like to see it exist.
And build the small version. Costed line by line below, the whole thing — arc, haptic motor, tilt, zoom — comes to roughly $4.80–8.70 of BOM at 100k units a year, and Core alone is roughly $3.70–6.50. But the reason to start with Core is not the dollar or two. Core is three components and a firmware loop: a curved capacitive arc, a smartwatch-class LRA, and centroid-based vertical scrolling with synthetic detents. It delivers what a mouse wheel delivers, in a 9.5 mm stack, without putting a vibration-isolation problem on your critical path. Tilt-to-horizontal is there when you want a second generation, and pressure-zoom adds nothing to the BOM at all.
If you are a hobbyist, the interesting unsolved parts are the arc electrode layout, tuning the contact-width gate against real finger data so press-down never registers as a stroke, and getting convincing detent feel out of a cheap LRA. Fork it and tell me what breaks.
— Madhav Kavuru, mkavuru2@gmail.com
The problem, stated precisely
Every laptop maker has been asked for a scroll wheel. None ship one. The reason is not taste, it is 15 millimeters.
Scroll wheels on current mice run roughly 15–22 mm in diameter. A thin laptop's keyboard section gives you about 10 mm total. Shrink the wheel below 15 mm and it becomes unpleasant to use, and you still have to redesign and miniaturize the optical encoder, the bearing, and the ratchet. So instead we get scroll strips painted onto a corner of the touchpad, which are too sensitive to be precise, break after driver updates, eat usable touchpad area, and force you to steer around them to avoid scrolling by accident. They feel like dragging a scroll-bar thumb, not like a wheel.
Arrow keys, meanwhile, remain terrible. In a word processor they move line by line and then jump a page at a time.
The idea
You never touch most of a scroll wheel. You touch an arc at the top. So build only that arc.
Take a disk segment — a circular segment no bigger than a semicircle — and stand it up through an opening in the chassis. Put a mutual-capacitance touch sensor along its curved outer face. Now your fingertip has the same curved reference geometry it gets from a real wheel, which is exactly what a flat strip fails to provide. With a 22 mm implied wheel diameter and a 17 mm chord, the segment is 4.02 mm tall — about the same as the exposed part of a mouse wheel — and about 2 mm of it pokes above the keycaps.
Then give it detents that don't exist. Bond a linear resonant actuator to part of the flat chord face of the segment. Smartwatch LRAs (12 × 5 × 3 mm, the class of part used in Apple Watch) are mature, cheap in volume, and already qualified for sub-20 ms haptic latency. Dimensions that are a problem in a watch are nothing in a laptop. Drive it with PWM waveform profiles and you can synthesize click detents, free-spin inertia, and page-turn cues — and change all of them in software after the hardware ships.
Why anyone would actually want this
The engineering case is the stack height. The user case is simpler, and it is what the sell sheet led with:
- Smooth infinite scrolling without the jumpiness of arrow keys or the over-sensitivity of a touchpad scroll zone.
- A scroll wheel on the couch, in bed, or on a plane tray table — no flat surface required.
- One less accessory to carry, charge, or buy batteries for.
- A USB port back, because no wireless dongle.
- Familiar wheel ergonomics that gamers, coders, and heavy readers already know.
- [quoted] — a real distributor price for a real part, with the price break stated. Sourced, verifiable, and high: catalogue reel pricing at 1k–6k units is well above what an ODM pays on contract at 100k+, typically by 30–50%. The volume column reflects that discount.
- [modeled] — no public price exists for a custom part, so this is an engineering estimate from the part's size, material, process, and tolerance. Treat these as the soft numbers. They are where the range comes from.
- The LRA is the biggest single line — 30–45% of Core. A coin LRA is cheaper than a bar; direct sourcing beats catalogue pricing substantially at volume.
- The driver IC is optional. Drive the LRA from an existing PWM channel through a discrete H-bridge and you save most of that line, at the cost of back-EMF sensing and auto-resonance tracking. Detent feel will drift with temperature and age. I would not do this, but it is a real option.
- No dedicated MCU is needed. The module can report over I²C-HID to the embedded controller or SoC, the same path a precision touchpad already uses (Microsoft). Do not budget a microcontroller for this.
- If the laptop already ships a haptic touchpad, it already has an LRA driver, a waveform library, and a tuning process. Marginal cost and marginal engineering both drop sharply — that is the cheapest platform to add this to.
- Anchor the post to the arc away from the LRA's mount, near the arc's edge along the chord.
- Use silicone with real damping, on the order of 50–70 Shore A.
- Keep the accelerometer at least 2 mm from the post's PCB anchor point.
And on the hardware side: software-tunable detent and free-spin profiles, no moving parts to wear out or collect dust, a standard HID descriptor that does not touch the touchpad driver stack, and — in the Full configuration — tilt-to-horizontal and pressure-zoom with no mechanical tilt assembly.
THREE WAYS TO BUILD THIS — read this section first if you make laptops
I originally wrote this project up as one design with every feature switched on. That was a mistake for anyone who has to actually ship it. The value is concentrated almost entirely in one feature — wheel-feel vertical scrolling — and two of the things I was most excited about are the two things that would slow a product down the most.
So here is the same design, separated into what you need and what you can leave out.
Core | Core + zoom | Full | |
Curved touch arc (disk segment) | ● | ● | ● |
LRA + driver, synthetic detents | ● | ● | ● |
Silicone isolator | ● | ● | ● |
Vertical scroll, centroid tracking | ● | ● | ● |
Pressure-to-zoom | — | ● (firmware only) | ● |
Tilt-to-horizontal-scroll | — | — | ● |
Metal post + MEMS accelerometer | — | — | ● |
New parts vs. Core | — | none | 2 |
Est. BOM at 100k/yr | $3.70–6.50 | $3.70–6.50 | $4.80–8.70 |
Time to market | fastest | fastest | longest |
Core is the product. A curved arc, a haptic motor, and vertical scrolling with real detents. That is what a mouse wheel gives you, and it is the entire reason anyone has ever asked for a scroll wheel on a laptop. Everything below Core in the table is a refinement of something users mostly did not ask for.
Core + zoom costs nothing in hardware. Pressure sensing reuses the capacitance array that is already there — press harder, the fingertip flattens, contact area grows, the controller already sees it. It is firmware. If it doesn't tune well on your panel, ship without it and add it in an update.
Full is for a second-generation part, or for a flagship where horizontal scroll is a spec-sheet line you want.
Costed line by line in the section below, Core lands at roughly $3.70–6.50 per unit and Full at roughly $4.80–8.70 at laptop volumes. I originally guessed "under $10" for the full thing; that turned out to be a fair ceiling rather than a target.
Two honest caveats:
Core does not make the module thinner. The accelerometer sits beside the controller rather than in the stack, so the ≈9.5 mm budget below holds either way. What you save by choosing Core is parts, tuning time, validation scope, and risk — not height.
And the case for Core is schedule, not BOM. The per-unit difference between Core and Full is only about $1.10–2.20. The real difference is one-time engineering: the accelerometer path is where the mechanical isolation characterization, the FIR filter work, and the late-validation risk all live. Cut tilt to ship sooner, not to save a dollar.
What it costs to build
Every figure below is per unit, in USD, assuming a single laptop SKU at roughly 100k units per year. Two kinds of number appear:
Core
Line | Basis | Distributor anchor | Modeled at 100k/yr |
Disk segment — molded dielectric, 17 mm chord × 4.02 mm, hard-coated | [modeled] simple 2-plate mold, no undercuts | — | $0.35–0.70 |
Electrode array — FPC, 1 TX + 16 RX, laminated to the arc | [modeled] ~19 × 8 mm 2-layer FPC, 200 µm pitch | — | $0.25–0.50 |
Mutual-capacitance touch controller | [quoted] Azoteq IQS7211E002CSR, $0.392 at 3k, $0.349 at 6k (Mouser) | $0.39 | $0.25–0.40 |
Linear resonant actuator, 12 × 4 × 3.5 mm class | [quoted] Jinlong/Vybronics bar LRA, $2.09 at 1k (JLCPCB) | $2.09 | $1.20–1.80 |
LRA driver with back-EMF and auto-resonance | [quoted] TI DRV2605LYZFR, $1.06 at 1k, $0.99 at 3k, $0.969 at 6k (Mouser) | $0.99 | $0.60–0.90 |
Silicone isolator, die-cut, 1 mm, 50–70 Shore A | [modeled] die-cut sheet, pennies at volume | — | $0.05–0.12 |
Module PCB, 2-layer, ~15 × 20 mm | [modeled] | — | $0.10–0.25 |
FPC termination — connector or hot-bar bond | [modeled] | — | $0.08–0.20 |
Passives, decoupling, ESD protection | [modeled] | — | $0.05–0.10 |
SMT + mechanical assembly + functional test | [modeled] module-level, includes handling the arc | — | $0.60–1.20 |
Tooling amortization over ~500k lifetime units | [modeled] | — | $0.03–0.08 |
Yield and scrap allowance, 3–5% | [modeled] | — | $0.10–0.20 |
Core total | $3.66–6.45 |
Full — what tilt-to-horizontal adds on top of Core
Line | Basis | Distributor anchor | Modeled at 100k/yr |
MEMS accelerometer | [quoted] Bosch BMA530, $1.48 at 1 pc, 10k reel (Mouser) | $1.48 | $0.70–1.10 |
Rigid metal post | [modeled] stamped or turned stainless, ~2 × 8 mm | — | $0.08–0.20 |
Silicone sleeve for the post | [modeled] | — | $0.03–0.08 |
Added assembly step — post insertion and alignment | [modeled] tighter tolerance than any Core step | — | $0.15–0.35 |
Per-unit tilt calibration at end of line | [modeled] added test time | — | $0.10–0.30 |
Added yield risk on the isolation stack | [modeled] | — | $0.05–0.15 |
Full adder | $1.11–2.18 | ||
Full total | $4.77–8.63 |
Pressure-to-zoom: what it costs
Per unit: $0.00. No component, no PCB area, no thickness, no assembly step, no test step. It reuses the contact-width measurement the tracking gate already computes from the capacitance array you already have. There is genuinely nothing to add to the BOM.
Two conditions where that stops being true, both worth checking before you promise it:
- Your touch controller has to expose contact area or touch strength, not just X/Y. Fixed-function trackpad controllers that report only coordinates cannot do this. If yours is one of them, you need either a raw-data or strength-reporting mode, or a part that has one — which can move the controller line item, though parts in this class sit well under a dollar either way.
- The processing has to live somewhere with headroom. If the module reports over I²C-HID to the host — which is how Windows touchpads already talk to the system (Microsoft) — the arithmetic is free on the SoC. If instead it has to run inside a fixed-function controller, you may be paying the vendor for custom firmware, which is NRE, not BOM.
So the real cost of pressure-zoom is engineering time: threshold and mapping tuning across finger sizes, a settings toggle, QA. It is the cheapest feature in the project by a wide margin.
One-time costs, which are not BOM
These dominate the decision far more than the per-unit numbers do:
Item | Core | Full |
Injection mold for the segment, plus housing changes | $8k–25k [modeled] | same |
Custom FPC tooling | ~$2,000 typical, MOQ 5k (Vybronics) | same |
Electrode pattern tuning and controller configuration | 4–8 engineer-weeks | same |
Haptic waveform design and tuning | 2–4 engineer-weeks | same |
I²C-HID descriptor, host integration, settings UI | 4–8 engineer-weeks | same |
EMC, ESD, drop, and life testing | $15k–40k [modeled] | more |
Accelerometer isolation characterization, FIR development, scope and shaker time | — | +3–6 engineer-weeks |
Pressure-zoom tuning and QA | optional, 1–2 engineer-weeks | same |
That last-but-one row is the actual argument for shipping Core. A dollar or two of BOM is noise inside a laptop. Several engineer-weeks of vibration isolation work sitting on the critical path, on the feature most likely to fail late validation, is not.
Cost levers, if you want to go lower
All distributor prices above were checked in September 2026 and will drift.
Stack budget
Layer | Thickness | Config |
Touch arc / disk segment | 4.0 mm (≈2 mm protrudes, roughly flush with keycaps) | all |
Haptic motor with LRA | 3.0 mm | all |
Silicone damping isolator | 1.0 mm | all |
PCB | 0.6–1.6 mm | all |
PCB-to-wall standoff | 0.5–1.0 mm | all |
MEMS accelerometer | 1.2 × 0.8 × 0.55 mm, beside the controller — not in the stack | Full only |
Total | ≈ 9.5 mm | all |
That fits a 10 mm keyboard section. This is the whole point of the project.
Sensing details
One TX electrode along the strip's length, RX electrodes perpendicular and segmented along it. RX count sets resolution — strips typically use 5–20; use 16 or more for 0.5 mm. One end of each line routes to a dedicated controller pin, the other terminates at the pattern edge. Even electrode spacing along the arc, which makes the software mapping trivial.
Do not use a self-capacitance (RX-only) strip. Ghost touches, noise susceptibility, worse resolution, less stable responsiveness.
Because the segment is a rigid, non-bendable part with evenly spaced electrodes, it should be easier to manufacture than the curved touch panels already mass-produced for phones.
Position tracking: centroid, with a contact-growth gate
Earlier versions of this write-up argued for tracking the leading edge of the contact patch instead of its centroid. I no longer recommend it, and I want to explain why in public rather than quietly delete it, because the reasoning is useful either way.
The original argument. On a 17 mm arc your index fingertip covers a large fraction of the sensor at once. As the finger travels, the centroid of that broad contact patch shifts less than the finger does. So scroll distance comes out understated, and direction at the very start of a stroke comes out mushy.
Why that argument doesn't survive contact. The problem with tracking the leading edge is that the contact patch changes size as well as position, and an edge estimator cannot tell those two apart. As the index finger presses down, the patch grows in both directions along the arc. The leading edge therefore advances upward while the user is beginning a downward swipe — so the pointer jumps up before it goes down. That artifact is not a corner case; it happens at the start of nearly every stroke, exactly where the original argument claimed edge tracking would help most.
Three more objections, in order of severity:
- An edge is a threshold crossing, so it quantizes to one electrode. At 16 RX over roughly 19 mm of arc, the pitch is about 1.2 mm — the edge can only report in those steps, and it flickers between adjacent electrodes on noise. A centroid interpolates between electrodes and resolves well below the pitch. The precision mode in the spec, at 0.1 mm, is only reachable with an interpolating estimator.
- The algorithm is circular. Choosing which boundary is the "leading" one requires already knowing the direction of travel, and direction was derived from the previous edge estimate. An error therefore reinforces itself instead of washing out.
- What centroid actually gets wrong is a scale error, not lost information. Understated displacement is a gain problem, and a gain problem is fixed by one calibration constant. It does not justify replacing the estimator.
What to do instead. Keep the centroid — decades of touch controllers already compute it well, every vendor's front end hands it to you, and it interpolates. Then fix the real defect the original argument identified, which was never the centroid itself but the press-down and lift-off transients, by gating on contact width:
- Init sensor: mutual capacitance, 1 TX, 16+ RX.
- Scan matrix: TX pulse sequence, measure RX, collect raw data.
- Filter noise, subtract baseline, threshold.
- Compute contact centroid (weighted average of activated electrodes) and contact width Δ = Max(RX) − Min(RX).
- Gate: if width is changing faster than a set rate, the patch is growing or shrinking — a press or a release, not a stroke. Report no motion this frame and update the reference position. This is the step that kills early-stroke mush.
- Scroll distance = (current centroid − previous centroid) × sensitivity, where sensitivity is calibrated once to compensate the centroid's understatement of finger travel.
- Reject frames below a minimum displacement to suppress jitter while a finger rests on the arc.
- After 500 ms of continuous contact, enter precision mode at 0.1 mm resolution.
- Fire the LRA with PWM derived from distance and speed.
- Send the USB HID report.
Vertical only. The width signal from step 4 is the same signal pressure-zoom uses, so nothing is wasted.
For completeness, the leading-edge variant remains fully documented in the specification and in the defensive publication, and it stays there deliberately — as prior art, broader disclosure is better, and someone with a smaller contact patch or a longer arc may find the tradeoff goes the other way. It just should not be the shipping default, and if you implement it at all, put it behind a settings toggle rather than in the main path.
Haptic profiles
Detents at roughly 0.1 N·m, free-spin at 0.05 N·m.
Parameter | Value |
Base frequency | 100–200 Hz (LRA resonance) |
Detent click | 50% duty, 1–2 ms pulses |
Free scroll | 10–30% duty, continuous sine modulation |
Pressure feedback | 5–80% duty, proportional to force |
Crisp detent waveform | Square, 175 Hz at 50% duty |
Inertial scroll waveform | Sine sweep 100 → 200 Hz |
Page turn | Burst, 3–5 cycles at 175 Hz |
Touch-to-vibration latency | < 20 ms |
Closed-loop: back-EMF sensing to correct PWM in real time, auto-resonance tracking to hold efficiency across temperature and aging.
The 1 mm silicone isolator is required in every configuration — it keeps the sensation at the fingertip instead of buzzing the whole palm rest. In the Full configuration it does double duty by keeping actuator energy out of the accelerometer's data.
Optional: pressure to zoom (firmware only, no added parts)
No force sensor. Press harder, your fingertip flattens, contact area grows, and the mutual-capacitance array already sees it — it is the same width measurement the tracking gate uses. Threshold at about 10 g to enter zoom mode so ordinary scrolling never triggers it, then map 10–50 g linearly to 1×–5× zoom granularity. Scroll forward under pressure to zoom in, backward to zoom out — the convention people already know from Photoshop and video editors. A double-pulse marks the moment you cross into zoom mode.
This is the cheapest feature in the project: it adds no component, no thickness, and no tooling. The only reason to leave it out of a first release is tuning time on your specific panel.
In the Full configuration, tilt data disables pressure zoom during horizontal scrolling so the two never fight. In Core + zoom there is no horizontal scroll, so that interlock is simply not needed — one less state machine.
Optional: tilt to scroll horizontally
This is the feature I would cut first, and I say that as the person who came up with it. Most people never horizontally scroll deliberately, and the ones who do already reach for shift-scroll or a trackpad gesture. Meanwhile it is the single most expensive feature in the design in engineering terms: it adds two components, a mechanical isolation problem, and a signal-processing problem, and it is the part most likely to fail validation late. Omitting it leaves the main selling point — a scroll wheel in a laptop — completely intact.
If you do want it: a rigid metal post in a silicone sleeve runs alongside the LRA and mechanically bypasses it, coupling the touch arc straight to the PCB. Press the arc, the board flexes a little, and a MEMS accelerometer a few millimeters away reads that flexure. Tilting mice use a rocker assembly for this; here there is no pivot at all. The ±2 g setting is plenty. The Bosch BMA580 fits well: a 1.2 × 0.8 × 0.55 mm six-pin WLCSP, 16-bit, selectable ±2/±4/±8/±16 g, 12.5 Hz to 6.4 kHz in high-performance mode, 120 µg/√Hz typical noise density, programmable low-pass filtering, I²C up to 1 MHz (BMA580 datasheet). Bosch aims it at hearables and XR glasses and sells it on bone-conduction voice activity detection, which is dead weight here — so the sibling BMA530, aimed at wearables and smartphones, is just as good a pick. Its published package, range, rate, resolution, noise, and interface numbers are identical. Honestly any low-g triaxial part that hits those numbers works — nothing in this design needs a specific chip.
The obvious objection is that the LRA will drown the accelerometer in its own vibration. Three things together fix it, and you need all three:
Add FIR filtering in the DSP pipeline and the haptic energy stays out of the force signal. If that sentence sounds like a week of oscilloscope time, it is, and that is the argument for shipping Core first.
Where it goes
Adjacent to the upper right corner of the touchpad, or adjacent to the lower right corner of the key field. Both sit outside the region your hands sweep while touch-typing, so accidental actuation isn't an issue. Cut recesses in the housing at both ends of the segment to expose more arc to the index finger.
The same module drops into a mouse: mount it to a sloped internal PCB surface matched to the shell's slope and it looks and feels like the wheel it replaces, minus the bearing. A USB-C numpad is a third host.
How it compares
This design (Core) | This design (Full) | Mechanical wheel | Flat touch strip | |
Tactile feedback | Variable LRA pulses, software-defined | Same | Fixed mechanical detents | Undifferentiated buzz |
Finger reference geometry | Curved arc, same as a wheel | Same | Curved wheel | None — flat |
Resolution | 0.5 mm, 0.1 mm in precision mode | Same | 1.5° optical encoder | ~2 mm zones |
Form factor | 4 mm protrusion, 9.5 mm stack | Same | 15–22 mm diameter | Flat |
Moving parts | None | None | Bearing, encoder, ratchet | None |
Horizontal scroll | No — use shift-scroll | MEMS tilt, no pivot | Bulky rocker | Second strip or gesture |
Zoom | Optional, firmware only | Capacitive force, no added sensor | No | No |
Service life | No wear surfaces | No wear surfaces | Wears, collects grit | No wear surfaces |
Driver risk | Separate device, own HID descriptor | Same | n/a | Shares the touchpad stack |
Added components vs. Core | — | 2 | n/a | n/a |
License
- Documentation, figures, and renderings: Creative Commons Attribution 4.0 International (CC BY 4.0) — https://creativecommons.org/licenses/by/4.0/
- Hardware design: CERN Open Hardware Licence Version 2 – Strongly Reciprocal (CERN-OHL-S v2) — https://ohwr.org/cern_ohl_s_v2.txt
- Firmware and code: MIT License — https://opensource.org/license/mit
No patent rights are asserted by the author.