autokey / autokey

AutoKey, a desktop automation utility for Linux and X11.
https://autokey.github.io/index.html
GNU General Public License v3.0
3.45k stars 191 forks source link

Add warning when the user launches Autokey under wayland #600

Open sebastiansam55 opened 3 years ago

sebastiansam55 commented 3 years ago

Just to ease issues with users not understanding what is going wrong.

If this could be tagged as easy fix that would be neat.

So if anyone wants to take a crack at fixing this here is what more or less how I would do it;

https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used From this link, the command loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type | awk -F= '{print $2}' seems to be the best solution to determine what login session the user is in. (wayland or x11)

I'd slap this in a function in UI_common_functions.py with a subprocess call (there are many examples of using this call elsewhere in the codebase) and check the output and throw both a logging message as well as an error message (I'd add it in the checkRequirements() function in the same file.

nevarek commented 3 years ago

I have some questions answered in order to finish work on this one

  1. What should the string message be, precisely? What would be the most helpful information to tell the user when they're running Wayland?
  2. Does the headless application need this check? I imagine not, but I will defer to a maintainers' judgment here instead of making an assumption.
sebastiansam55 commented 3 years ago

Can you embed links in the popup? Not sure offhand, but it might make the most sense to add a wiki page with more information about how to fix the issue. I know that for ubuntu all you have to do in 21.04 is logout and select the "Ubuntu on Xorg" or something like that to get back to X11, but the process might not be as simple for other distros.

Something like;

Autokey has detected that you are not using the Wayland Desktop Environment. 
Autokey is currently only officially designed to work on X11.

Not sure that we should be giving out info/recommending that people swap DEs as I'm sure that may cause a number of different issues that we don't want to be seen as responsible for

The headless version should also make the check as at least all of the scripting modules are still heavily reliant on X11 tools and libraries.

sebastiansam55 commented 3 years ago

@josephj11 and @BlueDrink9 if you have feedback/thoughts on phrasing

nevarek commented 3 years ago

Can you embed links in the popup?

Yes we can. We could add a page to the wiki here to document the details of the compatibility issues and links to information about how to change display servers on different distros.

BlueDrink9 commented 3 years ago

Autokey has detected that you are ~not~ using the Wayland Desktop Environment. Autokey is currently only officially designed to work on X11.

Maybe add

For more information, it might be helpful to consult the documentation for your desktop environment (e.g. Gnome or KDE Plasma)
josephj11 commented 3 years ago

With the "not" removed, it's OK, but it's not about how AutoKey was designed, it's that most or all of it just won't work under Wayland. So, maybe: AutoKey is currently incompatible with Wayland. It will still work if you enable X11 instead.

MaxPeal commented 3 years ago

loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type | awk -F= '{print $2}'

just as note: with

loginctl show-session "$(printf '%s' "$(loginctl)" | awk '/tty/ {print $1}' )" -p Type | awk -F= '{print $2}'

it will also work in a posix shell / dash

josephj11 commented 3 years ago

@MaxPeal Nice. Worked in my terminal.

josephj11 commented 2 years ago

Bump! This is getting more critical as Wayland is becoming the default in popular distros.

josephj11 commented 2 years ago

Wayland is taking over the world. We need this band-aid implemented ASAP to keep (potential) users from wasting a lot of time and giving up on AutoKey when they could still use it if they are willing to use X11.

josephj11 commented 1 year ago

Just tried the above commands and they didn't work on kubuntu 18.04. I got no output.

Rather than debugging it, I wrote a new script. It can obviously be improved and condensed, but it works.

