Using xdotool for years on XWayland but now inhibited

[bulletmark]

Arch Linux updated to the new xdotool today (from version 3.20160805.1-3 to 3.20210804.2-1) and now xdotool terminates itself claiming it does not run on XWayland. However, myself and many others have been using xdotool with XWayland and libinput-gestures for very many years and it has always worked fine. Please consider removing that check and allowing the program to continue running as it previously did.

I fetched the latest xdotool sources, commented out that single return NULL, then rebuilt and it worked fine for all my key mappings.

Undoubtedly I acknowledge you have probably seen issues supporting some XWayland edge cases but to completely disallow xdotool usage seems an extreme approach. Perhaps output a disclaimer/warning that XWayland is not formally supported (and state that no issues should be raised?), but please allow us to continue using this extremely useful tool.

[jordansissel]

Can you tell me more about how you use xdotool on XWayland? I haven’t seen xdotool work correctly on Wayland/XWayland, and knowing more about what does work can help me make this better.

…

On Wed, Aug 4, 2021 at 3:47 PM Mark Blakeney ***@***.***> wrote: Arch Linux updated to the new xdotool today (from version 3.20160805.1-3 to 3.20210804.2-1) and now xdotool terminates itself claiming it does not run on XWayland <#341>. However, myself and many others have been using xdotool with XWayland and libinput-gestures <https://github.com/bulletmark/libinput-gestures> for very many years and it has always worked fine. Please consider removing that check and allowing the program to continue running as it previously did. I fetched the latest xdotool sources, commented out that single return NULL <https://github.com/jordansissel/xdotool/blob/master/xdo.c#L124>, then rebuilt and it worked fine for all my key mappings. Undoubtedly I acknowledge you have probably seen issues supporting some XWayland edge cases but to completely disallow xdotool usage seems an extreme approach. Perhaps output a disclaimer/warning that XWayland is not formally supported (and state that no issues should be raised?), but please allow us to continue using this extremely useful tool. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#346>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2X6BG56H4UPHH2AWODT3G7QZANCNFSM5BSFZUKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[bulletmark]

I have the following configuration in my libinput-gestures.conf file to allow gestures to work with Chrome browser and they work fine. Have been using them for years on GNOME with Wayland. Note that Chrome (and Firefox) runs via XWayland.

gesture swipe left	4	xdotool key alt+Right
gesture swipe right	4	xdotool key alt+Left
gesture swipe right_up	4	xdotool key control+Tab
gesture swipe left_up	4	xdotool key control+shift+Tab
gesture swipe left_down	4	xdotool key control+w
gesture swipe right_down 4	xdotool key control+shift+t

[bulletmark]

BTW, should make it clear that libinput-gestures does nothing special here and is kind of irrelevant. It simply executes the above commands when it sees the above touchpad gestures invoked, just as if those commands were run manually at the time.

[bulletmark]

To be very clear - of course xdotool does not work for any native Wayland applications, but it does work for all applications running via XWayland because that is just a regular X server where xdotool works fine. There are still plenty of apps (such as Chrome and Firefox at least) that run via XWayland within a user's Wayland session.

[jordansissel]

Thanks for the extra details! It’s good news (to me!) that at least some parts of xdotool work under XWayland. I’ll probably revert this to a warning (that still allows xdotool to run) and then think about ways to improve reporting about XWayland issues in the future.

…

On Wed, Aug 4, 2021 at 5:14 PM Mark Blakeney ***@***.***> wrote: To be very clear - of course xdotool does not work for any native Wayland applications, but it does work for all applications running via XWayland because that is just a regular X server where xdotool works fine. There are still plenty of apps (such as Chrome and Firefox at least) that run via XWayland in a user's Wayland session. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#346 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2WTZFM3JX6FH2FK3FLT3HJWLANCNFSM5BSFZUKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[bulletmark]

The only comment I would make about the warning is that it is a little noisy. E.g. every time a user invokes one of the above touchpad gestures, which for me is many hundreds of time per day when using my browser, then xdotool is run and it will output that message to the user's journal.

[Redecorating]

I've also been using xdotool under xwayland, for discord push to talk, with this bit of sway config:

bindsym Alt_R exec xdotool keydown F30
bindsym --release --locked Alt_R exec xdotool keyup F30

I then bind F30 to push to talk within discord, and right-alt works as global push to talk.

Another option for allowing xwayland would be to have an argument like --enable-xwayland which would skip the xwayland check. (you could then alias xdotool to xdotool --enable-wayland if you always want it to work under wayland)

[shibe2]

In my opinion, X clients, such as xdotool, should check advertised features rather than particular implementation. From this point of view, it would be best to just remove the unnecessary check.

xdotool works fine with XWayland, I haven't encountered a single operation that works with standalone Xorg and fails with XWayland. The only case when a warning would be warranted is when a user tries to interact with Wayland windows using X protocol. If you can detect that, good. Otherwise it's better to be quiet.

Wayland protocol can be used by X server to interact with hardware back-end while the user runs normal X session. This is suggested by X.org and Wayland developers. In this use case, there is no Wayland windows, and no X/Wayland confusion.

[jordansissel]

I'm OK to remove the previous change (which now rejects XWayland). I'm considering making it a warning message.

xdotool works fine with XWayland

I'm glad this has been your experience! For me, I notice very quickly that I'm running Wayland. I noticed when Fedora switched to it and, more recently, when Ubuntu switched to it, primarily through noticing that xdotool stops doing working the way it was before an OS upgrade.

