-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rationalise input configuration options #3432
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3432 +/- ##
==========================================
- Coverage 77.24% 77.23% -0.01%
==========================================
Files 1071 1071
Lines 68467 68483 +16
==========================================
+ Hits 52885 52893 +8
- Misses 15582 15590 +8 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While here, how about a reference page for input configuration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we're missing:
I first want consensus on the naming |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--mouse-scroll-speed-scale arg Scales mice scroll events, use negative
values for natural scrolling
--touchpad-scroll-speed-scale arg Scales touchpad scroll events, use
negative values for natural scrolling
-speed-scale
is a mouthful… -speed
alone? -factor
? Could also use a note on accepted values.
For reference, this is the full current
|
Should we say |
And the corresponding logs:
|
We have scroll scale split into vertical and horizontal in the log (and calling it just |
Why the curly braces? Also, libinput calls this "clickfinger" rather than "finger-count", we probably should stay close to their nomenclature? |
Do you have a preference? I'd go for specifying vspeed and hspeed but... |
disable-while-trackpointing would mean changing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a preference? I'd go for specifying vspeed and hspeed but...
I suppose there could be devices that have different default scroll speeds on the two axes, so we should keep it?
And we could accept a float or a tuple of floats?
src/miral/input_device_config.cpp
Outdated
char const* const mouse_scroll_speed_scale_opt = "mouse-scroll-speed-scale"; | ||
char const* const mouse_vscroll_speed_opt = "mouse-scroll-vspeed"; | ||
char const* const mouse_hscroll_speed_opt = "mouse-scroll-hspeed"; | ||
char const* const touchpad_cursor_acceleration_opt = "touchpad-cursor-acceleration"; | ||
char const* const touchpad_cursor_acceleration_bias_opt = "touchpad-cursor-acceleration-bias"; | ||
char const* const touchpad_scroll_speed_scale_opt = "touchpad-scroll-speed-scale"; | ||
char const* const touchpad_vscroll_speed_opt = "touchpad-vscroll-speed"; | ||
char const* const touchpad_hscroll_speed_opt = "touchpad-hscroll-speed"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no, don't like that… 99% just need the same scale for both h/v, I'd rather stick to a single float, or maybe:
--mouse-scroll-speed {<hvscale>|<hscale>,<vscale>}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe: use --mouse-scroll-speed
for both unless --mouse-horizontal-scroll-speed-override
is also set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then… what if you only need vscroll changed? I suppose my proposal also forced you to give both, but in a more obvious way…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe: use --mouse-scroll-speed
for both unless --mouse-horizontal-scroll-speed-override
and/or --mouse-vertical-scroll-speed-override
is also set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And what if you set both -override
s, but not -speed
? XD
My vote is on the above, but maybe with "x" as separator.
--mouse-scroll-speed {<hvscale>|<hscale>x<vscale>}
# e.g.
--mouse-scroll-speed 1.2
--mouse-scroll-speed -2
--mouse-scroll-speed 1x-1
--mouse-scroll-speed -1.2x2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"But then… what if you only need vscroll changed?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still nicer IMO than the -vertical-override
option…
--mouse-scroll-speed 1x2
# or, but I don't think so, certainly not with `x` as separator
--mouse-scroll-speed x2
--mouse-scroll-speed 2x
Actually, there's one thing that needs consideration - in theory devices could have different defaults? So it may be important to have a way to only specify one axis? Or will the default always be 1.0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default is always 1F, it isn't something libinput implements
This is how things look now:
|
83f8650
to
102c89f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are a couple of options that could be improved with the grammatical suggestions, and a couple of other things, but in the broad strokes this option scheme looks sensible to me.
This is how these options now look:
|
Let's tidy up before we release 2.18 with them