Lubuntu18.04: how to save touchpad settings?

wxl · May 21, 2019, 6:12pm

Or create the script as above with the changes I suggested and stick it outside of home, e.g. /usr/bin/tap-to-click.sh and then call /usr/bin/tap-to-click.sh 0 in your $HOME/.profile and /usr/bin/tap-to-click.sh 1 in your other user’s. You can create a shortcut on the Desktop with ln -s /usr/bin/tap-to-click.sh $HOME/Desktop which will allow for toggling. This is more general and universal and it doesn’t use synaptics which, like I said, is deprecated.

lubucub · May 22, 2019, 6:13pm

@[wxl]
Sorry that i will stick to my deprecated solution till next year’s 20.04 LTS, which maybe will offer an on-board fix?

You can create a shortcut on the Desktop with ln -s /usr/bin/tap-to-click.sh $HOME/Desktop which will allow for toggling.

I did put my two scripts as new items into “Menu” > “System Tools”, using alacarte, which offers a sophisticated way of toggling now for both of us.

wxl · May 22, 2019, 6:38pm

Actually, we should have a fix in 19.10.

lubucub · May 24, 2019, 6:14pm

@wxl
With 19.04 I use in my case, and with my touchpad,
xinput set-prop 13 307 1
or
xinput set-prop 13 307 0

wxl · May 24, 2019, 6:16pm

That will work for your specific case, but if anything changes, you might run into trouble. The script seeks to find the id (13) more generally and refers to the setting (307) more generally as well.

lubucub · May 25, 2019, 9:10am

@wxl
You are right, I had to readjust the setting the next day

lubucub · May 25, 2019, 6:55pm

@wxl

xinput set-prop 13 307 1

That will work for your specific case, but if anything changes, you might run into trouble. The script seeks to find the id (13) more generally and refers to the setting (307) more generally as well.

Is there a simple way my system could automatically detect those changes? Please note that I am not a scriptmaster. And I would dearly continue using Lubuntu 19.04 after you had persuaded me to reinstall it.

wxl · May 26, 2019, 5:19am

You can use the script as above. Perhaps a little explanation might help make sense out of it:

Long script explanation (click to expand).

I’ll go through it line by line (except for the comments, i.e. the ones that start with #) so you can understand what’s going on.

#!/bin/bash

This is called the shebang and basically instructs the shell to use this program to run the script. In general, it will come in this format, but I prefer #!/usr/bin/env bash because it’s a bit more portable, but it’s fine as is.

echo 'touchpad.sh: DEBUG: entering'

This and other similar lines merely output the quoted text. The purpose for this is to allow for one to understand where one is in the program execution. This is useful for debugging. Since you are not debugging, you can either leave these out or comment them. I will not comment on similar lines.

MY_TOUCHPAD_ID="$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)"

This assigns a variable, MY_TOUCHPAD_ID with the output of the string of commands inside of the parentheses. This is called command substitution. The pipes (|) take the output of the previous command and feed it into the input of the next command and each of those commands are as such:

xinput list lists all of the input devices
grep -i touchpad does a case insensitive (that’s the -i) search for any instance of the word touchpad in the above and outputs the result
cut -d'=' -f2 print the field (that’s the -f, with the 2 specifying the second field) after = in the above. Our first command has an output that includes only one such delimiter (that’s the -d), the device ID.
cut -d$'\t' -f1 prints the field before a TAB character. Since the first command includes a master/slave description after the ID, we need to remove this to isolate the ID.

if [ "$MY_TOUCHPAD_ID" == "" ]; then

This uses the conditional if-clause to test if the MY_TOUCHPAD_ID variable (by the way, the $ before the variable outputs its value and is called parameter expansion) is empty.

	exit

This exits the program, in the case that the variable is empty, as it means we don’t have a touchpad we can identify, so we shouldn’t go trying to tweak settings on it.

fi

This ends the if-clause.

if [ "$1" == "" ]; then

Another if-clause, but this is checking to see if the first positional parameter or argument to the program is empty. This allows for calling the program in the form touchpad.sh to toggle the state rather than explicitly specifying the state with the 0 or 1 argument (e.g. touchpad.sh 0 turns it off).

	MY_TOUCHPAD_STATE="$(xinput list-props $MY_TOUCHPAD_ID | grep -i "tapping enabled" | cut  -f3)"

This creates a new variable, MY_TOUCHPAD_STATE that lists the properties of of our touchpad (by ID, using the MY_TOUCHPAD_ID variable from before), then searches for tapping enabled and using the TAB character as a delimiter (though it’s not specified, it’s the default for cut), outputs the third field. This is the value of the “tapping enabled” property, a 0 or 1 value.

	if [ "$MY_TOUCHPAD_STATE" == "0" ]; then
		MY_TOUCHPAD_STATE="1"

This checks if the state is 0, and if so, sets it to 1.

	elif [ "$MY_TOUCHPAD_STATE" == "1" ]; then
		MY_TOUCHPAD_STATE="0"

This is another form of the if-clause, but one that’s nested within the clause itself. It can be read “else-if.” It checks to see if the state is 1, and if so, sets it to 0.

	else
		echo "touchpad.sh: ERROR: Could not find current touchpad status (to toggle). Setting to enabled."
		MY_TOUCHPAD_STATE="1"

This is another option in the if-clause: an option to match anything that didn’t meet the previous tests. In this case, it means the state was something other than 0 or 1, which is erroneous. The script chooses to arbitrarily set it to 1 to at least return it to a normal state.

elif [ "$1" != "0" ] && [ "$1" != "1" ]; then
	echo "touchpad.sh: ERROR: Passed argument not 0 or 1. Setting to 1."
	MY_TOUCHPAD_STATE="1"

I’m not sure you noticed it but there is actually a whole if-clause (i.e. if…fi) nested within another one. The first one checked if the first argument was empty and used the second if so. This returns back to that if-clause. In the event the argument is not empty, then it checks if it is something other than 0 or 1. If this is the case, just like the last error check, this sets it to 1.

else
	MY_TOUCHPAD_STATE="$1"

We’ve tested if the first argument was empty and if it was not 0 or 1, which leaves us the only other real options: it’s either 0 or 1. In that case, the script was run with a request for an explicit state. This sets our state variable to that argument.

xinput set-prop $MY_TOUCHPAD_ID "Tapping Enabled" $MY_TOUCHPAD_STATE

Now that we have our ID and we have our state, we can simply set it using those variables.

I hope that helps you better understand how the script works and will help you in creating future scripts. The key is that the touchpad ID is acquired generally and the property is defined more generally rather than by its ID.

One thing to consider is that it really doesn’t hurt to set a property to a value it already has. That said, you can also summarize it into two really long commands:

# Turn it off
xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled" 0
# Turn it on
xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled" 1

lubucub · May 26, 2019, 3:30pm

@wxl:

After at least 2 hours of tinkering I gave up, the Touchpad scripts, that is.

A) Your short version do not work, neither as scripts, nor in a terminal, e.g.

~$ xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled" 1

property 'Tapping Enabled' doesn't exist, you need to specify its type and format

No wonder, Touchpad is not specified.

B) azdays15’s script works fine as is; but of course it just switches the whole Touchpad on or off. If I replace “Touchpad Enabled” with “Tapping Enabled” (as you suggest) nothing happens, Tapping keeps beeing disabled.

Now I really need a long break!

Thanks, lubucub

lubucub · May 26, 2019, 3:51pm

@wxl: I am so frustrated that I forgot to thank you for your very detailed explanations, Thank you
“Pearls before swine”

lubucub · May 27, 2019, 6:42pm

@wxl: Touchpad script

Found a solution but it works not always: Why?

Your script

     # Turn it on
      xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled" 1

doesn not work properly in my case, because of two “Tapping Enabled” lines in my touchpad list, see here:

    Device 'ETPS/2 Elantech Touchpad':
            Device Enabled (151):   1
            Coordinate Transformation Matrix (153): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
            libinput Tapping Enabled (307): 0
            libinput Tapping Enabled Default (308): 0

So, I changed it to

xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled (" 1

This worked fine for some time, being able to change Tap on/Tap off just replacing 1 with 0 and vice versa). But now it does not anymore, it does not tap on, and there is an errotmodification, see later :

Response after running the script:

    property 'Tapping Enabled (' doesn't exist, you need to specify its type and format

