#xdotool

[x11-official]

Even by my standards, the way I got mouse chording to finally work is very, very cursed.

This runs from a systemd service that itself is started and stopped by a udev rule, and adds mouse-only shortcuts for "home", "end", "delete", and "enter", all of which are relatively hard to reach with just the left hand on the keyboard.

[dvdmerwe]

I’m still in the process of fully migrating to Wayland from X11 on Linux, as there are still a few niggly things that don’t work 100%. At least Wayland is now stable for me on Manjaro Plasma desktop. But one challenge was getting keystrokes and mouse actions to work on Wayland, as all my shortcut keys on my Stream Deck are set up using the great xdotool which does all that, as well as window functions.

So ydotool does do the keystrokes and mouse actions quite well (using the identical syntax on Wayland and X11) but there are some caveats unfortunately: * It does not do any window functions like resize, move, bring into focus, or therefore, directing actions straight into a background window. And worse, even wmctrl misses some windows on Wayland – it recognised the Zoom Meeting window but not Kdenlive, but I need to test it out more thoroughly. * It has an unintuitive syntax as everything is keycodes such as 28:1 to press and 28:0 to release instead of xdotool’s alt+g for example. * The instructions to install are “messy” with it installing as a user service when it should be a systemwide root service. It may be that the documentation is a bit out of sync.

The reason ydotool works the same across Wayland, X11 and even other desktops (You can use it on anything as long as it accepts keyboard/mouse/whatever input. For example, X11, text console, “RetroArch OS”, fbdev apps (fbterm/mplayer/SDL1/LittleVGL/Qt Embedded), etc.), is that it uses the uinput framework of Linux kernel to emulate an input device, unlike xdotool which directs all its output only to the X server (it would have to be rewritten for Wayland to work there). I do have XWayland installed, so this is showing that keystrokes from xdotool appear in my terminal window, but not for example in application windows such as Kdenlive and others. So yes, maybe xdotool and / or XWayland get improved to handle xdotool properly still…

But for those who are interested in trying ydotool I’m going to just expand on the syntax as well as installation issues a bit as I spent hours finding the info, and this will at least give you some quick context, and save you some time:

Installation

