Open kostrykin opened 3 weeks ago
Were you actually in a TTY (virtual terminal) at the time? Not logged into a graphical desktop environment? Toshy is designed to only be active in a graphical session. I’ve never seen that error in a graphical session.
No, I was on the default Ubuntu 22.04 terminal app, I think it's gnome-terminal
So you're just in a regular Ubuntu 22.04 desktop environment (GNOME), and probably logged into Wayland (that's been the default session type for a long time). But you're remoting in with NoMachine. That's probably going to mess with the way the modifier keys work. Many remote desktop apps fail to pass certain keys like the Meta/Super/Win/Cmd key. I'm not sure how that's going to work out.
Yet I don't know how that would cause the session type to be detected as "tty" unless you had some non-standard desktop environment. I've literally never seen that come up as "tty" in hundreds of tests on all sorts of different Linux distros and desktop environments. Even a tiling window manager should have the session type set to either "x11" or "wayland".
Can you do this and see what comes out?
echo $XDG_SESSION_TYPE
If it still says "tty" you can try to set it to "wayland" manually before running the Toshy setup script. But, without knowing why it would say "tty" in the first place, Toshy still wouldn't necessarily work after installing, if it just saw "tty" as the session type every time it tried to start.
export XDG_SESSION_TYPE="wayland"
Give it a try to at least get through the install. But unless this is caused by NoMachine, I really don't understand what's going on.
I may have to modify the environment module to keep it from raising the EnvironmentError exception in this case.
In the Downloads folder where the Toshy install files were extracted (usually "toshy-main"), you can open up lib/env.py
and look for this:
if SESSION_TYPE not in ['x11', 'wayland']:
raise EnvironmentError(f'\n\nENV: Unknown session type: {SESSION_TYPE}.\n')
Then change it to this:
if SESSION_TYPE not in ['x11', 'wayland', 'tty']:
error(f'\n\nENV: Unknown session type: {SESSION_TYPE}.\n')
This will let the install proceed without the immediate error, but if that value is still "tty" once the keymapper tries to start, the keymapper will have no idea how to get the window context.
There is a way in the config file to override any part of the detected environment, but that's basically never been used by anyone that I know of. Before trying that, I'd like to figure out why the session type comes up as "tty".
I can't replicate the "tty" session type, even after installing Ubuntu 22.04.4 LTS in a virtual machine and remoting into it with NoMachine.
Unless you can think of something unusual about your Ubuntu install that might be causing this, I have no idea what's going on with that session type coming up as "tty". That's really not normal.
@kostrykin
Can I ask if you start your desktop environment manually, without using a display/login manager like GDM or SDDM? I'm seeing this "tty" session type when manually starting miracle-wm-session
on a new Fedora 41 spin. Never seen it anywhere else.
Problem observed:
Following the instructions for installation: https://github.com/RedBearAK/toshy?tab=readme-ov-file#how-to-install