GNOME Bugzilla – Bug 708241
Pointer speed is set to slowest first time you enter Mouse & Touchpad
Last modified: 2013-09-27 14:21:45 UTC
Default is reset to slowest first time you enter Mouse & Touchpad.
Created attachment 255116 [details] [review] do not reset mouse speed Acceleration and threshold is set to -1 by default. When you enter mouse panel it tries to set -1 to the mouse speed scale, however it isn't possible, so 0 is set and propagate back. Attached patch do same thing as for the touchpad speed. The speed is set before change signal is connected. But I'm not sure if it is best solution. Speed scale show slowest speed, however speed is unset and can be random. So user may want slow it down, but he can see it minimal which is wrong. He have to move with slider from minimum and back to change it from unset to the slowest... Another possible solution is set acceleration and threshold to same valid values by default, but it can be also problematic.
This bug is also in GNOME 3.9.91, so make sure you apply accordingly.
Review of attachment 255116 [details] [review]: This is a patch that I would take for stable branches but, tbh, I don't like the logic handling these settings in the first place. We have the adjustment value being processed and saved into two different settings but then we also have bidirectional binding from just one of those settings into the adjustment. I think the binding should be removed and we should have a reverse mapping from both settings into the adjustment. We should also handle the default -1 values specially, probably by querying the X server directly in that case to get the real values being used and use that to update the adjustment value.
(In reply to comment #3) > Review of attachment 255116 [details] [review]: > We have the adjustment value being processed and saved into two different > settings but then we also have bidirectional binding from just one of those > settings into the adjustment. I think the binding should be removed and we > should have a reverse mapping from both settings into the adjustment. However there is a problem, when acceleration and threshold aren't inverse values as we wanted (the way they are set by speed scale). Another problem is when the value is out of the range (similar to -1). I think there is no simply way to "bind" both values to the scale from this reasons. > We should also handle the default -1 values specially, probably by querying the > X server directly in that case to get the real values being used and use that > to update the adjustment value. We can't simply get current acceleration value, we have to calculate it from numerator and denominator values, which is done in g-s-d in reverse direction. It would be good to do that also in the g-s-d from this reason and set the acceleration to concrete value instead of -1. Particularly solution of those problems could be merging acceleration and threshold to one key value in the schema and calculate everything in g-s-d. This will be needed also for Bug 563777 and port to Wayland probably. However we just move some of the listed problems to g-s-d... What do you suggested to be done?
Created attachment 255845 [details] [review] remove innecessary acceleration setting But you are right that we don't need to set acceleration twice.
Review of attachment 255845 [details] [review]: ok
Review of attachment 255116 [details] [review]: Ok, let's push both patches to master and 3.8. The settings will need to be re-evaluated for wayland in any case. Actually for wayland we'll need a pointer acceleration implementation inside mutter-wayland or some shared library with weston which doesn't exist yet AFAICT.
Commited to the both branches. master: commit da911dce3ce8ca4017144b0a869b2051a23285e2 commit 1fc4a0c6b6001e5388361c91844edda41b011538 gnome-3-8: commit f21f6017df17af99059bacb305bb946ecf3cc91c commit 6ef6bfbebf00379a6e43cf7f402ab80de6c6b41d