#!/bin/bash
## window_manager
session=$(loginctl | awk '
NR != 2 {next}
{print $1}')
wm="$(loginctl --no-pager show-session $session -p Type)"
echo -n "Your window manager is "
cut -c 6- <<<"$wm"
Elliria commented 1 year ago

Does echo $XDG_SESSION_TYPE work for you, @josephj11?

sebastiansam55 commented 1 year ago

I've been informally using the XDG_SESSION_TYPE as a check in some of my WIP stuff. Please do update this if you find that is not always set to x11 for Xorg and wayland for Wayland display server.

Admittedly most testing has been in ubuntu variants but I had thought that variable would be "cross-distro"

josephj11 commented 1 year ago

echo $XDG_SESSION_TYPE works fine for me and says x11. I don't do anything with Wayland - especially since my main notebook is still on kubuntu 18.04 and I don't think Wayland was entirely house broken in that release. I didn't know about that environment variable.

Elliria commented 1 year ago

I think it probably works in any distribution, but we may want to intentionally seek out folks who use other operating systems before deciding to use it in AutoKey. Then again, AutoKey could use a conditional statement that, if it doesn't get one of two expected responses, tries a different way of doing the test, and we could put several different tests together like that to hopefully satisfy any of the distributions.

josephj11 commented 1 year ago

It might take several tests. I'm not sure, but that other method I was using with loginctl might be part of systemd - the init system so many users love to hate.

Elliria commented 1 year ago

Yeah, I don't think there'd be any harm in making a conditional statement that's written to look for very specific responses from each of the tests that it does and stops when it gets a valid one or continues on to the next one when it doesn't. That way, if different distributions require different commands, then we can accommodate all of them. Now it's a matter of finding out what works and doesn't on platforms that we know AutoKey runs on. We don't happen to have a list of those, do we?

josephj11 commented 1 year ago

Now it's a matter of finding out what works and doesn't on platforms that we know AutoKey runs on. We don't happen to have a list of those, do we?

I don't think so, but this is where to start.

Elliria commented 1 year ago

That worked great. Here are my results and I'd appreciate some input on the ones that I found to be invalid, because I may be wrong about that on some of them:

These are invalid:

These can use $XDG_SESSION_TYPE:

echo $XDG_SESSION_TYPE

Important: This should be a user command and not be run as root, because it will fall over in Fedora and produce no output (and may behave in unexpected ways in other distributions) if run as root.

josephj11 commented 1 year ago

IDK how you figured that out so quickly!

PyPI is not an operating system/distro, so I'm not sure why it's in your list at all. It's a way to get and install AutoKey, but it does not affect the environment in which it runs. I've never heard of the other three and can't research them ATM.

Elliria commented 1 year ago

I used the list that you linked to above, replaced FOO in this Google search with each of the names on the list one by one in Firefox, and then read some of the pages in the results to verify whether or not people said the command worked for them:

"FOO" "echo $XDG_SESSION_TYPE"

One of the Fedora pages in my search results mentioned that if you do the command as root in Fedora, you won't get any result at all, so I figured I'd note that, too, because it's caused some confusion elsewhere where people simply assume the command won't work at all even though it works fine if done as a user.

PyPI was on the list, as were the others. I'm not sure why those are there. I know that PyPI is a repository and that you can get software from it, but that that's a "Linux Distributions" list, so perhaps that and the others should be removed. That list is generated by repology, so it's beyond our control, although we could try reaching out to them.

Elliria commented 1 year ago

There's another Wayland/Xorg wrinkle for us to be aware of:

By the way, as part of researching this, I found references to NVIDIA forcing Xorg even when Wayland is chosen as the session type on log-in. I have to wonder if some of the issues that are encountered are as a result of a person having (intentionally or otherwise) chosen a Wayland session, but then having been given a forced Xorg session instead, perhaps causing some parts of the system to misbehave as a result of a possibly-unclean override.

The misbehavior part is purely me making a wild guess, but it's based on my use of an NVIDIA card and the fact that although I adore the NVIDIA hardware, I can see (from some ongoing issues I've had for quite some time now) that the way the NVIDIA team creates and/or maintains some of its driver code can seem either sloppy or as though they don't care about some of our issues, so it's not much of a leap to go from that to imagining that they might perhaps not have gotten the override code just right.

TLDR: Where I was going with all of that is that it may be vital for users to deliberately choose a Xorg session on log-in even if they've done a command-line test that told them they're using one already, because it might not be a genuine one.

josephj11 commented 1 year ago

Usually, any command that needs to be run as root will either be prefixed with sudo or shown with a prompt that ends with a # which is the default root prompt suffix.

I can't think of anything (other than a system wide install of AutoKey and dependencies) that would ever need root access, so I'd be inclined to leave that out.

Another generic piece of advice is never run anything as root unless it says you have to, you know what the command really does, and, in general you either know what you're doing or really trust the source where you got the command - preferably all of the above.


