Using Barrier w/ Kinto

[agoddard]

This project is incredible, and really makes such a huge difference when setting up a new linux machine, and swapping between linux + mac. It's just so well done, thank you so much!

I've been using Kinto for a while with a Mac keyboard, and recently tested it out using a shared keyboard via Barrier - if I connect the Mac keyboard directly to the linux workstation, Kinto works perfectly, however if I connect the keyboard via Barrier, it doesn't seem to work (I've tried re-running setup, restarting the service, etc). The Kinto readme contains a link to Barrier, and the Barrier project references Kinto, so it seems like there's a way to get them working together but I have been unable to figure it out and I'm wondering if there's something I might be missing? If there is and I can get it working, I'd love to contribute some docs to help others using both tools.

Thanks again 💯

[rbreaves]

Thanks! When I was compiling that list I had also added applications that I hadn't actually tested w/ Kinto, although I suspected that Barrier would have worked just fine, but apparently not.

I am not really sure why it fails to work, but it has something to do with how it hooks into the kb input I am sure. You might have some better luck with it if you were to install the older Kinto v1.1 based on xkb instead of xkeysnail. If that does work though then please let me know - I may consider bringing back limited support for the xkb method if I find that there's a good reason to do so.

The xkb method much more complicated to update and maintain, adding individual hotkeys per an app tends to be more complicated compared to using xkeysnail. The difference btwn a python wrapper for /dev/uinput, which is pretty low level, w/ a simple python config file vs xkb using my c written app w/ xkb (setxkbmap) custom config files & json config.

I will be closing this ticket, but if you or someone tests against the older Kinto app on the destination pc I may reconsider opening this up. I ran xkeysnail manually on a linux client just now with barrier and I do not see any virtual keyboard devices, so I don't really have anything to manually target either via xkeysnail. Sometimes keyboards don't get picked up by xkeysnail and users can set that manually if they edit some files/parameters.

[rbreaves]

I have added a note in the readme so users will be aware that Barrier does not actually work with v1.2+ but might work w/ 1.1.

A possible work around may be to use VNC, Anydesk, or RDP (the RDP client from a Windows machine in particular, linux and macOS RDP clients appear to have issues w/ the Win/Super key not being reliable).

I would really like to resolve the issues with Barrier - but atm I am not sure where to start to get it to work with Xkeysnail. Seems there was already an issue opened with xkeysnail about this, no solution though. mooz/xkeysnail#95.

[agoddard]

@rbreaves Thanks! The behavior seems the same when running Kinto 1.1-8. I like Kinto enough that I'll probably just ditch Barrier until it starts working with xkeysnail, I'll keep an eye on that xkeysnail issue.

[rbreaves]

Thanks for reporting back.

I was kinda hoping that xkb/setxkbmap would work around the issue, but I guess the way Barrier hooks into the keyboard evades both xkeysnail and xkb which sorta surprises me.. I honestly didn't think it got much lower level than xkeysnail since it manipulates something called uinput for keyboard input, but maybe there is a more direct kernel level way of doing it that Barrier does, I am not sure.

[agoddard]

I'll keep testing, because using Linux as the server in barrier (with Kinto) and macOS as the client still doesn't work right, which seems weird too.

[agoddard]

@rbreaves I tested this w/ flipping the server and the client - so the linux machine running Kinto was the barrier server, and macos was the client. Keys then worked fine remapped in Linux, but the keyboard behavior was wrong on macos. I'm not sure if that might point to where the issue is. I replaced Barrier with a KVM because my linux machine is basically unusable without Kinto 😂 but I'm happy to keep testing if I can help

[fracture91]

@agoddard This is hacky, but I was able to get things working decently by killing xkeysnail whenever my mouse moved to the client macos system, and then restarting it when the mouse moved back 😬 Just make sure not to touch your keyboard too quickly after the switch, haha

See this commit: fracture91/dotfiles@21d0e91

tail -fn0 ~/snap/barrier/current/barrier.log |
  grep --line-buffered -o -e "entering screen" -e "leaving screen" |
  while read -r line; do
    case "$line" in
      "entering screen")
        sudo systemctl start xkeysnail
        ;;
      "leaving screen")
        sudo systemctl stop xkeysnail
        ;;
      *)
        echo "Unhandled keyword ${line}" >&2
        exit 1
    esac
  done

