Disabling touchpad on startup

Kinda dumb question, but how can I disable touchpad on my laptop after I login into DE?
I mean I tried several things, but still can't get this thing to work.

What I tried:

  1. I created a unit
    /etc/systemd/system/disable_tp.service with link to .sh script with the following syntax:
 xinput disable "SynPS/2 Synaptics TouchPad"

I did also chmod +x on this file, it became executable, and it works when I run it (on FM or terminal). It is really disabling the touchpad, great. Now I need to run it on log in.
I enabled and started the unit via systemctl and after reboot it doesn't work.
2. I tried to set this .sh script on Settings => Startup & Shutdown => Autostart => Login Scripts.
Reboot - still doesn't work.

Any idea what I'm doing wrong?

And yeah, here is garuda-inxi

Kernel: 5.19.1-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.1.1
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=9dbc2d80-f8ff-4292-9f96-dc64de48b51f rw [email protected]
quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
resume=UUID=a34c3215-eb63-4d11-b6c9-b05946c5521a loglevel=3 ibt=off
Desktop: KDE Plasma v: 5.25.4 tk: Qt v: 5.15.5 info: latte-dock
wm: kwin_x11 vt: 1 dm: SDDM Distro: Garuda Linux base: Arch Linux
Type: Laptop System: Micro-Star product: GS65 Stealth Thin 8RF v: REV:1.0
serial: Chassis: type: 10 serial:
Mobo: Micro-Star model: MS-16Q2 v: REV:1.0 serial:
UEFI: American Megatrends v: E16Q2IMS.112 date: 05/21/2019
ID-1: BAT1 charge: 79.7 Wh (99.3%) condition: 80.3/80.3 Wh (100.0%)
volts: 16.9 min: 15.2 model: MSI BIF0_9 type: Li-ion serial: N/A
status: not charging
Info: model: Intel Core i7-8750H bits: 64 type: MT MCP arch: Coffee Lake
gen: core 8 built: 2018 process: Intel 14nm family: 6 model-id: 0x9E (158)
stepping: 0xA (10) microcode: 0xF0
Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB desc: 6x256 KiB
L3: 9 MiB desc: 1x9 MiB
Speed (MHz): avg: 2516 high: 4100 min/max: 800/4100 scaling:
driver: intel_pstate governor: performance cores: 1: 2200 2: 2200 3: 2200
4: 2200 5: 2200 6: 4100 7: 4100 8: 2200 9: 2200 10: 2200 11: 2200
12: 2200 bogomips: 52799
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Type: itlb_multihit status: KVM: VMX disabled
Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
Type: retbleed mitigation: IBRS
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
Type: spectre_v2 mitigation: IBRS, IBPB: conditional, RSB filling,
PBRSB-eIBRS: Not affected
Type: srbds mitigation: Microcode
Type: tsx_async_abort status: Not affected
Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] vendor: Micro-Star MSI
driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20
ports: active: eDP-1 empty: DP-1,HDMI-A-1 bus-ID: 00:02.0
chip-ID: 8086:3e9b class-ID: 0300
Device-2: NVIDIA GP104M [GeForce GTX 1070 Mobile] vendor: Micro-Star MSI
driver: nvidia v: 515.65.01 alternate: nouveau,nvidia_drm non-free: 515.xx+
status: current (as of 2022-07) arch: Pascal code: GP10x
process: TSMC 16nm built: 2016-21 pcie: gen: 3 speed: 8 GT/s lanes: 16
ports: active: none empty: DP-2,HDMI-A-2 bus-ID: 01:00.0
chip-ID: 10de:1ba1 class-ID: 0300
Display: x11 server: [X.Org](http://X.Org) v: 21.1.4 with: Xwayland v: 22.1.3
compositor: kwin_x11 driver: X: loaded: modesetting,nvidia gpu: i915
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: eDP-1 mapped: eDP-1-1 model: AU Optronics 0x80ed built: 2017
res: 1920x1080 hz: 144 dpi: 142 gamma: 1.2 size: 344x193mm (13.54x7.6")
diag: 394mm (15.5") ratio: 16:9 modes: 1920x1080
OpenGL: renderer: NVIDIA GeForce GTX 1070 with Max-Q Design/PCIe/SSE2
v: 4.6.0 NVIDIA 515.65.01 direct render: Yes
Device-1: Intel Cannon Lake PCH cAVS vendor: Micro-Star MSI
driver: snd_hda_intel bus-ID: 1-4.4:6 v: kernel
alternate: snd_soc_skl,snd_sof_pci_intel_cnl chip-ID: 0c76:161f
class-ID: 0300 bus-ID: 00:1f.3 chip-ID: 8086:a348 class-ID: 0403
Device-2: NVIDIA GP104 High Definition Audio driver: snd_hda_intel
v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16 bus-ID: 01:00.1
chip-ID: 10de:10f0 class-ID: 0403
Device-3: JMTek LLC. USB PnP Audio Device type: USB
driver: hid-generic,snd-usb-audio,usbhid
Sound Server-1: ALSA v: k5.19.1-zen1-1-zen running: yes
Sound Server-2: sndio v: N/A running: no
Sound Server-3: PulseAudio v: 16.1 running: no
Sound Server-4: PipeWire v: 0.3.56 running: yes
Device-1: Intel Cannon Lake PCH CNVi WiFi driver: iwlwifi v: kernel
bus-ID: 00:14.3 chip-ID: 8086:a370 class-ID: 0280
IF: wlo1 state: up mac:
Device-2: Qualcomm Atheros Killer E2500 Gigabit Ethernet
vendor: Micro-Star MSI driver: alx v: kernel pcie: gen: 1 speed: 2.5 GT/s
lanes: 1 port: 3000 bus-ID: 3c:00.0 chip-ID: 1969:e0b1 class-ID: 0200
IF: enp60s0 state: down mac:
IF-ID-1: virbr0 state: down mac:
Device-1: Intel Bluetooth 9460/9560 Jefferson Peak (JfP) type: USB
driver: btusb v: 0.8 bus-ID: 1-14:5 chip-ID: 8087:0aaa class-ID: e001
Report: bt-adapter ID: hci0 rfk-id: 1 state: up address:
Local Storage: total: 953.88 GiB used: 410.3 GiB (43.0%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/sda maj-min: 8:0 vendor: Kingston model: RBUSNS8180S3512GJ
size: 476.94 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
type: SSD serial: rev: 61D1 scheme: GPT
ID-2: /dev/sdb maj-min: 8:16 type: USB vendor: Transcend
model: TS512GSSD230S size: 476.94 GiB block-size: physical: 512 B
logical: 512 B type: SSD serial: rev: 02J0 scheme: GPT
ID-1: / raw-size: 467.46 GiB size: 467.46 GiB (100.00%) used: 410.3 GiB
(87.8%) fs: btrfs dev: /dev/sda7 maj-min: 8:7
ID-2: /boot/efi raw-size: 600.3 MiB size: 599.1 MiB (99.80%) used: 580
KiB (0.1%) fs: vfat dev: /dev/sda5 maj-min: 8:5
ID-3: /home raw-size: 467.46 GiB size: 467.46 GiB (100.00%) used: 410.3
GiB (87.8%) fs: btrfs dev: /dev/sda7 maj-min: 8:7
ID-4: /var/log raw-size: 467.46 GiB size: 467.46 GiB (100.00%) used: 410.3
GiB (87.8%) fs: btrfs dev: /dev/sda7 maj-min: 8:7
ID-5: /var/tmp raw-size: 467.46 GiB size: 467.46 GiB (100.00%) used: 410.3
GiB (87.8%) fs: btrfs dev: /dev/sda7 maj-min: 8:7
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 15.47 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
ID-2: swap-2 type: partition size: 8.79 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/sda6 maj-min: 8:6
System Temperatures: cpu: 55.0 C pch: 52.0 C mobo: N/A gpu: nvidia
temp: 52 C
Fan Speeds (RPM): N/A
Processes: 338 Uptime: 4m wakeups: 1 Memory: 15.47 GiB used: 2.57 GiB
(16.6%) Init: systemd v: 251 default: graphical tool: systemctl
Compilers: gcc: 12.1.1 clang: 14.0.6 Packages: pacman: 1947 lib: 561
Shell: fish v: 3.5.1 default: Bash v: 5.1.16 running-in: konsole
inxi: 3.3.20
Garuda (2.6.5-1):
System install date: 2022-05-26
Last full system update: 2022-08-14
Is partially upgraded: No
Relevant software: NetworkManager
Windows dual boot: Probably (Run as root to verify)
Snapshots: Snapper
Failed units: disable_tp.service

I can see failed unit - disable_tp.service.
Here is a unit syntax:

Description=disabling touchpad on DE startup



This is unit status command output:

    × disable_tp.service - disabling touchpad on DE startup
    Loaded: loaded (/etc/systemd/system/disable_tp.service; enabled; preset: disabled)
    Active: failed (Result: exit-code) since Mon 2022-08-15 05:15:01 MSK; 2s ago
    Duration: 6ms
    Process: 18693 ExecStart=/home/rat/.config/autostart/disable_tp.sh (code=exited, status=1/FAILURE)
    Main PID: 18693 (code=exited, status=1/FAILURE)
    CPU: 6ms

    авг 15 05:15:01 SSDDgl systemd[1]: Started disabling touchpad on DE startup.
    авг 15 05:15:01 SSDDgl disable_tp.sh[18695]: Unable to connect to X server
    авг 15 05:15:01 SSDDgl systemd[1]: disable_tp.service: Main process exited, code=exited, status=1/FAILURE
    авг 15 05:15:01 SSDDgl systemd[1]: disable_tp.service: Failed with result 'exit-code'.

Can't figure out why it is unable to connect to X server? :slight_smile:

Hi there, welcome to the forum!
I'd try to make it easier.
The problem could be due to the fact that the script is launched as root, but this is not needed for your command.
You could create an Autostart application entry running your command or your script (but I don't think it is necessary).
Altrrnatively in the KDE settings for the touchpad there should be flags to disable it while typing or when mouse is connected.

1 Like

Why is that? Don't get me wrong - I'm still learning, so I'm just curious.

I thought I tried to do exactly this via systemd actually. :slight_smile: Are there any other ways to do it?

Unfortunately it's all I have there. :frowning:

Search for Autostart on the search field in the application menu. It is very easy to add a new entry. I cannot help further since I'm off and with mobile only.

1 Like

Ah, that one. Yeah I know, I already tried it and it's not working. I mentioned it in first post:

I mean as soon I don't press Fn key and F3 key after I booted - touchpad is still working. It is driving me crazy already. :smiley:

It may be the X server is not finished doing its own thing when this service launches, see this thread for some thoughts on that.

You can either delay the start of the service until after the X server is available to respond to it, or as Filo mentioned you can find another way to start it.

Have you tried adding the script to .xinitrc or .xsession?

1 Like

Wow, no I didn't tried it yet. Will give it a go, thanks!

Instead of the script you could try also launching directly a command, like

xinput disable "SynPS/2 Synaptics TouchPad"
1 Like

Autostart allows me add only script. :frowning:
P.S. Sorry for hyperlinks, I can't upload pictures yet.

Use the Application option.
You could also try creating the desktop file directly like here, but with your command


Tried this solution - no luck. :frowning:

I decided to turn the touchpad off for good. Permanently. I will hope that I don't forget to turn it on before disconnecting the mouse. :slight_smile:
Too much time wasted on this task imo.
Thanks for your replies tho.

This sounds like an xy problem.
Can you explain the real issue, instead of how to implement what you think of the solution to it?

Since the script works in terminal, it should also work with the other autostart methods. You are probably missing, or using wrong fields/values.

For example, .desktop files that actually run a terminal command, need Terminal=true in the settings.
Something similar (but not same, since the mechanism is different) should happen with the service file, which, as was noted, needs to be in user space (~/.config/systemd/user/).

First answer the ... first question :wink:


Alright, the real issue is that solutions I trying to implement while disabling my touchpad on DE startup are not working.
So I have pretty clear task: touchpad needs to be disabled when I logging in DE. I should be able to enable it by pressing Fn+F3.

Yeah, that's why I'm asking for help actually. :upside_down_face:
Here is a syntax of my .sh script:

xinput disable "SynPS/2 Synaptics TouchPad"

What I'm potentially missing here? It is really works when I run it by double clicking mouse on it or when I running it from terminal.

Yes, it is a pretty good example, but unfortunately I don't use .desktop file, I use direct .sh script.

I mentioned the solutions I tried to implement in first post to make the whole process of accomplishing this task as clear as possible. :slight_smile:

So here's list of solutions I tried to make this happen:

  1. Creating a unit to run the script on startup using systemd.
  2. Putting a script in the /home/rat/.config/autostart/ folder.
  3. Using the KDE autostart and adding a script there.
  4. Using the KDE autostart and adding a script there as application.
  5. Editing the script (adding sleep 10 key to make sure that X server are not busy doing other important tasks).
  6. Edinting the script (adding > ~/touchpad.log to see whats wrong - the log file is empty every time).
  7. Tried the solution from this post.
  8. Installing switchboard-plug-mouse-touchpad-git package from AUR. This package adds the option to automatically disable touchpad when mouse is connected - ticked this flag, rebooted - touchpad is still working.

I give up. :grin:

I'm curious if you gave this a shot? Either adding the script or just the command from the script. If you don't have an .xinitrc in your home folder you can just make one.

micro ~/.xinitrc

Add the line, save & exit, reboot and see what happens. :crossed_fingers:

Yeah I have this folder on my home directory.
I added this line to script like this:

xinput disable "SynPS/2 Synaptics TouchPad"
micro ~/.xinitrc

Rebooted - no bueno.

Then I changed it like this:

xinput disable "SynPS/2 Synaptics TouchPad" && micro ~/.xinitrc

Rebooted - touchpad still works.

Well, thanks for suggestion anyway. :slight_smile:

UPD. Oh, wait, I guess I misunderstood. Gimme 5 minutes.
UPD 2. I have a file .xinitrc, not a folder. What should I do with it?

The file should be, as suggested, [ ~/.xinitrc ]
Which is exactly :: [ /home/$USER/.xinitrc ]

Within this file add the command itself or point to your script.

Add (appending if necessary) the following line to the file [ ~/.xinitrc ]

xinput disable "SynPS/2 Synaptics TouchPad"

Save, reboot.


Why? What happens if it is enabled, and what happens if it is disabled?

My English is not native, so I suppose there is a language issue... :person_shrugging:


If there is a chance to help you find the "wrong", you should post the contents of files and the paths you save them at.
If you think you do everything right, I wonder why did you post, apart from a usual complaint. :grey_question:

Your system, you the boss! :+1:

This is not sourced when using a DM, only when starting with starx. The equivalent is .xprofile, but it is not supposed to be used for running tasks, mostly for setting env-vars, but it wouldn't hurt trying.

Checking the journal and Xorg logs, might reveal a potential reason of the failure, for any of the methods tried.


Great point @petsam. ! My answer assumed the $USER knew which order & conditions the sourcing takes place.

Thanks to @petsam we will pinpoint even further this subject. Good spot here to read up on the ordering & hierarchy of sourcing for further explanation:

... archwiki snippit start ...

Sourcing xprofile from a session started with xinit

It is possible to source xprofile from a session started with one of the following programs:

All of these execute, directly or indirectly, ~/.xinitrc or /etc/X11/xinit/xinitrc if it does not exist. That is why xprofile has to be sourced from these files.

... archwiki snippit end ...

Documentation Resource:

Go to the source... Luke.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.