Open sebastiansam55 opened 3 years ago
I have some questions answered in order to finish work on this one
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.
@josephj11 and @BlueDrink9 if you have feedback/thoughts on phrasing
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.
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)
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.
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
@MaxPeal Nice. Worked in my terminal.
Bump! This is getting more critical as Wayland is becoming the default in popular distros.
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.
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"
Does echo $XDG_SESSION_TYPE
work for you, @josephj11?
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"
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.
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.
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.
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?
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
I got a very quick response from the maintainer/author and he said he's not sure, but will look into it.
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
orx11
)I'd slap this in a function in
UI_common_functions.py
with asubprocess
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 thecheckRequirements()
function in the same file.