I have a trackball and it takes me 4 strokes of my thumb to go from one side of the screen to the other even though the speed setting is at max. I added xset m 200 1 to my startup apps, but recently it stopped auto-starting. I have to manually enter this command in Terminal Is the a way to set this speed without this workaround?
Thank you for the help
Best Answer
Not a "Is there a way to set this speed without this workaround?" – answer. But perhaps some help. You might found a solution by @RickGreen-Turbo 's comment-link, but add some.
To identify mouse use:
In your case it might be something like
Logitech USB Trackball
.To list current settings say:
xinput --list-props [<id_number> | "String Identifier"]
E.g. (in my case):
Not sure about this, but my guess is, that id could change between boots. As stated here:
So in a script, when modifying, use the string variant. (Perhaps this is what is wrong with your old configuration?)
It yields (for me):
Find the values you want to change and add them to start-up script.
For testing e.g.:
The (related) properties:
are documented here. (Look around the same page for more information if you want.)
Add hack that works for your mouse in a file and save it to e.g.
~/.bin/my_mouse_hack
e.g:
Make it executable:
Now: To set this to run at start-up. Add this to
.bash_profile
as stated here. (I'm in the middle of a load of work, coding, compiling etc. so I won't test this now. But I'll do later and update answer.)Or add it to by choosing "Add" in (If you use GNOME):
Alt+F2
gnome-session-properties
Enter.Or by X11 config or similar.
EDIT 1: suspend quirk
See you have some problems with resume after suspend.
When the computer goes into or resumes suspend/hibernate mode it runs scripts located in
/etc/pm/sleep.d
and/usr/lib/pm-utils/sleep.d
. man pm-action.When going down scripts are run with argument
suspend
orhibernate
, when resuming the argument isresume
andthaw
respectively – that is: in your script $1 is either of the four.Scripts, aka
"hooks"
, in these directories are, AFAIK, categorized in two blocks.Also; if you want to disable a script that reside in
/usr/lib/pm-utils/sleep.d
create an empty file in/etc/pm/sleep.d
with the same name and don't make it executable.A last file to mention is
/var/log/pm-suspend.log
. This file has information about last suspend/hibernate and resume/thaw – and by convention is a good place to add your own logging. It also is a good place to look for errors. If a script fails, it should be logged here.A simple script
01_test
:Then
Suspend and wake up, cat log and see:
OK. That works. Now what you want is to set mouse by
xset
etc. It would be tempting to believe that a simple line likeIn a script in
/etc/pm/sleep.d
would suffice, but if you try (no harm by trying), you'll see some error in the log file. There is at least two issues. 1:xset
require adisplay
2: root most likely does not have an Xsession.To resolve this one could specify a user environment etc. by adding a line like this instead:
but as this is a global script one would presumably do it a bit more complex. This script check for users that are logged in and have an :0 display, check if they have an executable file in
/home/user/bin/
named.resume
that is executable; if so executes it01_user_resume
:So:
/etc/pm/sleep.d/01_user_resume
.sudo chmod 755 /etc/pm/sleep.d/01_user_resume
In your home directory create the file
bin/.resume
- and add e.g. (err see Edit 2 below):Make it executable:
chmod 700 bin/.resume
Or, better, use same script for boot and resume – aka re-run the script you used to set mouse on boot.
Suspend and resume. Check if settings has changed by:
EDIT 2: Mouse move
Testing this it seems like there is yet another problem. The
xset q | grep -A 1 Pointer
command reveals that the settings are changed, problem is that once the mouse is used - it reverts. For me this was fixed by addingsleep 1
beforexset
in the.resume
script. You might want to use a longer sleep time to be sure.Changed so that script was last executed, according to the log file, but this did not help - probably because the scripts seems to be executed in sub-shells - so some process from an earlier script might get executed after last script is executed.