[agoddard]

@fracture91 woah, that's wild! Will definitely check it out, thanks!

[rbreaves]

@fracture91 that does look nice! Wonder if that should be integrated w/ xkeysnail directly. I may open a ticket w/ them & look at adding that via python.

[rxng]

just wanted to say this is absolutely the best workaround so far @fracture91 . I cannot be grateful enough for this.

please make it official @rbreaves !!

[brandhsu]

Hi @rbreaves was wondering if this feature or another similar workaround was ever merged. Thanks for the awesome contributions!

[rbreaves]

One hasn't but it probably does need some work done on it.. I can't give an ETA on that though. It's not a situation I really deal with in my daily workflow as I am more likely to do things inside of RDP sessions than anything else when involving multiple PC's. I am certainly open on accepting, or reviewing any PR that comes to me with a fix that is ready to be merged more or less.

I know my readme is also quite extensive on RDP solutions as a result of my own workflows. Can be helpful for mac to Windows, and even Linux but it does require an older version of Kinto on linux - v1.0.7-3 when doing RDP stuff & possibly barrier stuff as well - although re-reading the above it appears the workaround was for the latest - xkeysnail iteration of kinto so I guess it may work either way.

I suspect if your host keyboard and mouse is on Linux then xkeysnail will work with that script above - if your destination is linux though then look at v1.0.7-3 because I doubt xkeysnail's iteration will work with anything but a physical mouse and keyboard.

[dupsatou]

Just installed Kinto and immediately found relief that was frustrating me in my new Linux setup with my Apple wireless keyboard. Until I moved my mouse off the screen into my Mac environment connected via barrier :( Any movement on this at all? Any strong workarounds? This unfortunately may become a deal breaker on what is otherwise a great setup. Either way, thank you for putting this out there!

[RedBearAK]

@dupsatou

I've never used barrier, but I'm curious about what happens with the window attributes when moving into the barrier area.

This may not work, and you may need to install xprop first, but if you run this in a terminal it should turn your mouse cursor into a cross every few seconds and let you click on a window to see the relevant window attributes. You'll need to go back to the terminal and Ctrl+C (or Cmd+Dot) to stop it.

Hopefully this will still work when the mouse cursor is in the barrier area and it will show what the window attributes are. I don't know how barrier works, but surely it still needs to create a window of some kind on the client side, so you can see the remote computer screen.

while true; do xprop WM_CLASS _NET_WM_NAME; sleep 3; done

[dupsatou]

Interesting, when trying to run that it prevents me from crossing over in to the other screen. To be clear, if this isn't known, barrier basically is the open sourced fork of Synergy. It's very, very similar to Synergy.

Using that command in a terminal though seems to effectively block Barrier from working.

[RedBearAK]

Using that command in a terminal though seems to effectively block Barrier from working.

What if you do the sleep first and then let the xprop command run after you've had time to move the mouse cursor into the barrier area? This may not accomplish anything, but:

sleep 6; xprop WM_CLASS _NET_WM_NAME

And then click in the barrier area even if you don't see the cursor change to a cross. See what happens.

If it's that the barrier area is simply not part of the X server display (although I don't know if that's even possible) or those window attributes aren't available, that should mean that there would be an X context error when the keymapper attempts to get the window attributes while barrier has the keyboard focus. Which may mean that switching to using keyszer could be a solution to this, as it is a solution to other issues with xkeysnail. Because keyszer has a better response to problems with the X context, and just stops doing any remapping while the context error continues. This might mean that it would just passively stop messing with things whenever the cursor wanders over to the barrier part of the screen. Which would theoretically be a usable solution to the problem.

Don't get the idea that I really understand most of this stuff, but I did get a branch of keyszer working in a Wayland+GNOME+extensions environment so I've been looking at the code a lot.

There are some instructions in the comment linked below to converting over to using keyszer. A few people have been able to follow it successfully. I'm trying to come up with a full installer that will set up keyszer and a working Kinto-like config, but it won't be ready for a while.

#750 (comment)