There are a variety of perspectives through which "xdotool works on Wayland" is a correct statement. Not everyone has this experience though, which is why I wrote the patch in the first place. For context, I will not expect any xdotool user to know that they're graphics environment is Wayland, nor will I expect anyone to understand the oddities of XWayland vs XOrg.

More research is likely needed to be able to detect and/or notify users about expected issues, especially since any suggested corrective action might be a larger burden such as switching to X11/Xorg.

[jordansissel]

Not sure why my previous comment got mangled (I sent via email). I've edited it now 😆 hopefully it makes more sense.

[jordansissel]

should check advertised features rather than particular implementation

I don't know if this is possible, in a sense.

For example, if you're running Nautilus (gnome's file manager) and want to use xdotool to perform some action, it will probably fail on Wayland. The failure would be that xdotool wouldn't be able to find nor interact with any Wayland surfaces, and I don't expect a user to know the details about Wayland vs XWayland and the areas around which xdotool would or would not work.

In this way, having xdotool detect "Are we running on XWayland?" is the only way I found to detect any such "advertised feature" we might describe as "Stuff you could expect to work, but doesn't work, because you're running on Wayland"

As for detecting XWayland, I only found two ways to detect it. One of them is used by the xinput tool upstream in the Xorg project which uses the xinput device listing to check if any input device has a name starting with "xwayland-".

[shibe2]

I see a couple problems with warning:

1. Just detection of XWayland is not a good trigger for it. I gave an example XWayland use case where Wayland protocol would not be available to client applications, and from user's point of view, everything works the same way as with other X servers. I myself use a Wayland compositor for features that standalone Xorg server doesn't have, but applications that I want to control use X protocol. There is no window for which xdotool would not work.
2. In many use cases, xdotool is launched many times by scripts or other applications. Issuing the same warning on every invocation would clutter logs of legitimate users and bury actually useful messages.

When these problems are solved, it would be a good warning to have.

I will not expect any xdotool user to know that they're graphics environment is Wayland

The name of protocol is in the name of xdotool, so direct xdotool users should know about the protocols, in my opinion. Indirect users may not know, but perhaps, in this case, it is better to solve the problem in the applications that use xdotool. For example, a GUI applications can display information in the UI instead of writing warnings to stderr. A smart application can use xdotool for interacting with X windows and another tool for interacting with Wayland windows.

[jordansissel]

The name of protocol is in the name of xdotool

Xdotool predates Wayland by a while and as such may have unfortunate naming. The goal is unrelated to the protocol. If Wayland and it’s compositors supported what xdotool could do, I would have written support for Wayland by now. Best I can tell there’s still broad disagreement on what bonus Wayland protocols could exist (input-methods, for example, or EWMH equivalents)… I’d write the code if Wayland would let me. I gave up years ago asking for things because I would be dismissed as the features not being needed or “security problems” I’ll add Wayland support when it becomes possible.

…

On Mon, Aug 16, 2021 at 12:55 AM shibe2 ***@***.***> wrote: I see a couple problems with warning: 1. Just detection of XWayland is not a good trigger for it. I gave an example XWayland use case where Wayland protocol would not be available to client applications, and from user's point of view, everything works the same way as with other X servers. I myself use a Wayland compositor for features that standalone Xorg server doesn't have, but applications that I want to control use X protocol. There is no window for which xdotool would not work. 2. In many use cases, xdotool is launched many times by scripts or other applications. Issuing the same warning on every invocation would clutter logs of legitimate users and bury actually useful messages. When these problems are solved, it would be a good warning to have. I will not expect any xdotool user to know that they're graphics environment is Wayland The name of protocol is in the name of xdotool, so direct xdotool users should know about the protocols, in my opinion. Indirect users may not know, but perhaps, in this case, it is better to solve the problem in the applications that use xdotool. For example, a GUI applications can display information in the UI instead of writing warnings to stderr. A smart application can use xdotool for interacting with X windows and another tool for interacting with Wayland windows. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#346 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2S6ZPTWVHHE7TLI5JLT5C77PANCNFSM5BSFZUKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[Algram]

Yeah please re-enable it with wayland again. I've been using this with xwayland for years without problems. I actually had to downgrade xdotool after the wayland check was merged :)

Basically if you are running a wayland compositor, you will currently need both ydotool/wtyp and xdotool for wayland and xwayland windows respectively.

Here you can see an example of mine using it for inputting umlauts on sway:

[bulletmark]

Users who come here from Arch, please note that another user has added a new xdotool-xwayland package to the AUR to work around this issue. Use yay -S xdotool-xwayland to install.

[jordansissel]

@bulletmark thanks for highlighting that for folks on Arch :)

I'm going to remove the fail-on-wayland stuff for now. Hopefully we can figure out how to approach "You're on XWayland and some stuff won't work" better next time.

[jordansissel]

#355 should revert to the prior (working on XWayland).

We can keep it this way until we get a better idea of what scenarios and functionality do not work on XWayland and maybe bring some kind of warning for those scenarios.

[bulletmark]

@jordansissel are you planning to do a new release soon with that change?

[jordansissel]

@bulletmark indeed! Working on that now.

[jordansissel]

Release: https://github.com/jordansissel/xdotool/releases/tag/v3.20210903.1 should resolve this.

Tag: https://github.com/jordansissel/xdotool/tree/v3.20210903.1

[bulletmark]

Thanks very much. I have already flagged the Arch package to be updated soon hopefully.