Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multiple relative wheels #349

Merged
merged 3 commits into from
Aug 8, 2024

Conversation

jigpu
Copy link
Member

@jigpu jigpu commented Aug 8, 2024

The X driver currently has support for devices with a single relative wheel (e.g. scroll wheels on pucks or pads). This patch set adds support for devices that have a second relative wheel sending REL_HWHEEL events from the kernel. Such a control will produce horizontal scrolling events by default. The xsetwacom tool has been updated to allow configuring these controls via the traditional "RelWheel[2]<Up|Down>" commands, as well as a new set of "Dial[2]<CCW|CW>" commands that place relative wheels on the pad (e.g. recent Huion / XP-Pen devices).

jigpu added 3 commits August 8, 2024 12:10
Allow dial and ring events to be recognized as coming from the pad
when there are no other better sources of information (for example,
BTN_TOOL_* events earlier in the event packet, an ABS_MISC with the
information, or a previously-known tool type).

This fixes an issue where the pad is not recognized (and events are
not generated) if your first interaction is with a relative wheel
rather than a button or touchring. The events types matched by this
function have an ambiguous source on their own, but other earlier
tests would be able to determine the type from other context. If
all other context-sensitive tests fail to find a tool type, it is
reasonably safe to assume we're looking at a pad.

Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Relative wheel actions are backwards from how the user thinks about them.
If you want to get/set the action that occurs when scrolling up, you
currently need to work with the REL_WHEEL_DOWN action. This is difficult
to explain to users and is also makes the code more difficult to follow.

This commit changes the behavior so that programming the REL_WHEEL_UP
action actually affects what happens when you physically scroll the
wheel up. The behavior is now: physical scroll wheel up -> positive
delta from kernel -> REL_WHEEL_UP action -> X11 mouse button 4 ->
window scrolls up.

Note that this commit will break any xsetwacom scripts that users may
have which change the relative wheel actions from their defaults. It
would also affect control panels that rely on xsetwacom or configuring
the driver directly. We don't expect this to cause significant
problems in reality since Wacom has not produced tools with relative
wheels in many years and so there are few scripts/control panels to
break.

Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Just like how tablets may have two absolute wheels, it also is possible
for them to have two relative wheels. This commit extends the
WACOM_PROP_WHEELBUTTONS property to reference two new actions:
RelWheel2Up and RelWheel2Down. These actions will be triggered in
response to horizontal scrolling events from the kernel (positive
and negative REL_HWHEEL events, respecitively). The default action
for these wheels is sending horizontal mouse scroll events (X11 mouse
buttons 7 and 6, respectively).

Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
@Pinglinux Pinglinux merged commit b43c259 into linuxwacom:master Aug 8, 2024
13 checks passed
@Pinglinux
Copy link
Member

The changes look good and clean to me. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants