You are not logged in.
A few months ago, I got a new PC, which came with an ASUS gaming mouse. The pointer moves very quickly. I got used to it, but my son always complains about it.
So, I decided to see what I could do about it. First, I tried using /etc/X11/xorg.conf.d/50-mouse-acceleration.conf using numerator 1 and denominator 2, and restarting X. It made no difference that I could tell.
Now, I'm trying to use xset. The settings are taking effect (according to "xset q"), but they also have no discernable effect. Here is the current output:
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000000
XKB indicators:
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
03: Compose: off 04: Kana: off 05: Sleep: off
06: Suspend: off 07: Mute: off 08: Misc: off
09: Mail: off 10: Charging: off 11: Shift Lock: off
12: Group 2: off 13: Mouse Keys: off
auto repeat delay: 660 repeat rate: 25
auto repeating keys: 00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent: 50 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 1/8 threshold: 6
Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 600 cycle: 600
Colors:
default colormap: 0x20 BlackPixel: 0x0 WhitePixel: 0xffffff
Font Path:
/usr/share/fonts/100dpi,/usr/share/fonts/75dpi,built-ins
DPMS (Energy Star):
Standby: 600 Suspend: 600 Off: 600
DPMS is Enabled
Monitor is OnI am running Xorg 1.20.9-2 and xorg-xset 1.2.4-2. I have fully updated Arch Linux amd64 and nvidia driver 455.38-3
Last edited by ratcheer (2020-11-07 14:37:51)
Offline
xset does not have an effect because you are using libinput.
With this information have another look at https://wiki.archlinux.org/index.php/Mouse_acceleration.
Offline
In the X.org X Server 1.6 and above, the behaviour described so far is linked to the default profile. There are other profiles (i.e. functions determining pointer acceleration from device velocity) and additional settings, so the above description may not apply to non-default cases. In the X.org Server 1.7, these are available as input device properties (see xinput).
The setting should certainly apply to the default config, but is for sure clamped to "sane" values (try an acceleration of 1000 …) - idk. whether that applies to values < 1, but the default algo wold quickly stall the pointer and the "natural" (threshold = 0) one causes weird warping here.
You can try a postive factor (xset m 3 6) to see whether the value takes effect on your config.
However, I'd focus on the particula model of "gaming moufse™" - these things typically offer a variable DPI that can be controlled by either SW or a HW switch or both.
Lowering the input DPI will get you much better results than maipulating the acceleration (which has no impact on small motions anyway - where you typically want to be the most precise)
eg.
https://wiki.archlinux.org/index.php/Razer_peripherals
https://aur.archlinux.org/packages/lomoco/
Offline
Thanks, Seth. I will look into all of that, tomorrow morning.
Offline
If there's no way to impact the HW DPI, you can try the flat acceleration profile in xinput w/ an acceleration factor of 0.3 (which according to https://wayland.freedesktop.org/libinpu … ation.html is the slowest supported value)
As very last resort you might try to lower the mouse polling rate, https://wiki.archlinux.org/index.php/Mouse_polling_rate
Offline
Ok, it does appear that xinput is what is in play. Thanks, Gosi.
I have arrived at this, and it does seem to be better. I'm not sure, though. It seems to give more precise slow movement, but a flick will still instantly move the pointer all the way across the screen. I'm marking the thread Solved.
[tim@tux glxinfo]$ xinput list-props 13
Device 'ASUSTek TUF GAMING M3 Mouse':
Device Enabled (153): 1
Coordinate Transformation Matrix (155): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Natural Scrolling Enabled (287): 0
libinput Natural Scrolling Enabled Default (288): 0
libinput Scroll Methods Available (291): 0, 0, 1
libinput Scroll Method Enabled (292): 0, 0, 0
libinput Scroll Method Enabled Default (293): 0, 0, 0
libinput Button Scrolling Button (294): 2
libinput Button Scrolling Button Default (295): 2
libinput Button Scrolling Button Lock Enabled (296): 0
libinput Button Scrolling Button Lock Enabled Default (297): 0
libinput Middle Emulation Enabled (298): 0
libinput Middle Emulation Enabled Default (299): 0
libinput Accel Speed (300): 0.300000
libinput Accel Speed Default (301): 0.000000
libinput Accel Profiles Available (302): 1, 1
libinput Accel Profile Enabled (303): 1, 0
libinput Accel Profile Enabled Default (304): 1, 0
libinput Left Handed Enabled (305): 0
libinput Left Handed Enabled Default (306): 0
libinput Send Events Modes Available (272): 1, 0
libinput Send Events Mode Enabled (273): 0, 0
libinput Send Events Mode Enabled Default (274): 0, 0
Device Node (275): "/dev/input/event7"
Device Product ID (276): 2821, 6416
libinput Drag Lock Buttons (289): <no items>
libinput Horizontal Scroll Enabled (290): 1Offline
This thing?
https://www.asus.com/id/Keyboards-Mice/TUF-Gaming-M3/
The description read as if the two buttons below the wheel allow you to adjust the resolution?
Offline
Yes, that's it. Apparently, the buttons change the DPI (horizontal and vertical). I have been working on the acceleration factor. 0.3 is the lowest, and I think I'm ok with it.
Offline