Mouse Button Configurations on Pad Fail

[acook]

I think this is related to #289

After configuring:

xsetwacom set "Wacom Intuos Pro M Pad pad" "Button" "9" "button 5"

Looking in I see no events at all when pressing the appropriate button, yet it works fine with keyboard mappings of all sorts.

This is odd to me because the stylus works just fine with its various mouse button mappings.

I am using Budgie but I know a large portion of it is built on Gnome. But it maintains its own forks, so it may be possible to get a fix in at least to disable it if nothing else.

Do you have any inkling as to what is causing the trouble?

[Joshua-Dickens]

I was able to replicate the issue and compared it to issue 289 you linked and this seems like the same issue in that it's conflicting with whatever Gnome code still exists in Budgie.

As listed on this wiki page there is a command which could potentially fix the compatibility issue. I'm unsure what version of Gnome Budgie is currently based off of but if it does use older versions then the compatibility fix in that article might work if the command works the same in Budgie.

[acook]

I wasn't able to get it working with the workarounds. They're about to do a harder fork of the Budgie backend away from Gnome, so maybe after that happens we'll be able to make better progress on this.

[hansemro]

A similar issue is present in GTK4 applications (gtk4-demo, Rnote) where they fail to respond to mouse scroll button events from the wacom pad under KDE6 X11 environment.

From my debugging sessions, I found that discrete scroll events translated from XI_ButtonPress events were created with the source/physical/slave device (source_device) rather than the logical/virtual/master device (device). GTK's chapter on input and event handling (https://docs.gtk.org/gtk4/input-handling.html) describes that GTK widgets (via EventControllers) generally handle events from logical devices rather than from physical devices. (Looking at GTK4's X11-XI2 backend, we can confirm that only logical/master devices are handled: https://gitlab.gnome.org/GNOME/gtk/-/blob/06e905f87d3f2f0eef07db61a012e7ee065fd64b/gdk/x11/gdkdevicemanager-xi2.c#L2135)

With my current findings, I was able to make the gtk4-demo application respond to scroll button events from the pad by changing source_device to device in https://gitlab.gnome.org/GNOME/gtk/-/blob/06e905f87d3f2f0eef07db61a012e7ee065fd64b/gdk/x11/gdkdevicemanager-xi2.c#L1655.

It may be worth mentioning that the pad also lacks any scroll valuators, but I am not really sure yet how that factors in everything here.

Looking to investigate more before I post an issue on GTK's issue tracker.

@acook As a non-budgie desktop user, could you tell me your testing methodology? I'd like to investigate this as well.

[acook]

@hansemro It's been about 6 months since my initial testing and I'm afraid my mental cache has been cleared since then. All I can say is that I was using xsetwacom to change settings as specified in the original post and then looking for results when using the tablet's wheel.

Budgie currently still uses the Gnome stack for everything, so whatever you have been able to test should be identical.

For example, the "Budgie Control Center" appears to just be a reskinned version of the Gnome Control Center:

[hansemro]

From testing both GNOME (Xorg) and Budgie Desktop, I was able to replicate the issue you describe and see that it affects all apps globally (not just GTK4 apps). As #289 describes, the mouse button binding issue is not present to the same extent in KDE (or most non-GNOME-based environments).

With that said, I tested Mutter (X11) window manager in isolation and was able to replicate the issue in non-GTK4 apps. Both GTK4 and Mutter seem to share similar X11 backend code (in terms of input event handling), but there seems to be enough differences that the fix in my previous post does not apply to Mutter directly.

Budgie's window manager (Magpie) is also based off Mutter/Clutter, so this is where I will need to spend more time debugging.

Testing Mutter with X11 backend in isolation

Didn't see too much on mutter X11 backend testing, so here is what I came up with:

1. Create ~/mutter_xinitrc:

#!/usr/bin/env bash

# Enable debug messages from mutter
export G_MESSAGES_DEBUG=all
#export MUTTER_DEBUG=all

# Start mutter with xterm with output logged. Closing xterm will end the X session.
exec mutter --replace xterm > ~/mutter.log 2> ~/mutter.err

2. Optionally create script (~/mutter_x11.sh) to open and switch to virtual terminal 8 and run startx:

#! /usr/bin/env bash

# startx on virtual terminal 8 (from another terminal)
# Note: Using vts earlier than 8 may not work (as they are handled by getty)
#       Reference: see Note under section on "X11 autologin with systemd" in
#       https://wiki.gentoo.org/wiki/X_without_Display_Manager
# Source: https://unix.stackexchange.com/a/554603
systemd-run \
    --property PAMName=login \
    --property User="$USER" \
    --property StandardInput=tty \
    --property TTYPath=/dev/tty8 \
    sh -c 'chvt 8 && exec startx ~/mutter_xinitrc'

3. Make scripts executable:

$ chmod +x ~/mutter_xinitrc ~/mutter_x11.sh

4. Start mutter:

• ... in current virtual terminal with user logged in:

$ startx ~/mutter_xinitrc

• ... in virtual terminal 8 from remote/different terminal:

$ ~/mutter_x11.sh

5. Interact in isolated mutter session (with pad device) and check mutter log files.

[acook]

Ah that's right, Mutter is the WM reported by FastFetch on my machine too, I noticed that a while back but hadn't put any thought into it. Good catch!

[Pinglinux]

This issue is beyond X driver's scope. When using xsetwacom, we assume no other configuration tools are used. Otherwise, both tools will compete with each other, which would confuse the system and end users.

[acook]

Are you suggesting that xsetwacom only supports non-GTK non-KDE desktop environments?

[whot]

Are you suggesting that xsetwacom only supports non-GTK non-KDE desktop environments?

xsetwacom doesn't "support" anything. It writes values to the X driver properties and exits. If some other X client writes to the same X driver properties whoever writes last wins.