Subject: bug#51891: 29.0.50; [PATCH] Pixel delta support for wheel events on X

From: Po Lu <[email-masked]>
Date: Thu, 18 Nov 2021 08:15:27 +0800

Eli Zaretskii <[email-masked]> writes:

> Did you consider the possibility of defining a new event?

Yes I did, but IMO it makes more sense to make this use the normal
`wheel-events'.

> And should mwheel.el be aware of this change somehow?

It doesn't have to.  A separate mwheel-scroll-*-function can be used to
implement pixel scrolling, once we get to that.

> And finally, why introduce keyword-value pairs into a form that didn't
> use them before?  Can we store just the values there?

Different window systems might have more/different information.  For
instace, I can imagine the GTK port wanting to include scroll phase and
inertia data into this propertly list.

>> +			scroll_unit = pow (FRAME_PIXEL_HEIGHT (f), 2.0 / 3.0);

> Ouch! can we avoid calling 'pow' here?  It's an expensive function.

That's what the other big users of XInput 2 do, including GTK+ and
Mozilla Firefox, and is unfortunately the only method of obtaining true
pixel scroll data from a scroll valuator.

>> +  DEFVAR_BOOL ("x-coalesce-scroll-events", x_coalesce_scroll_events,
>> +	       doc: /* Non-nil means to only send one wheel event for each scroll unit.
>> +Otherwise, a wheel event will be sent every time the mouse wheel is
>> +moved.

> This is confusing: what does "scroll unit" mean in this context?

An amount of scrolling that would previously generate a `mouse-4' or
`mouse-5' event.

But since I think most people don't know what such button events are,
it would not be sufficient to just put that into the doc string.

Any ideas?

Thanks!