fix: preserve accumulated drag-scroll distance, queued or coalesced

[ankostis]

The job of the Drag-scroll distance-accumulating buffer is to reduce mouse's input-distance by dividing it by CHARYBDIS_DRAGSCROLL_BUFFER_SIZE.

Problem (fixed)

Before this PR, when the buffer was full (accumulated-distance > CHARYBDIS_DRAGSCROLL_BUFFER_SIZE),
a ±1 wheel-event was emitted and the spill-over distance was dumped,
beginning the next accumulation cycle (every POINTING_DEVICE_TASK_THROTTLE_MS) always from 0.

In other words, the distance division was getting rid of the remainder,
which at times can be above 1000!
This effectively caps the attainable scroll-speed.

With sensible defaults (SCROLL_DPI: 100), the effect was a subtle jerk and capped scrolling speed,
but in higher DPIs, or with mouse-acceleration1 enabled, and feeding to drag-scroll,
all expected additional velocity was simply lost2.

Feature added

This PR additionally retrofits the drag-scroll with a new config CHARYBDIS_DRAGSCROLL_SEND_COALESCED
that controls how accumulated drag-scroll distance from fast moves are emitted:

• undefined: queued and emitted as ±1 events
  even after "wheel" has stopped moving; scrolling in the opposite direction will immediately cancel any queued events;
• defined: scroll-wheel events with values greater than ±1 are immediately emitted.

Mouse acceleration

To enjoy this you need a potent source of mouse distance, like the Mouse acceleration mod2 ("maccel").
But bkb code in keyboards/bastardkb/charybdis/charybdis.c:pointing_device_task_kb() drives the user task
(where the maccel runs) after drag-scroll code, so you have to reverse the x2 lines in the above function
into this:

report_mouse_t pointing_device_task_kb(report_mouse_t mouse_report) {
    if (is_keyboard_master()) {
        mouse_report = pointing_device_task_user(mouse_report);
        pointing_device_task_charybdis(&mouse_report);
    }
    return mouse_report;
}

The last commit in this PR does just that.

:::{note}
You may see this PR in action in ankosti's charyoku keymap for charybdis-4x6.
:::

[ankostis]

Apologies for fat-fingering the OP text & title, ignore this email notification.

[ankostis]

Introduced an unforeseen enhancement:

The accumulation fix allowed for "travelling", like "inertia", ie. keep scrolling while mouse has stopped moving,
assuming enough distance had been accumulated, eg. due to high acceleration.
That's very much wanted for big files and streams eg. Discord.

But there must be a way to immediately break travelling, eg when we found what we wanted
and instinctively moving the mouse in the reverse direction.
In that case, the mouse has to work against accumulated distance before acting.

[ankostis]

Turned this PR back into "draft" because with the the scroll-distance accumulation fixed,
we now have the opportunity to choose from x2 behaviors (or have both on demand):

• Inertia Queued: keep sending accumulated scrolling distance even after user has stopped dragging scroll
• Flush: Coalesced: divide and send all scrolling distance at once on every duty-cycle

Although the flush coalesce idea is sound and certain apps can readily cope with it,
inertia is more cool because you can see the whole thing scrolling in front your eyes.

So it may be worth it to have them both, and configurable/activated on demand.
What do you think?

[0xcharly]

Hi, and thanks for taking the time to look into the behavior and submit a PR.

Now that QMK has introduced their pointing device subsystem, there's no reason to maintain or update this piece of bespoke Charybdis code anymore. It is scheduled to be entirely removed and replaced with the QMK core feature.

For this reason I'd suggest upstreaming your changes directly to QMK, if need be.

[ankostis]

For this reason I'd suggest upstreaming your changes directly to QMK, if need be.

From what i have learned, the new subsystem won't have anything in common, so no point to push it there. And i absolutely understand the burden of attending code destined for retirement, and why this PR must be rejected, not to spur further development.

On a personal note, i take pride from my work, so i made this to play along with the great maccel feature, forming a pretty functional dead-end duo that can stay in limbo to denote the fact.

Only allow me to settle any loose ends on this PR, OP, title, etc, because
"if a job's worth doing, it's worth doing well" :-)