[enhancement] Add mouse sensitivity setting

[Alphare]

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.

[progandy]

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.

[Alphare]

@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.

[L-as]

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.

[artizirk]

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

[jparsert]

Is there a way now to change the mouse sensitivity in sway?

[luzidd]

I'm also interested if this is planned.

[zerfix]

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

[JSquar]

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?

[cauebs]

The workaround proposed is not enough, because some may want to keep the adaptive behaviour and still alter the overall pointer speed factor.

[luzidd]

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)

[distek]

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
}

[falkecarlsen]

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
}

[ivankovnatsky]

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.

[kaiserschmarrn0]

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?

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.

[robintown]

@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.

[falkecarlsen]

@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.

[goodboy]

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.

[kaiserschmarrn0]

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

[Zeioth]

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
}

[koxu1996]

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.

[virus-found]

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?

[koxu1996]

@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]

@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.

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.

[WhyNotHugo]

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?

[maximbaz]

@WhyNotHugo have you tried accel_profile adaptive together with pointer_accel?

[WhyNotHugo]

@maximbaz That makes the touchpad have an acceleration, but I'm trying to increase it's [continuous] speed, not acceleration.

[Penguin-Guru]

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.

[koxu1996]

@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.:

[tkkcc]

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
}

[davawen]

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?

[zerfix]

@davawen I use flat profile with -0.665 pointer_accel and it works perfectly for my high dpi mouse. Are you sure that you have set the correct input device? Have you tried setting sensitivity globally instead of per device? Have you tried using negative value?

My config:

input type:touchpad {
    accel_profile flat
    pointer_accel -0.2
}
input type:pointer {
    accel_profile flat
    pointer_accel -0.665
}

[davawen]

Are you sure that you have set the correct input device?

Thank you!!
I ran swaymsg -t get_inputs and assumed I needed to use type:mouse. I just realized people used type:pointer in their examples. Setting pointer acceleration now works :heart:.

[mangkoran]

Apologize but any updates/timeline for this feature? I saw https://github.com/swaywm/sway/pull/6129 but it's been a while since it's last update.

[WhyNotHugo]

This was requested long ago on the libinput side (see https://gitlab.freedesktop.org/libinput/libinput/-/issues/187), but it doesn't seem like anything is happening on that front.

From what I can tell, the only viable recommendation (if you need sensitivity higher than pointer_accel 1) is to edit udev rules and fiddle with MOUSE_DPI.

[emersion]

To me I'd make more sense to remove the libinput limitation of [-1, 1]...

[tropical32]

There is something called custom acceleration profile in libinput and it's been available for quite some time.

The custom pointer acceleration profile gives users full control over the acceleration behavior at different speeds.

Currently, this is hidden behind an #if directive. Is there a good reason why? https://github.com/swaywm/sway/blob/v1.9/sway/ipc-json.c#L938

[xeruf]

I am very confused by the parameters accel profile and pointer accel by libinput. Does pointer_accel now work with flatas the documentation states or switch back as some people here say? Why is the multiplier not a multiplier, where values below one reduce speed, values above one increase it and negative values invert it? This -1 to 1 is very very odd.

Why do libinput and sway report different profiles?

❯ swaymsg -t get_inputs | grep -A9 Ploopy
    "identifier": "20547:23622:Ploopy_Corporation_Thumb_Trackball_Consumer_Control",
    "name": "Ploopy Corporation Thumb Trackball Consumer Control",
    "vendor": 20547,
    "product": 23622,
    "type": "pointer",
    "scroll_factor": 1.0,
    "libinput": {
      "send_events": "enabled",
      "natural_scroll": "disabled"
    }
  },
--
    "identifier": "20547:23622:Ploopy_Corporation_Thumb_Trackball_Consumer_Control",
    "name": "Ploopy Corporation Thumb Trackball Consumer Control",
    "vendor": 20547,
    "product": 23622,
    "type": "keyboard",
    "repeat_delay": 600,
    "repeat_rate": 25,
    "xkb_layout_names": [
      "EurKEY (US)",
      "German (no dead keys)",
      "English (US, euro on 5)"
--
    "identifier": "20547:23622:Ploopy_Corporation_Thumb_Trackball_System_Control",
    "name": "Ploopy Corporation Thumb Trackball System Control",
    "vendor": 20547,
    "product": 23622,
    "type": "keyboard",
    "repeat_delay": 600,
    "repeat_rate": 25,
    "xkb_layout_names": [
      "EurKEY (US)",
      "German (no dead keys)",
      "English (US, euro on 5)"
--
    "identifier": "20547:23622:Ploopy_Corporation_Thumb_Trackball_Mouse",
    "name": "Ploopy Corporation Thumb Trackball Mouse",
    "vendor": 20547,
    "product": 23622,
    "type": "pointer",
    "scroll_factor": 1.0,
    "libinput": {
      "send_events": "enabled",
      "accel_speed": -0.20000000298023224,
      "accel_profile": "flat",
      "natural_scroll": "disabled",
--
    "identifier": "20547:23622:Ploopy_Corporation_Thumb_Trackball",
    "name": "Ploopy Corporation Thumb Trackball",
    "vendor": 20547,
    "product": 23622,
    "type": "keyboard",
    "repeat_delay": 600,
    "repeat_rate": 25,
    "xkb_layout_names": [
      "EurKEY (US)",
      "German (no dead keys)",
      "English (US, euro on 5)"
❯ sudo libinput list-devices | grep -A18 Ploopy
Device:           Ploopy Corporation Thumb Trackball
Kernel:           /dev/input/event20
Group:            6
Seat:             seat0, default
Capabilities:     keyboard 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   n/a
Rotation:         0.0

Device:           Ploopy Corporation Thumb Trackball Mouse
Kernel:           /dev/input/event21
Group:            6
Seat:             seat0, default
Capabilities:     pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   button
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   flat *adaptive custom
Rotation:         0.0
[...]

[MithicSpirit]

I am very confused by the parameters accel profile and pointer accel by libinput. Does pointer_accel now work with flatas the documentation states or switch back as some people here say?

From my testing, it works fine with the flat acceleration profile.

Why is the multiplier not a multiplier, where values below one reduce speed, values above one increase it and negative values invert it? This -1 to 1 is very very odd.

That comes from upstream. For example, for the flat profile, this is how the accel_speed is treated.

static bool
accelerator_set_speed_flat(struct motion_filter *filter,
               double speed_adjustment)
{
    struct pointer_accelerator_flat *accel_filter =
        (struct pointer_accelerator_flat *)filter;

    assert(speed_adjustment >= -1.0 && speed_adjustment <= 1.0);

    /* Speed range is 0-200% of the nominal speed, with 0 mapping to the
     * nominal speed. Anything above 200 is pointless, we're already
     * skipping over ever second pixel at 200% speed.
     */

    accel_filter->factor = max(0.005, 1 + speed_adjustment);
    filter->speed_adjustment = speed_adjustment;

    return true;
}

My guess is that other accelerators don't treat this the same (I'm too lazy to check, but feel free to do so), and might be nonlinear, so they went with the -1 to 1 value to make it not seem as though it should be linear. Maybe there should be a separate option to apply a linear scaling, but ig that's what the calibration matrix is for. Either way, the issue seems to be upstream.