1

I am trying to get a way to execute a script from a root session, but I am having some trouble with it. I'll lay out the issue:

I have a script that performs some tasks as the regular user 'kolterdyx', and some others as root with sudo. What this script does is rotate a screen and update the touchscreen calibration matrix automatically. I spent about a week troubleshooting that and the script I came up with is as follows:

/home/kolterdyx/.cargo/bin/gnome-randr modify HDMI-1 --rotate "$1"

rule='ATTRS{idVendor}=="27c0", ATTRS{idProduct}=="0818", ENV{LIBINPUT_CALIBRATION_MATRIX}='

right='"0 -1 1 1 0 0"'
left='"0 1 0 -1 0 1"'
inverted='"-1 0 1 0 -1 1"'
normal='"1 0 0 0 1 0"'

case "$1" in
  left )
    RULE="$rule$left"
    ;;
  right )
    RULE="$rule$right"
    ;;
  inverted )
    RULE="$rule$inverted"
    ;;
  normal )
    RULE="$rule$normal"
  * )
    echo "You need to pass an argument"
    exit
    ;;
esac

sudo bash -c "echo '$RULE' > /etc/udev/rules.d/99-calibration.rules"


sudo udevadm control --reload-rules
sudo udevadm trigger
sudo bash -c 'echo 1-1 > /sys/bus/usb/drivers/usb/unbind'
sudo bash -c 'echo 1-1 > /sys/bus/usb/drivers/usb/bind'

The system this is running on is Raspberry Pi OS, which I installed without a desktop, and then installed Gnome, which by default uses Wayland and Gnome-Shell. That opened the can of worms that is trying to perform X11 tasks on a non X11 environment, through SSH (because I can't hook up a keyboard to the raspberry pi).

I managed to get that script working, but it only works if I run it as kolterdyx, directly from the user shell. sudo -u kolterdyx or runuser -u kolterdyx as any other user won't work, and the error I get is as follows:

Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

This happens because of the first line, which is a command from gnome-randr-rust. For some reason, if I run it by logging in as kolterdyx it works fine, but if I run it as root either with or without sudo -u kolterdyx, I get the previous error. Isn't sudo supposed to make the target user run the command? What's the difference and how can I get the command to run as my user from the root user?

1 Answer 1

1

Programs find your D-Bus session bus in a few ways:

  • Explicitly set $DBUS_SESSION_BUS_ADDRESS. This is the main method if you don't use systemd or if your distro doesn't have the "user bus" model enabled; in those cases usually a random address is chosen every time you log in.

  • A well-known path under $XDG_RUNTIME_DIR/bus. This is the systemd-ish approach where each UID has only one session bus and always at a semi-fixed per-UID location.

  • Auto-launch based on the X11 $DISPLAY; a legacy mechanism from the early days of D-Bus that most distros avoid now (not least because it's X11-dependent). Being the last fallback is why it ends up in those misleading error messages, though.

So you need to set one of the two environment variables mentioned above. On a systemd environment, XDG_RUNTIME_DIR would be the easier option because it's pretty much always set to /run/user/$UID and you can safely hardcode that format in scripts – and it will cover not only D-Bus but also the Wayland socket address and various other components that have settled around that path. Otherwise, though, you need to have your desktop session write out its DBUS_SESSION_BUS_ADDRESS into a file on startup, which the script will then read.

(In fact, with systemd being present, it might be easiest to systemd-run --user -M [email protected] to automatically find the bus address and spawn the command directly inside your session, having all necessary environment.)

As a side note, doesn't GNOME already have built-in support for detecting screen orientation via iio-sensor-proxy?

1
  • That works! As for the side note, even if gnome has support for that, I don't have an accelerometer set up yet, and even when manually rotating, the touchscreen would not update. I had a lot of problems trying to rotate the screen manually from the command line, and the same for rotating the touchscreen. As you can see I ended up having to hardcode calibration values, reloading udev, and programatically unplugging and plugging in the touchscreen Commented Feb 2, 2024 at 13:22

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.