This is eve more strange sice hte property “Tapping Enabled” is correctly found in my test script, i.e., both numbers correctly turn out, MY_TOUCHPAD_ID and MY_TOUCHPAD_STATE, 13 and 0 (iTap off, the latter):

    #!/bin/bash

    # Turn it on

    MY_TOUCHPAD_ID="$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)"

    MY_TOUCHPAD_STATE="$(xinput list-props $MY_TOUCHPAD_ID | grep -i "Tapping Enabled (" | cut  -f3)"

    echo $MY_TOUCHPAD_ID
    echo $MY_TOUCHPAD_STATE

    read -p "Press [Enter] key to continue..."

    # This is your original
    # xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled" 1

    # This is my modification
    xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "Tapping Enabled (" 1

    # xinput set-prop $MY_TOUCHPAD_ID $MY_TOUCHPAD_STATE 1

    echo $MY_TOUCHPAD_ID
    echo $MY_TOUCHPAD_STATE

    read -p "Press [Enter] key to continue..."

When I run it now I get:

    13
    0
    Press [Enter] key to continue... property 'Tapping Enabled (' doesn't exist, you need to specify its type and format
    13
    0

13 and 0 are correct, but why “doesn’t exist,…”
What could be wrong?

Thanks, lubucub

lubucub · May 28, 2019, 6:21pm

Finally solved, and it is rebootproof

These are the 4 essential lines of the TapToClickOn-script for Lubuntu 19.04:

    MY_TOUCHPAD_ID="$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)"

    TOUCHPAD_STATE="$(xinput list-props $MY_TOUCHPAD_ID | grep -i "Tapping Enabled (" | cut -d '(' -f2)"

    MY_TOUCHPAD_STATE="${TOUCHPAD_STATE:0:3}"

    xinput set-prop $MY_TOUCHPAD_ID $MY_TOUCHPAD_STATE 1

To set TapOff just replace 1 with 0

wxl · May 28, 2019, 10:38pm

I’m really confused as to why you’re searching for “Tapping Enabled (” and not “Tapping Enabled,” but I see how you worked around it to get it there, and managed some more high-level scripting, too. Good work!

lubucub · May 29, 2019, 5:00pm

@wxl:
Thanks, and quite simple: without “(” I get a longer string to slice, e.g.,
289): 1 290): 0
i.e., the first plus the second line’s information
while with " (" I get the shorter information from the first line only
289): 1
That’s all, nothing special about it, just my curiosity how to handle this tricky business in different ways.

wxl · May 29, 2019, 6:22pm

Oh, I see the issue. You’re trying to get the ID of the property. Originally I suggested that using the name of the property rather than the ID would be more general and would be less likely to get you in trouble. The problem was my assumption that the property was called “Tapping Enabled” when it’s actually “libinput Tapping Enabled.” If you used that, it would likely be better.

lubucub · May 30, 2019, 9:21am

@wxl

Thank you, works perfect now:

#!/bin/bash

# Turn it on
xinput set-prop "$(xinput list | grep -i touchpad | cut -d'=' -f2 | cut -d$'\t' -f1)" "libinput Tapping Enabled" 1

R690 · May 31, 2019, 10:57am

This question by lubucub highlights a severe weakness of Lubuntu, in that there is no GUI for touchpad settings or mouse double-click times etc.

Surely, the simplest answer to the question is to add the command to Autostart in the LXSession Configuration GUI in the Preferences menu?

wxl · May 31, 2019, 6:33pm

This is a severe weakness only of LXDE. If you read the entire thread, you’ll notice the next version of Lubuntu will contain a fix for LXQt.

This brings me to the point I’ve been saying over and over and over again: DON’T USE 18.04/LXDE and instead upgrade to 19.04+/LXQt. LXDE is dead. I don’t care what people say. The upstream developers are not fixing bugs, let alone adding features. That’s de facto dead.

R690 · May 31, 2019, 7:32pm

The original question referred to 18.04, and there are many good reasons for LTS users not to upgrade yet, unless they are looking for a new hobby.

I have a nice, stable, 18.04 system. In a few years’ time, I might consider upgrading is worth the hassle, but certainly not at the moment.

wxl · May 31, 2019, 7:46pm

Like the fact that there are “severe weaknesses” in it?

Yes, one that comes with a totally unreliable file manager.

What hassle is there?