x52d reverse scroll wheel direction

[VorpalBlade]

Is your feature request related to a problem? Please describe.

The scroll wheel on the X52 Pro is mounted on the backside of the throttle. When using x52d pulling my finger back (as I would on a normal mouse wheel to scroll down) for some reason scrolls up, and vice versa.

I cannot see an option in x52d to reverse the scroll direction.

Describe the solution you'd like
An option in the config file to select scrolling direction.

Describe alternatives you've considered
I tried changing the scrolling direction in KDE settings, but that only affects my real mouse, not the X52.

Additional context
Add any other context or screenshots about the feature request here.

[VorpalBlade]

Another note related to the scroll wheel: It scrolls way too many lines at a time. It would be nice if that could also be configured. When I test it in a browser (Firefox) it seems to scroll almost a full screen at a time.

[nirenjan]

It shouldn't be too hard to add a reverse scroll option, but the scroll speed issue is bugging me. The virtual mouse only sends a scroll value of 1 or -1, I don't know if there's something else in the desktop input libraries or the kernel that's translating it into a super large jump.

[VorpalBlade]

The scroll step seems to be application dependant, but is larger than my normal mouse always:

• In vscode the X52 seems to make a large jump (8 lines at a time), while my normal mouse (Logitech MX Vertical) only jumps 3 lines at a time.
• In Firefox the X52 makes large steps (somewhere between half a screen and a full screen). My MX Vertical seem to need around 8 clicks to scroll a full screen. However with the X52 in Firefox the scroll speed also seems erratic when scrolling at a high speed. It is not reproducible when scrolling slowly. Missed steps/events?
• I checked using xev, and a single scroll on my mouse results in a single matching pair of ButtonPress/ButtonRelease events. A single step on the X52 scroll wheel results 4 matching pairs.

I don't know how to debug this further, but if you can suggest some commands to run I'm willing to try.

DE: KDE
Distro: Arch Linux

[nirenjan]

That is extremely weird. Can you run x52evtest and check what the output is when you scroll? You should get a single pair of events for each scroll.

[VorpalBlade]

I do indeed get a single pair of events for each scroll in x52evtest.

[nirenjan]

I don't see any problem with a test program on Ubuntu 22.04 with Wayland. I don't think I can be of much help here, since I'm not familiar with how the input subsystem works.

Can you try with the following test program and let me know if you see the same kind of behavior?

#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include "libevdev/libevdev.h"
#include "libevdev/libevdev-uinput.h"

int main()
{
    int rc;
    struct libevdev *dev;
    struct libevdev_uinput *mouse_uidev;

    /* Create a new mouse device */
    dev = libevdev_new();
    libevdev_set_name(dev, "Test virtual mouse");
    libevdev_enable_event_type(dev, EV_REL);
    libevdev_enable_event_code(dev, EV_REL, REL_X, NULL);
    libevdev_enable_event_code(dev, EV_REL, REL_Y, NULL);
    libevdev_enable_event_code(dev, EV_REL, REL_WHEEL, NULL);
    libevdev_enable_event_type(dev, EV_KEY);
    libevdev_enable_event_code(dev, EV_KEY, BTN_LEFT, NULL);
    libevdev_enable_event_code(dev, EV_KEY, BTN_RIGHT, NULL);

    rc = libevdev_uinput_create_from_device(dev, LIBEVDEV_UINPUT_OPEN_MANAGED,
                                            &mouse_uidev);
    if (rc != 0) {
        fprintf(stderr, "Error %d creating virtual mouse: %s\n", -rc,
                strerror(-rc));
        return rc;
    }

    for (int i = 0; i < 10; i++) {
        sleep(1);
        printf("Writing scroll down event %d\n", i);
        rc = libevdev_uinput_write_event(mouse_uidev, EV_REL, REL_WHEEL, -1);
        if (rc != 0) {
            fprintf(stderr, "Error %d writing wheel event: %s\n", -rc,
                    strerror(-rc));
        }
        rc = libevdev_uinput_write_event(mouse_uidev, EV_SYN, SYN_REPORT, 0);
        if (rc != 0) {
            fprintf(stderr, "Error %d writing sync event: %s\n", -rc,
                    strerror(-rc));
        }
    }

    libevdev_uinput_destroy(mouse_uidev);
    libevdev_free(dev);

    return 0;
}

