Is it possible to automate clicks with xdotool to control a different GUI session from the one being currently used?

Question

The xdotool command allows us to create scripts controlling the graphical user interface of the system very easily. I can e.g. open my Chrome browser in the following desktop by executing xdotool mousemove 26 146 click 1.

So, let's say that I create a new user to my system:

# adduser newuser

If I log with newuser in a different session and execute xdotool commands they work perfectly fine. But well, let's say that I've opened two different GUI sessions in different ttys, one with my regular user and other with newuser, and let's also say that I'm currently running a GUI session with my regular user and I create the following script:

#!/bin/bash

xdotool mousemove 31 61 click 1

Then I save it as macro.bash on my home folder and execute chmod 777 ~/macro.bash to set the right permissions for it. Finally, I open a new terminal and I log as newuser (while I'm currently using my regular user session):

$ su newuser

Now if I try to execute my script I get the following error (see EDIT):

newuser@myPC:~$ /home/myregularuser/macro.bash 
No protocol specified
Error: Can't open display: (null)
Failed creating new xdo instance

This script works fine if I try to execute it while running a GUI session logged as newuser, but my goal here is to have a macro tool that can control the graphical interface of the newuser session with scripts while I'm using my regular user session. Is it possible? Does anyone know a workaround to solve this error?

---

EDIT

As quixotic said in the comments and telcoM said on his answer I was missing setting the right values of the environment variables $DISPLAY and $XAUTHORITY. Although I didn't manage to solve my problem as described on telcoM's answer, I managed to solve it with the following process:

1- Logging into my newuser session.

2- Inserting the following commands as the last lines of the ~/.bashrc file:

if xhost >& /dev/null; then
   echo "export DISPLAY=\"$DISPLAY\"" > $HOME/.variableMemory
   echo "export XAUTHORITY=\"$XAUTHORITY\"" >> $HOME/.variableMemory
fi

3- Changing my script making it redefine the $DISPLAY and $XAUTHORITY variables to their right values while the script is executed:

#!/bin/bash

source $HOME/.variableMemory
xdotool mousemove 31 61 click 1

With this, I'm basically capturing and saving the values of the $DISPLAY and $AUTHORITY variables when I first log on the newuser session with the graphical interface, so I can use these values when I log with the shell later.

Now I don't see any errors and I can move the mouse around the other session with the xdotool commands perfectly when I execute the script, but I have a new problem: The Xorg that is in a different GUI session is frozen while it's not being used. To sum up, it queues all the clicks that I send to it and then it releases all of them at once when I manually switch to that particular GUI session (and that makes xdotool unusable)... So, the question still remains: Is it possible to control a GUI session with a macro tool while I'm running a different GUI session? Is there a Xorg configuration that disables this "freezing behavior" so it receives the click commands on real time even when I'm not using that session?

---

Additional information

1. I'm running Ubuntu 18.04.
2. The display server used is Xorg (with Wayland xdotool doesn't work at all but this question isn't related to Wayland).
3. GNOME is the graphical user interface I'm currently using.
4. My main goal is to use a macro tool to control a screen that I'm not physically using, so I can use the computer while the macro does its job. Although I chose xdotool, Ubuntu, Xorg and GNOME to solve this problem, I'm open to answers that solve this same problem with different tools, desktop environments or even different Linux distributions... Thanks!!

Answer 1

The other component you're missing is the .Xauthority file. It contains a "session cookie" that is generated anew each time a X11 server restarts, and the client is required to have it in order to send any commands to the X11 server. This file is normally located in ~/.Xauthority, although you can use the $XAUTHORITY environment variable to specify an alternate location.

In order to control the GUI session that isn't yours, you'll need to gain access to the session cookie of that other session. If it has a different $DISPLAY value, you could simply copy that session cookie into your .Xauthority file using xauth extract and xauth merge commands:

su newuser -c "xauth extract /home/newuser/.Xauthority $newuserDISPLAY" | xauth merge

The .Xauthority file can hold multiple session cookies for different DISPLAYs at the same time.

Or if the session cookie is located in a file that is already accessible to you, you can use the $XAUTHORITY variable to point at it.

---

This is starting to seem like an XY problem: you have something you want to achieve, and may have fixated on xdotool as the assumed way to do it.

But when you are trying to automate something, going through the motions of the GUI using xdotool is usually the least convenient way to do it. For example, if you want to automate starting Google Chrome as a specific user, you don't need to simulate clicking an icon: you could just arrange for the right identity and environment, and just start the process you want.

For example, to start google-chrome as user newuser, you might do:

su -lc "DISPLAY=<whatever> google-chrome" newuser

As the su command has the -l option, the google-chrome process will have the right $HOME for newuser, and so it will look for .Xauthority in the default location, i.e. ~newuser/.Xauthority. You just need to supply the correct value for the $DISPLAY variable that matches the actual running GUI session of newuser. If you want Google Chrome to open a specific URL, you can specify it as an argument for google-chrome within the double quotes.