(Question) Any success or ideas for using from AWS Workspaces

[palexander-agathos]

First off, thank you for all of the work you have done on this. It's super impressive, and scratches the exact itch I've had trying to move back and forth between OSX and Linux.

Most recently, I'm using an Ubuntu AWS Workspace machine in a highly restricted environment. I have no problem getting toshy installed, but it doesn't seem to do anything or capture input when I look at the debug mode.

Any ideas on where I can poke at next? Clearly Workspaces are doing something to translate my local keyboard, but when I look at the keyboard widget in Gnome, I can see that my key presses show the right keys on the keyboard, so I'm open to digging in. I've work in python, so I'm comfortable poking around too.

Here's my debug info:

toshy-devices

``` palexander@U-1N62XYIA4WDZ2:~$ toshy-devices List of devices seen by the keymapper (keyszer): keyszer v0.7.1 -------------------------------------------------------------------------------- Device Name Phys -------------------------------------------------------------------------------- /dev/input/event0 Power Button LNXPWRBN/button/input0 /dev/input/event1 Sleep Button LNXSLPBN/button/input0 /dev/input/event2 AT Translated Set 2 keyboard isa0060/serio0/input0 /dev/input/event3 ImPS/2 Generic Wheel Mouse isa0060/serio1/input0 /dev/input/event4 Keyszer (virtual) Keyboard py-evdev-uinput ```

toshy-env

``` palexander@U-1N62XYIA4WDZ2:~$ toshy-env (EV) Toshy env module sees this environment: DISTRO_NAME = 'ubuntu' DISTRO_VER = '22.04' VARIANT_ID = 'notfound' SESSION_TYPE = 'x11' DESKTOP_ENV = 'gnome' DE_MAJ_VER = '42' ```

toshy-config-verbose-start

``` palexander@U-1N62XYIA4WDZ2:~$ toshy-config-verbose-start Stopping Toshy systemd services... Toshy systemd services stopped. non-network local connections being added to access control list keyszer v0.7.1 (DD) CONFIG: /home/palexander/.config/toshy/toshy_config.py (DD) THROTTLES: Pre-key: 12ms, Post-key: 18ms (DD) No Synergy log folder found. No log observer will be engaged. (CG) Current settings: ------------------------------------------- calling_module = 'toshy_config.py' db_file_path = '/home/palexander/.config/toshy/toshy_user_preferences.sqlite' ------------------------------------------- gui_dark_theme = True ------------------------------------------- override_kbtype = 'Auto-Adapt' ------------------------------------------- optspec_layout = 'US' ------------------------------------------- forced_numpad = True media_arrows_fix = False multi_lang = False Caps2Cmd = False Caps2Esc_Cmd = False Enter2Ent_Cmd = False ST3_in_VSCode = False ------------------------------------------- (CG) Toshy config sees this environment: DISTRO_NAME = 'ubuntu' DISTRO_VER = '22.04' SESSION_TYPE = 'x11' DESKTOP_ENV = 'gnome' DE_MAJ_VER = '42' (DD) ENVIRON: Session type: 'x11', Desktop env: 'None' (DD) Zenity command path: '/usr/bin/zenity' (--) WATCH: Watching for new devices to hot-plug. (--) Autodetecting all keyboards (--device not specified) (+K) Grabbing 'AT Translated Set 2 keyboard' (/dev/input/event2) (+K) Successfully grabbed 'AT Translated Set 2 keyboard' (/dev/input/event2) (--) Ready to process input. ```

The (DD) ENVIRON: Session type: 'x11', Desktop env: 'None' caught my eye because there is no desktop env, but I could not figure out where this was being emitted from nor how I could alter it.

Let me know if I can provide anything else, and thanks again!

[RedBearAK]

@palexander-agathos

That "ENVIRON" line comes from the API function within the keymapper's config_api module. But the keymapper uses Xlib for the window context in X11, so it doesn't need to know what the desktop environment is (unlike the ongoing nightmare of Wayland compositors that need their own custom window context methods). So seeing None there is not a problem. The desktop environment info gets automatically discarded if the session is X11.

So this Workspaces thing is like a virtual machine? I'm not familiar with the environment.

I suppose there's no further output in the verbose logging, as if the keymapper doesn't see any of the input after it starts up?

Take a look at the permissions on /dev/uinput, and did you see anything in the logging when the installer script was setting up the udev rules file?

$ ls -la /dev/uinput

crw-rw----+ 1 root input 10, 223 Mar 20 01:11 /dev/uinput

Was your user successfully added to the input group, and does /dev/uinput show read-write permissions for the input group rather than being owned by root:root? What about the ACL permissions? Try getfacl.

$ getfacl dev/uinput

getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
user:kris:rw-
group::rw-
mask::rw-
other::---

I haven't actually noticed this working yet, but I added TAG+="uaccess" to the udev rules file very recently, maybe that would make a difference. But if the environment is restricting the installation or parsing of the rules file entirely, I'm not sure what you can do.

Unfortunately I don't have that deep of an understanding of exactly how the keymapper and input system works, I mostly just followed other people's instructions to get it functioning. So I'm not sure what else to look at.

[RedBearAK]

@palexander-agathos

It's weird that there's no error from the keymapper. Ordinarily if the uinput module wasn't loaded or there was a permission issue with /dev/uinput, the keymapper would complain, but it just says "Ready to process input", which normally means everything should be fine.

I feel like I've seen something like this before, but I'm not sure what the cause was or what could fix it.

[palexander-agathos]

Thanks for the helpful feedback @RedBearAK. You're right, the AWS Workspace is a cloud-hosted virtual machine. Unfortunately, I'm not sure what virtualization technology it is using or what it might be analogous to.

In terms of all of the uinput expected values, mine match what you posted, so I think everything is ok there. My user is in the input group, and I don't see anything indicating that there are permission issues there.

It's good to isolate the issue to keyszer. I was able to try evtest, which reads the list of possible keyboard events for my device properly, but does not capture any input. xinput, on the other hand, does capture keypress events just fine. xev also captures keypress events just fine. Unfortunately, I'm not at all familiar with how this works, so I'm not sure what it indicates that evtest doesn't work but the other two do.

At any rate, since it seems like it's outside your project, I'm happy to keep poking around as I have time and if any new information comes up, I'll update here. Feel free to close the issue if it helps keep clutter down.

Thanks again for all the help!

[RedBearAK]

I’ll leave it open for now since it does affect the ability to use Toshy in that environment. But it does seem focused on the keymapper itself.

You might want to go directly to the “evdev” issues and ask about this. I think they are on GitHub. Or search the web for references to evdev and AWS Workspaces. Seems a little out of my expertise range.

Let me know if you ever come up with anything.