6

To toggle the enabling/disabling of my notebook's touchpad according to connected USB mouse, I used touchpad-indicator, which runs a daemon to monitor connected devices and take appropriate action. When I send notebook to sleep and then unplug my mouse, on the wake up, the touchpad is disabled, so I have to connect-disconnect the mouse to enable it! I've searched this forum for the problem and both found solutions (adding script in /etc/pm/sleep.d or /usr/lib/pm-utils/sleep.d) didn't work! I've put up a question to solve it, but after all, even when re-worked using udev's rules instead of touchpad-indicator, the problem still persists!

I want to clarify it: if touchpad was disabled on system level (i. e. disabled before even logging in, and the script would lie in rc.local, which, however, I tried, and it didn't work), putting scripts in /etc/pm and usr/lib/pm-utils may work.

But it is disabled on session level or whatever level does udev apply to. Can you please tell me where to put scripts which will run when I enter the password? NOT LOG-IN, BUT ENTER PASSWORD e.g. after wakeup.

Update: @terdon You didn't quite get it. I don't even have xscreensaver enabled, I doubt if it is even installed. You see, because my account has a password, if I press "Log out" or "Change user" OR SLEEP MODE, after that I will have to enter my password, and it has nothing to do with xscreensaver OR ANY SCREENSAVERS I DON'T HAVE THEM.

I tried what you suggested before asking this question and it didn't work out.

Update 2: Ok, after some investigation I can tell that it's a Lubuntu specific problem. I am working now on "befriending" lightdm (which I guess applies on some level other than udev) and udev. Anybody with any experience with lighdm is appreciated.

Update 3: Thanks to Ubuntu Wiki I (correctly?) figured out where to put the call of my script. So I added session-setup-script=/home/n76/tptoggle.sh to /etc/lightdm/lightdm.conf The current situation is the same as in the beginning, except that lightdm is actually trying to put touchpad on when user session starts

The problem isn't gone, but I feel that I'm close and it's just about giving lightdm the right privileges.

Please suggest how to do it.

1 Answers1

2

I don't know if there is a way to run things after entering your password as you request and I doubt there will be since that is handled by the desktop environment (probably the screensaver daemon). However, it should work perfectly well if you add the right scripts to /etc/pm/sleep.d. Since you have not shown the scripts you've tried, my guess is that you simply did not write the script correctly. The following works fine on my system:

  1. Create a file called /etc/pm/sleep.d/20_resume with the following contents:

    #!/bin/sh
    
    case "$1" in
        thaw|resume)
        /home/terdon/scripts/onoff.sh
        ;;
    esac
    exit $?
    

    Make sure to adapt the path above (/home/terdon/scripts/onoff.sh) to the actual path of the script shown in step 3.

  2. Give the file the right permissions (rwxr-xr-x)

    sudo chmod 755 /etc/pm/sleep.d/20_resume
    
  3. Write a script that turns off the touchpad if a mouse is connected and on if there is no connected mouse:

    #!/bin/sh
    
    ## Get the xinput ID of the touchpad
    TID=$(xinput list | grep -iPo 'touchpad.*id=\K\d+')
    
    ## Check if a mouse is connected and act accordingly
    xinput list | grep -iq mouse &&  xinput disable "$TID" || xinput enable "$TID" 
    

    Now save the script above using the path and name from step 1 (in this example, /home/terdon/scripts/onoff.sh), make it executable (chmod +x /home/terdon/scripts/onoff.sh) and you should be set.

If this is what you've already tried, please edit your question and show us the scripts you've used.


The other approach I can think of is to use the procedure outlined in my answer to your other question. I don't understand what you have against loops, they are a perfectly valid and indeed invaluable programming construct. The only issue I can think of is that running an infinite loop can tax your CPU but that should not be a problem if your script uses sleep to wait for a second or two between each loop run. Since my suggestion does just that, you can simply use that if the above fails you.

terdon
  • 104,119