9

I am using Manjaro 17 with i3wm (if any relevance).

I want to run a single command on start-up to fix the my touchpad tap click setting. I wrote the script that enables the option in /usr/bin/ and change its mode as executable.

/usr/bin/touchpad-enable-tap-click:

#!/bin/bash
exec xinput set-prop 11 290 1

The script can be smootly executed in terminal without causing any problem.

Based on my research, I prepared a simple service file in /etc/systemd/system/.

/etc/systemd/system/touchpad-enable-tap-click.service:

[Unit]
Description=Allow touchpad tap click

[Service]
Type=oneshot
ExecStart=/usr/bin/touchpad-enable-tap-click

[Install]
WantedBy=multi-user.target

than executed following command before reboot:

[sercan@compaq ~]$ sudo systemctl enable touchpad-enable-tap-click.service
Created symlink /etc/systemd/system/multi-user.target.wants/touchpad-enable-tap-click.service → /etc/systemd/system/touchpad-enable-tap-click.service.

I also tried full path.

The service is not working, as a result:

systemctl status

[sercan@compaq ~]$ systemctl status touchpad-enable-tap-click.service
● touchpad-enable-tap-click.service - Allow touchpad tap click
   Loaded: loaded (/etc/systemd/system/touchpad-enable-tap-click.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2017-04-22 01:51:17 +03; 14min ago
 Main PID: 32429 (code=exited, status=1/FAILURE)

Nis 22 01:51:17 compaq systemd[1]: Starting Allow touchpad tap click...
Nis 22 01:51:17 compaq bash[32429]: Unable to connect to X server
Nis 22 01:51:17 compaq systemd[1]: touchpad-enable-tap-click.service: Main process exited, code=exited, status=1/FAILURE
Nis 22 01:51:17 compaq systemd[1]: Failed to start Allow touchpad tap click.
Nis 22 01:51:17 compaq systemd[1]: touchpad-enable-tap-click.service: Unit entered failed state.
Nis 22 01:51:17 compaq systemd[1]: touchpad-enable-tap-click.service: Failed with result 'exit-code'.

journal -xe after attempting restart service:

Nis 22 02:09:52 compaq sudo[21550]:   sercan : TTY=pts/0 ; PWD=/home/sercan ; USER=root ; COMMAND=/usr/bin/systemctl restart touchpad-enable-tap-click.service
Nis 22 02:09:52 compaq sudo[21550]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nis 22 02:09:52 compaq systemd[1]: Starting Allow touchpad tap click...
-- Subject: Unit touchpad-enable-tap-click.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit touchpad-enable-tap-click.service has begun starting up.
Nis 22 02:09:52 compaq bash[21553]: Unable to connect to X server
Nis 22 02:09:52 compaq systemd[1]: touchpad-enable-tap-click.service: Main process exited, code=exited, status=1/FAILURE
Nis 22 02:09:52 compaq systemd[1]: Failed to start Allow touchpad tap click.
-- Subject: Unit touchpad-enable-tap-click.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit touchpad-enable-tap-click.service has failed.
-- 
-- The result is failed.
Nis 22 02:09:52 compaq systemd[1]: touchpad-enable-tap-click.service: Unit entered failed state.
Nis 22 02:09:52 compaq systemd[1]: touchpad-enable-tap-click.service: Failed with result 'exit-code'.
Nis 22 02:09:52 compaq sudo[21550]: pam_unix(sudo:session): session closed for user root

I hope you can help me, I appreciate.

1

2 Answers 2

6

The GUI is a distinct part of the operating system, and a machine can have multiple GUI environments. Your attempts with systemd aren't working because the services are executed outside of a GUI context. In fact, they're executed before the GUI starts. To run xinput, you need to have a GUI, which is provided by an X server.

Applications know what the GUI context is (i.e. which X server to communicate with) through the DISPLAY environment variable. This is a way to check whether a GUI is available: if that variable is not set, you're outside of a GUI context. (Setting the variable won't create a GUI context. It could let you connect to an existing GUI context from outside but that's not relevant here.)

If your login prompt is in graphical mode, then you're using a display manager. You can configure the display manager to run xinput, and then the settings will be applied as soon as the login prompt is displayed. How to do that depends on which display manager you're using; see How can I run a script that starts before my login screen? for more details.

No matter how you log in, you can apply the settings as part of your login scripts. If you're using .xinitrc or .xsession to start your GUI session, add the command there. If you're using a desktop environment which has a concept of startup applications, add the xinput command, or a script that runs it, to your startup applications. If you're using a window manager directly, check its documentation for how to run a command at startup (almost any window manager can do this).

Since you're using i3, you can run a command at GUI login time by putting an exec command in your ~/.i3/config:

exec xinput set-prop 11 290 1

Although systemd starts the display manager as a service, I don't think it provides a way to run a command in the resulting GUI context. It may provide a way to run a command when you log in however; see the Arch Wiki for examples.

1
  • If the service is running under a user account that has a GUI context, this solves the issue. I have yet to figure out how to do it for services running under root, though. Commented Mar 9, 2022 at 22:49
4

This is happening because you are trying to run a command that modifies the behavior of the X system (the GUI) before X has loaded. So, understandably enough, it complains that it can't connect to the X server. The hint is the name of the command you are running: xinput .

Now, I can't guarantee that systemd won't in the near future develop the capability of interacting with a server that hasn't started yet, but for the time being, this isn't the right tool for the job.

The first thing to try is to just add that (without the unnecessary exec) command to your ~/.profile (or, if you use bash and it exists, to your ~/.bash_profile):

xinput set-prop 11 290 1

Note, however, that this will make it complain if you are logging in non-graphically. If that doesn't work (see here for details), find a way to add it to your desktop environment's startup programs. Most popular DEs like Gnome, Cinnamon, KDE, Unity etc, have GUI tools that let you load programs on login. See here for how to do it in openbox and here for LXDE. Alternatively, see here for a more global solution using ~/config/autostart.

8
  • 2
    A DE startup script makes much more sense than any shell profile. It only needs to run once, after starting X.
    – Jeff Schaller
    Commented Apr 22, 2017 at 0:01
  • @JeffSchaller indeed, but that assumes a DE, that's all. Although, that said, my personal preference would be ~/.profile as long as I'm using a login manager that reads it. Still only executed once on login and no need to fiddle about with cumbersome GUI things.
    – terdon
    Commented Apr 22, 2017 at 0:09
  • I'm imagining remote ssh sessions that don't invoke X, yet would run xinput anyway. Could wrap it in a test for DISPLAY being set, or just put it with the X startup scripts.
    – Jeff Schaller
    Commented Apr 22, 2017 at 0:13
  • @JeffSchaller ah, yes that's a fair point.
    – terdon
    Commented Apr 22, 2017 at 10:18
  • 1
    ~/.profile is a bad idea. It would run when logging in over SSH with X11 forwarding enabled, for example. Commented Apr 22, 2017 at 21:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .