Is there a secret documentation file.

[infodungeon]

Trying to figure out how to set the scrolling speed but can't find the fm. The config example doesn't provide any configuration examples for either scroll wheel. Trolling through Issues logs I see people semi-randomly trying things in the hirescroll section a couple of years ago. Any pointers to working examples or documentation appreciated.... Trying to get my MX Master 3 working nicely in linux and it's "almost" there.

[kth8]

I uploaded all the source code of this program to my AI and it responded with:

LogiOps doesn't have a simple, direct configuration option like vertical_scroll_speed or scroll_multiplier within the main hiresscroll block to universally adjust the speed of standard (non-inverted) vertical scrolling.

Here's the breakdown:

Standard Scrolling Handling: When you configure hiresscroll like this:

hiresscroll:
{
    hires: true;    // Or false
    invert: false;
    target: false;
};


LogiOps primarily tells the device whether to send high-resolution scroll events or not, and whether to invert the direction signal at the hardware level. The actual interpretation of these scroll events (how many lines/pixels to scroll per event) is typically handled by the Linux kernel's input system (like libinput) and your desktop environment (GNOME, KDE, etc.). LogiOps doesn't intercept and modify the magnitude of these standard scroll events in this basic configuration.

Workaround using Axis Remapping: You can achieve a similar effect, but it requires fully diverting the scroll wheel events and remapping them using AxisGesture, which might bypass some native kernel/desktop environment scroll acceleration or feel slightly different:

hiresscroll:
{
    hires: true;    // Keep hires enabled if desired
    invert: false;
    target: false;  // Usually false

    // Divert UP scroll and remap with a multiplier
    up: {
        mode: "Axis";
        axis: "REL_WHEEL";      // Target the standard vertical wheel relative axis
        // Adjust this multiplier:
        // > 1.0 increases speed (e.g., 1.5 = 50% faster)
        // < 1.0 decreases speed (e.g., 0.7 = 30% slower)
        axis_multiplier: 1.5;
    };

    // Divert DOWN scroll and remap with the same multiplier (negative for down)
    down: {
        mode: "Axis";
        axis: "REL_WHEEL";
        axis_multiplier: -1.5; // Use the negative of the multiplier above
    };
};

Explanation of the Workaround:

By defining up and down gestures within the hiresscroll block, you tell LogiOps to capture those scroll events instead of letting the kernel handle them directly.

mode: "Axis" tells LogiOps to treat the scroll input as movement along a relative axis.

axis: "REL_WHEEL" specifies the standard vertical scroll axis recognized by the kernel.

axis_multiplier: is the key. You set a factor here to scale the scroll events. A value of 1.0 would be the default speed (relative to the hires setting). Increase it for faster scrolling, decrease it (towards 0.0) for slower scrolling. You need to apply the same magnitude multiplier (but opposite sign) to both up and down.

Caveats of the Workaround:

Feel: This might feel different from the native scrolling, potentially lacking the smooth acceleration curves provided by libinput or your desktop environment.

Compatibility: Ensure REL_WHEEL is the correct axis code on your system (it usually is).

Complexity: It's less straightforward than a simple speed slider.

In summary, while there's no direct speed setting for standard scrolling, you can use the AxisGesture remapping within the hiresscroll block as a workaround to control the effective scroll speed handled by LogiOps.

[infodungeon]

Thanks very much for this answer. Sounds like a needed feature if there is anyone still supporting this application.

[infodungeon]

Sounds like something like input remapper need to intercept the mouse scroll wheel events before libinput and scale them down for a global solution. .... Gemini 2.5 Pro ...

Okay, finding readily available, user-friendly "hooks" to globally control the speed and acceleration of native high-resolution scrolling across all applications in Linux is currently very limited and challenging. Here's a breakdown of potential intervention points, why they often don't work as simple hooks for this specific task, and what the closest possibilities are: Application-Specific Settings (Most Practical Hook): How it works: Individual applications interpret the high-resolution scroll data from the toolkit (GTK/Qt). Some applications expose settings to modify this interpretation. Example: Firefox's about:config settings like mousewheel.default.pixel_delta_multiplier_y can directly scale the pixel scroll amount derived from high-res events. Limitation: This is the most common place you'll find control, but it's not a system-wide hook. You need to configure each supporting application individually. Many applications offer no such control and rely entirely on the toolkit defaults. Toolkit Level (GTK/Qt - Mostly Implicit/Developer Hooks): How it works: GTK (used by XFCE) and Qt receive the fine-grained scroll events from libinput (via the display server). They contain the logic that translates these events into actual scrolling motion, potentially applying acceleration curves. Hooks?: There are generally no user-facing GSettings keys or environment variables provided by GTK or Qt specifically designed for users to globally tweak high-res scroll speed multipliers or acceleration curves. Developer Control: Application developers using GTK/Qt can access the detailed scroll event data (delta values) and implement their own scaling or physics, but this is within their app code, not a system hook. Potential (Advanced): Theoretically, one could patch GTK/Qt libraries, but this is highly invasive and not a simple "hook." libinput Level (No Direct Hooks for This): How it works: libinput processes raw kernel events and provides standardized events to the display server/toolkits. It detects high-res capabilities. Hooks?: libinput itself does not offer configuration options (via udev attributes or local-overrides.quirks) to apply arbitrary speed multipliers or acceleration curves to native high-resolution scroll events. Its focus is on reliable detection and passing data through. Properties like libinput Scrolling Pixel Distance relate to emulating pixel scrolling from discrete events, not scaling native high-res data. Display Server Level (Xorg/Wayland Compositor - Generally No Hooks): How it works: Receives events from libinput and passes them to the toolkits/applications. Hooks?: Xorg: Tools like imwheel work by intercepting discrete Button 4/5 events and re-issuing multiples. They are not designed to understand or modify the fine-grained relative axis events used by native high-resolution scrolling. xinput properties also lack controls for this. Wayland: The compositor could potentially intercept and modify events, but currently, major compositors (Mutter, KWin, wlroots-based) do not expose user settings for tuning high-res scroll speed/acceleration curves globally. Low-Level Event Interception Tools (Advanced/Experimental Hooks): How it works: Tools like input-remapper or potentially custom scripts using python-evdev or similar libraries can grab raw /dev/input/eventX devices. Hooks?: Theoretically, such a tool could: Grab the mouse device exclusively. Listen for the high-resolution scroll events (e.g., REL_WHEEL_HI_RES, REL_HWHEEL_HI_RES). Apply custom scaling logic (speed) and acceleration curves based on event frequency/magnitude. Re-inject modified events into the system using the uinput kernel module (creating a virtual device). Challenges: This is complex. You need to correctly identify high-res events, implement the scaling/acceleration logic smoothly, handle different axes, and ensure compatibility without introducing lag or glitches. input-remapper's GUI might not directly support quantitative scaling of relative events easily; you might need scripting. This is far from a simple configuration tweak. Conclusion: There are no standard, built-in, user-friendly system-wide hooks in a typical Linux setup (Arch/XFCE included) to specifically adjust the speed and acceleration of native high-resolution scrolling.