Build it with gcc -o mouse-scroll-test mouse.c $(pkg-config --cflags --libs libevdev)

[VorpalBlade]

First: I'm on X11. That may indeed make a difference if you are on Wayland ("!/#% nvidia).

Ignore this, realise this was irrelevant.

Second, whatever I do (even if I don't scroll) it just prints the following, one line every second or so:

$ ./mouse-scroll-test 
Writing scroll down event 0
Writing scroll down event 1
Writing scroll down event 2
Writing scroll down event 3
Writing scroll down event 4
Writing scroll down event 5
Writing scroll down event 6
Writing scroll down event 7
Writing scroll down event 8
Writing scroll down event 9

Scrolling with either the X52 or my mouse does not affect the output in any way.

EDIT: Ah, now I realise this is supposed to generate scroll events.

EDIT2: It seems to be small steps in Firefox. They are still much smaller than the steps from x52d (not sure if it is the same size as my mouse though)! In xev it is one pair of events per printed line.

[nirenjan]

Aha! I think I figured out why you are seeing this issue - the wheel event is sent anytime there is a new report read from the hardware. From your comment in #44, it seems like there is some hardware issue that is causing noise when you are reporting a change due to the your twist axis. The report_wheel method in x52d simply checks what the current value is, and not what the previous value is. So, you are possibly receiving multiple reports when the wheel is getting updated. I'll push a fix for this shortly.

[VorpalBlade]

That is very possible. The noise in question is very high frequency, flickering many times per second.

[nirenjan]

Can you give the code in the reverse-scroll branch a try? This should fix both your enhancement request for reversed scroll direction and the multiple scroll events issue.

[VorpalBlade]

Unfortunately it doesn't seem to work quite right. It scrolls one step in either direction then there are no further events at all until I reverse direction of the scrolling.

EDIT: No further scroll events that is.

[nirenjan]

Dang, I thought that would fix it. Can you capture some event logs from your joystick using evemu-record? I can use those logs to replay the exact events sent from your joystick on my computer, and then it might be easier to spot the problem.

This should be in the evemu-tools package. Please follow the instructions on the manpage.

[VorpalBlade]

On Arch Linux it is apparently in the "evemu" package. Unfortunately I have issues getting this to work (maybe?):

$ evemu-record /dev/input/js0 scrolling.log
error: this device is grabbed and I cannot record events
see the evemu-record man page for more information
$ man evemu-record
<read>
$ fuser -v /dev/input/js0
$

So I don't know what is grabbing it.

However I found that /dev/input/event22 also seemed to be associated with the joystick and it worked there. Log file attached. I scroll a bit in each direction: scrolling.log

[nirenjan]

I've pushed another commit, which may fix the single event issue. Unfortunately, I don't have access to my joystick right now, so I can't test it myself. Please let me know if this works.

[VorpalBlade]

Unfortunately there was no change in behaviour with the latest patch

[nirenjan]

OK, I'll have to look into this later. Did you get a chance to play with the ReverseScroll option in the config? You can roll back to 819d38f - that commit has only the ReverseScroll related changes, and none of my hacky attempts to fix the spurious scroll events.

[VorpalBlade]

I did not get around to testing that. I will check it out and report back.

[VorpalBlade]

Sorry it took a few days to get around to testing this. Yes the reverse scroll commit works.

[nirenjan]

@VorpalBlade, thanks for the confirmation. I've merged the reverse scroll commit to master.

I'll close this issue, and track the multiple reports bug in #46