I think PyPI is valid on the original list when viewed as places where you can get AutoKey and what version you'll get if you do use them.


There's a reason Linus literally cursed out Nvidia. LOL

I have always selected computers that use Intel graphics. I probably can't tell the difference in quality, but they never seem to have driver issues like Nvidia and Radeon very often do. And, less fancy graphics probably means longer notebook battery life. But I don't do any gaming or graphics work. This notebook still has a 720P screen although any new one I get will be higher res, but mainly because I'm tired of having black bars above and below a lot of videos I watch.

As for a partial Xorg of some sort running: Stranger things have happened, but the inordinate amount of work I assume would be necessary to create and maintain Frankenstein's Bride makes me doubt they would attempt it for a system they only grudgingly support at all.

But, if they experience weirdness with the "forced" Xorg, they should definitely try the login setting to see if it makes any difference.

Elliria commented 1 year ago

I can't think of anything (other than a system wide install of AutoKey and dependencies) that would ever need root access, so I'd be inclined to leave that out.

I mentioned it as clarification of the widespread confusion I found online over the belief that the echo $XDG_SESSION_TYPE command can't be used in Fedora and also because we're considering using that command in AutoKey to test for Wayland and I wasn't sure whether AutoKey would be doing that as the user or root.

I think PyPI is valid on the original list when viewed as places where you can get AutoKey and what version you'll get if you do use them.

I can understand why they included it, but I'm still calling total shenanigans on it, because it's a list of distributions.

I have always selected computers that use Intel graphics. I probably can't tell the difference in quality, but they never seem to have driver issues like Nvidia and Radeon very often do. And, less fancy graphics probably means longer notebook battery life. But I don't do any gaming or graphics work. This notebook still has a 720P screen although any new one I get will be higher res, but mainly because I'm tired of having black bars above and below a lot of videos I watch.

I'm not sure about your notebook battery life, but I require an NVIDIA card for what it can do that the others can't, so I suffer with the driver issues and will have to remain aware of the potential for a Wayland/Xorg issue as the result of having one.

As for a partial Xorg of some sort running: Stranger things have happened, but the inordinate amount of work I assume would be necessary to create and maintain Frankenstein's Bride makes me doubt they would attempt it for a system they only grudgingly support at all.

They do force Xorg. What remains to be seen is what's involved with that and, if it's intricate, how well they manage to do it.

But, if they experience weirdness with the "forced" Xorg, they should definitely try the login setting to see if it makes any difference.

Yeah. It may be worth it for folks to try if nothing else is working.

josephj11 commented 1 year ago

I can't think of anything (other than a system wide install of AutoKey and dependencies) that would ever need root access, so I'd be inclined to leave that out.

I mentioned it as clarification of the widespread confusion I found online over the belief that the echo $XDG_SESSION_TYPE command can't be used in Fedora and also because we're considering using that command in AutoKey to test for Wayland and I wasn't sure whether AutoKey would be doing that as the user or root.

AutoKey does not and should not require/use elevated permissions for anything. (A user script could do whatever they want as long as they handle the authorization and security implications somehow.)

I wasn't aware of the Fedora thing. If you think it helps, then it's fine with me.

Elliria commented 1 year ago

Good. If AutoKey won't use elevated permissions, we don't have to worry about it. The mention was only intended for these issue comments so that it would be findable if anyone ever went searching for it. It also wouldn't hurt for us to be aware of it so we can do damage control if it comes up elsewhere.

Now all that's left is to figure out what DPorts is and whether echo $XDG_SESSION_TYPE will work in it. If so, then we can be pretty certain that that's the command we need to squeeze into AutoKey somewhere to get it to do that check. I sent an email to the maintainer listed for DPorts on the Repology page that generates the list we use and asked. Maybe he'll know.

josephj11 commented 1 year ago

Never saw Dports before. From a brief scan, it appears to be one or more repositories for BSD (UNIX). BSD is an OG distro world from the beginning of time - maybe even before Linux. It is niche these days and is known primarily for having very tight security.

AFAIK, we have never encountered an AutoKey user from that universe. First contact would be memorable.

Elliria commented 1 year ago

I got a very quick response from the maintainer/author and he said he's not sure, but will look into it.