sway
sway copied to clipboard
swaywm
[enhancement] Add mouse sensitivity setting
This is a very similar issue to #3004.
Right now we have the ability to enable and disable mouse acceleration, but no setting for mouse sensitivity. Sensitivity in sway is lower than in my other distros/OSes, and it's been bugging me.
Depending on my schedule I might give it a try this week-end. Considering how similar the code will be to #3004, this should not be very hard to implement, unless there is something I'm overlooking.
Wouldn't that be possible already by setting the "flat" acceleration profile and then setting a factor between -1 and 1? Or the calibration matrix may be another alternative.
@progandy Mhhh, that might be it yeah. This libinput docs paragraph seems to indicate that you can indeed keep a 1:1 ratio and have a factor. Now, whether that factor is wide enough is another question. I'm not on my machine right now, I'll test that later . Moreover, my initial issue with inconsistent default sens (read: DPI settings) might be something in udev unrelated to sway. I'll check back soon, thanks.
I found this.
TL;DR: 0 is the default, -1 is the minimum possible speed, and 1 is the maximum possible speed.
One thing that confuses me is how can there be a maximum and minimum speed? Does libinput perhaps pass this number to the device itself? In any case, it works well enough for me, but higher limits would be nice.
Correct mouse DPI setting in 70-mouse.hwdb file helps quite a lot
- http://who-t.blogspot.com/2014/12/building-a-dpi-database-for-mice.html
- https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
to change sensitivity, add to sway config:
input <your device identifier> {
accel_profile <flat or adaptive>
pointer_accel <between -1.0 and 1.0>
}
as identifier you can use type:pointer, type:touchpad or use swaymsg -t get_inputs to find your input device
For me, pointer_accel 1 is still too slow for me. Therefore I tried to influence the pointer's transformation matrix by setting calibration_matrix 2 0 0 0 2 0. But I didn't notice any difference...is there any solution to this?
The workaround proposed is not enough, because some may want to keep the adaptive behaviour and still alter the overall pointer speed factor.
I have a suggestion for making the configuration syntax for this feature more intuitive.
# this is a little redundant if one would set the sensitivity setting to zero, it might just be easier to have this anyway for convenience'
input <identifier> adaptive true|false
# describes the slope of the sensitivity/raw_pointer_speed curve
# sensitivity would be on the y axis while pointer input speed is on the x axis
# a value of 0 would have the same effect as "adaptive false"
input <identifier> sensitivity [-x..x]
# alternative names could be "adaptive_sensitivity" or "sensitivity_curve/ramp"
# multiplies the distance traveled (per frame) by this factor
# a negative setting would make the cursor move in the opposite direction
input <identifier> speed [-x..x]
Also there is a video that shows a good example of how an acceleration curve could be customized and what the benefits might be: (https://youtu.be/SBXv0xi-wyQ?t=230)
Just a note, and possibly the solution to some of your issues:
Despite swaymsg -t get_inputs printing the identifier with escaped characters like so:
"identifier": "2:10:TPPS\/2_Elan_TrackPoint",
Make sure that when you add it to your configuration, you remove the escapes:
input "2:10:TPPS/2_Elan_TrackPoint" {
accel_profile "flat"
pointer_accel -0.3
}
Also, another note, if you specify the same input device twice ( for example ), the second setting will override the first setting and set it back to default:
input "2:10:TPPS/2_Elan_TrackPoint" accel_profile "flat"
input "2:10:TPPS/2_Elan_TrackPoint" pointer_accel -0.3
This will set accel_profile back to adaptive and then the pointer_accel to -0.3
Forgot to add: So specify multiple settings the way I showed above with:
input [device] {
option val
}
On a T14 trackpoint the 'flat' acceleration profile results in a bounce back when stopping large inputs are given. Is this expected behaviour?
input 2:10:TPPS/2_Elan_TrackPoint {
accel_profile "flat"
pointer_accel 1
}
damn, i didn't thought that i could actually use figures between: -1.0..1:
in nix format:
"5426:120:Razer_Razer_Viper" = {
accel_profile = "flat";
pointer_accel = "-0.5";
};
for me, that worked.
For me,
pointer_accel 1is still too slow for me. Therefore I tried to influence the pointer's transformation matrix by settingcalibration_matrix 2 0 0 0 2 0. But I didn't notice any difference...is there any solution to this?
This was probably happening because you're using a mouse with relative positioning, which the calibration matrix has no effect on.
Idk whether this should be a sway or libinput issue, though. I think it's strange that libinput abstracts dpi to a -1 to 1 scale but doesn't offer any abstraction for adding a multiplier to relative movements.
@cogitantium I am fairly certain that trackpoint drift is normal and inherent to how the pressure sensors calibrate themselves, not a software issue.
From Reddit:
The track point does constantly measure the force applied to it and if it is constant for a certain period the calibration is set to this force. But that means if you apply a constant force in one direction for a longer period, this is now the new normal and if you let go the curser moves in the opposite direction because now the force from your finger is gone. This is reset again after the same amount of time once no force is applied, which then stops the cursor.
@robintown thanks for trying to elaborate but I'm not describing the drift that all trackpoints experience. From zero input, a large input that is abruptly stopped results in a 'bounce-back' where the pointer moves slightly in the opposite direction of the input. See this video for a demo, some of the inputs don't experience this, others do: https://streamable.com/dprx5o.
Interestingly, this behaviour was not present previously, neither with the adaptive profile.
The main issue I've noticed isn't so much that you can't get the acceleration speed (which you can seem to on whatever display is being scaled to with HiDPI, though it still doesn't seem as snappy as in X and it's annoying you can't really increase if it necessary), it's that if you have multi-monitor then the monitor that has more pixels mas a much slower mouse movement and thus is pretty unusable. Seems like you're moving same number of relative pixels instead of same distance on screen..
It's unfortunate, was hoping to make the full switch over from X soon 😿
I'm wondering if the main issue is more tied to a udev mouse config file.
if you have multi-monitor then the monitor that has more pixels mas a much slower mouse movement and thus is pretty unusable. Seems like you're moving same number of relative pixels instead of same distance on screen..
the scale output command fixes this. it also changes the scale of the monitor, which is probably desirable
Sharing my config in case someone may find it useful. Got the id from swaymsg -t get_inputs
input "18003:1:foostan_Corne_Mouse" {
# Flat or adaptative
accel_profile adaptive
# Between -1.0 and 1.0
pointer_accel 0.6
#My old xorg values were → calibration_matrix 8 0 0 0 5 0 0 0 1
calibration_matrix 8 0 0 0 5 0
}
If anyone is interested in disabling mouse acceleration completely:
input type:pointer {
accel_profile flat
pointer_accel 0
}
Beware: you might need to adjust DPI; and feeling might be strange at first, but with with time you get used to it.
If anyone is interested in disabling mouse acceleration completely:
input type:pointer { accel_profile flat pointer_accel 0 }Beware: you might need to adjust DPI; and feeling might be strange at first, but with with time you get used to it.
Thanks. How does one adjust DPI?
@virus-found Gaming mouses sometimes have different levels of DPI adjustable with dedicated software\buttons. If you do not have such mouse and you want to make pointer faster/slower, then just adjust pointer_accel value.
@virus-found Gaming mouses sometimes have different levels of DPI adjustable with dedicated software\buttons. If you do not have such mouse and you want to make pointer faster/slower, then just adjust
pointer_accelvalue.
Many thanks. Did not realize you were talking about hardware adjustment.
In my case, if you are interested, I have only a touchpad, obviously without the adjuster. And my pointer_accel is already at the highest value 1.0 and the cursor is too slow to bear, unfortunately.
The calibration matrix seems to have no effect for touchpads. This has no impact:
input 1739:30383:DELL07E6:00_06CB:76AF_Touchpad calibration_matrix 8 0 0 0 5 0
And I've already maxed its speed:
input type:touchpad accel_profile flat
input 1739:30383:DELL07E6:00_06CB:76AF_Touchpad pointer_accel 1
I guess there's no known workaround?
@WhyNotHugo have you tried accel_profile adaptive together with pointer_accel?
@maximbaz That makes the touchpad have an acceleration, but I'm trying to increase it's [continuous] speed, not acceleration.
This thread is confusing to me. Speed is slightly different from sensitivity but the two are very similar from a practical standpoint. Acceleration is completely different-- it is the function of change in speed over time, distance, and/or such. I want absolutely no acceleration but I do obviously want some speed/sensitivity, since I want to move my cursor.
@Penguin-Guru You are right, acceleration is completely different than pointer speed (and should/could be discussed in a separate issue). However, it is common to adjust them together, e.g.:
My calibration_matrix still not work. It works with xinput set-prop before. calibration_matrix has not effect if accel_profile is flat.
input type:pointer {
calibration_matrix 6 0 0 0 6 0
accel_profile flat
pointer_accel 0.0
}
So, is there any known way or workaround (perhaps at the libinput level) to adjust senstivity for a flat acceleration profile? Tweaking pointer_accel yields almost no change in speed (and I guess it shouldn't, since there is no acceleration). Same thing for calibration_matrix.
Do we know how other DE's do this on wayland?