As I said it must be a systemwide service (ignore what it’s help says) so any systemctl commands must be run with sudo. I installed it from the AUR on Majaro, but I gather the compiling also installs it’s systemd service config file in /usr/lib/systemd/user/ instead of /usr/lib/systemd/system/ so these are the steps I followed to get installation right: 1. I moved the service file it made (/usr/lib/systemd/user/ydotool.service to /usr/lib/systemd/system/. 2. I edited the service file with sudo nano /usr/lib/systemd/system/ydotool.service and changed the ExecStart line as per insert below. Note that the 1000 refers to the usual default user on Linux so in my case this was correct. If in doubt, run whoami | xargs id -u to check your user number. This change is needed so that it creates the socket where ydotool expects to find it, and also that the socket is owned and readable by the non-root user.

# /usr/lib/systemd/system/ydotool.service [Unit] Description=Starts ydotoold service [Service] Type=simple Restart=always ExecStart=/usr/bin/ydotoold --socket-path="/run/user/1000/.ydotool_socket" --socket-own="1000:1000" ExecReload=/usr/bin/kill -HUP $MAINPID KillMode=process TimeoutSec=180 [Install] WantedBy=default.target

The key thing now is to enable and start that service systemwide, so the following needs to be executed:

sudo systemctl daemon-reload sudo systemctl enable ydotool.service sudo systemctl start ydotool.service sudo systemctl status ydotool.service

A last step was to also set the environment variable in the .bashrc file in the users home directory. I just added this line export YDOTOOL_SOCKET="/run/user/1000/.ydotool_socket".

Personally, I really think the ydotool installation should just be fixed for all of this. It relates mainly to it being installed as a user service instead of a systemwide service…

Syntax

It looks a bit intimidating but you only set this up once if you have the hang of it, it is pretty easy to do, but you do need to open the following file to view, so you know which are the correct keycodes to use on your computer.

The other thing to remember is you execute key presses, and then release in the reverse order. So for example where I may want to send a Alt+Right with xdotool I would just execute: xdotool key Alt_L+Right it will be ydotool key 56:1 106:1 106:0 56:0 for ydotool. The 56:1 means press the Alt key and the 56:0 means release the Alt key.

For something like Alt and Right Arrow xdotool would be xdotool key Alt_L+Right whilst ydotool would be ydotool key 56:1 106:1 106:0 56:0.

But if you want to paste whole strings of text, for a mail signature for example, it is quite similar to xdotool using the type command, so this is an example of how you would insert Best Wishes, and newline, and Name Surname for both: * xdotool is: xdotool type "Best Wishes" && xdotool key Return && xdotool type "Name Surname" * ydotool is: ydotool type "Best Wishes" && ydotool key 28:1 28:0 && ydotool type "Name Surname"

I see that ydotool is apparently being rewritten in JavaScript later in 2024 so maybe lots of the current issues will be sorted out soon. More info at their project at https://github.com/ReimuNotMoe/ydotool.

[dvdmerwe]

I’m busy looking into xdotool to automate various actions on Linux with the Elgato Stream Deck (well because Elgato only provides apps for Windows and MacOS). There is a good Linux alternative app to work with the Stream Deck, but I do need to be able to execute some commands when I want to bring a specific window into focus from the background, and then to execute a key press shortcut. So an example may be to bring Brave Beta browser window into focus, then activate tab 3 and do a tab fresh.

Another tip I worked out is instead of struggling to identify which window has which name exactly, you can also right-click on a window’s title bar and choose to rename the window. When I restarted that application, it retained the window name.

So, to bring Brave Beta browser into focus, activate tab 2 (CTRL-2), and then do a fresh (CTRL-R), I can just set this command string to a hot key on the Stream Deck: ‘xdotool search –name ‘Brave-Beta’ windowactivate –sync key ctrl+2 ctrl+r’.

You can still do this sort of thing without having any Stream Deck by just setting the same string to any Linux shortcut on the keyboard.

Xdotool lets you simulate keyboard input and mouse activity, move and resize windows, etc. It does this using X11’s XTEST extension and other Xlib functions. With xdotool, you can search for windows and move, resize, hide, and modify window properties like the title. If your window manager supports it, you can use xdotool to switch desktops, move windows between desktops, and change the number of desktops.

See https://github.com/jordansissel/xdotool

[dais-cns]

#!/usr/local/bin/xdotool search --onlyvisible --classname $1 windowsize %@ $2 $3 windowraise %@ windowmove %1 0 0 windowmove %2 $2 0

[adventureswithedmund]

Getting Coordinate of Mouse Clicks in Linux

Here is an update to the previous post. Continuing my project on making a self adjusting eye tracker with a webcam, I need to get the coordinates from mouse clicks some how. This is because I do not want to use a 'calibration screen' to get the relative position of the user and the webcam. As the user shifts their heads the calibration will immediately be off. As a result, it seems more sensible if the 'calibration' was the user's mouse clicks. Users click throughout using a computer and it is likely that when the user is clicking, they are also looking where they are clicking. Therefore, the system will automatically calibrate it self with each click by continuously adjusting the known relative position of the user and the webcam on each new click. Getting the coordinates of mouse clicks was actually pretty easy (xdotool). Getting an event when the mouse was click was hard. I saw many 'solutions' online with libraries like pygame and Xlib (I think I know why it didn't work) but they didn't seem to work. I finally came across PyUserInput which seems to work. This is specifically for Python 2.7 running in Linux (Ubuntu). PyUserInput easily allows you to detect when a mouse click occurs anywhere. It actually uses Xlib (which I thought didn't work earlier). The issue though is that version 15rc of Xlib doesn't work and gives and error message. On the other hand, using version 14 of Xlib worked perfectly...so that was an interesting snag. The code looks something like this: (pymouse is part of PyUserInput) To actually get the location of the mouse, the good ol' xdotool saves the day. Simply use xdotool getmouselocation and it will output in bash. Of course I will be calling it through python and getting the variables. The next step will be taking data of the head, eyes and click data and hopefully finding some sort of modeling/training method to make this possible. *Also, I will not be doing head tracking since last time I said it was too slow. Instead, I will use the eye tracking boxes to track the head. To get the eye gaze location or pupil location, I will image process the data within the eye box. Doing this will give my actual gaze and head location data. (pupil tracking now here!)

[vsenyo]

xdotoolにつかうWM_CLASSのとり方

xprop WM_CLASS

として、対象のウィンドウをクリックすると表示される。

。。。て、違うわ。

xdotool selectwindow

でいいじゃん