Wayland support? [Donation target met]

[JaneSmith]

Added by one of the maintainers of Barrier, @p12tic:

Please support this bounty to get Wayland support in Barrier

---

A bounty for Wayland support has been posted to BountySource here. EDIT: $2550.42 has been collected, thus meeting the goal of $2000, but not the goal of $5000.

As promised here, I @p12tic will start working on Wayland support within 3 months of the moment when $2000 is collected. I will start working on this feature immediately as soon as $5000 is collected. The higher amount is collected, the higher priority this will be given.

---

Original issue

Is there any work being done to support Wayland?

The README file states "We will also have our eye on Wayland when the time comes", but to me the time has already long come and past. Distros ship Wayland by default now. Desktop environments like KDE have a feature freeze in place for X, with all focus being on Wayland now. New WMs/DEs are being made for Wayland only (e.g. Sway and Way Cooler). The upcoming Librem 5 phone will be running Wayland only. It's all full steam ahead with Wayland on Linux.

Synergy has been promising Wayland support literally for years. Their last comment was that it was "coming soon", almost a year ago. They seem to have nothing to show it and even locked the threads discussing the issue. They're advertising a paid product supporting Linux, when in fact it doesn't at all if you're using modern Wayland. This seems like false advertising. There are other issues with Synergy, such as encryption being a paid feature, the feature creep, etc. Therefore I'm looking to Barrier instead.

So can we get Wayland support with Barrier? Is it technically possible to implement? I am aware that Wayland's limited feature set and increased security could possibly cause problems. Could we get an actual discussion going about this? Or a status update? Thanks a lot in advance.

[p12tic]

Hey, Barrier does not currently support Wayland. It should be technically possible, but for that to happen someone needs step up, investigate and implement that. Barrier is a community-driven project, there's no one to complain to and doing so might be counter-productive :-)

Like in all similar projects, a particular feature is usually implemented when some user who is a skilled programmer gets fed up and spends several weekends working on it.

[walker0643]

I don't have the time to invest into Wayland development. At least, not as much as would be required to lead it. I would, however, be willing to dedicate a branch for this purpose if there were sufficient developer interest.

[walker0643]

Reopen if a dev wants to tackle a wayland branch.

[BrendanBall]

Would we be able to implement Linux support with uinput so that there's just a single implementation needed? FreeBSD does seem to have uinput as well, all though there doesn't seem to be much documentation around it.

[chriselrod]

https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Maintenance-Mode-Quickly

X.Org is going into maintenance mode in favor of Wayland. Seems like we may need Wayland support eventually.

[valpackett]

FreeBSD does seem to have uinput as well

Indeed we do :) It only works for GUI, but it's not like the current X implementation can type into the plain console.

BTW, https://github.com/Blub/netevent is a good uinput forwarder. Not smoothly moving the mouse across devices, just toggles between devices based on a key, but still works nicely.

[frague59]

+1 for netevent

[kayasoze]

All mainstream Linux distributions now default to Wayland on GNOME. This would seem to be a high priority.

[BrendanBall]

I've already started playing with uinput, but I'm currently stuck on getting mouse movements to work because they're absolute, not relative. I haven't looked much at netevent, but I would assume it uses relative mouse events because it doesn't need a smooth crossover from one machine to another. I've only tested so far in Xorg because my barrier server is still on i3, where my barrier client is on sway. Uinput should be universal, so it should work in both Xorg and Wayland, but I should probably just check if the absolute mouse events are also broken in Wayland. If it's not possible to get absolute mouse movements to work through uinput then it's kind of a dead end.

[AdrianKoshka]

Thanks for the effort you're putting in @BrendanBall! As for @kayasoze, developer resources need to be diverted to more pressing issues right now like memory leakage. And keep in mind, there's currently not many active developers on the project. We have a lot of users, but not many developers. While wayland support would be appreciated, I think fixing more pressing issues is of higher priority.

[EbonJaeger]

All mainstream Linux distributions now default to Wayland on GNOME.

No, they don't. Ubuntu hasn't since 18.04. Doesn't look like Manjaro does either, but they can't seem to agree on if it does or not. I believe only Fedora uses Wayland by default, and only for some configurations (Nvidia non-free drivers cause problems with Wayland).

Time is definitely better spent on fixing current bugs, as @AdrianKoshka said.

[ramereth]

FWIW Debian 10 now defaults to Wayland (which is why I'm watching this issue).

[BrendanBall]

I didn't realize there's only one developer :( . I'm unfortunately not a C++ developer, so won't be contributing code directly in the foreseeable future. I have however spent a lot of time reading lots of the code (which was quite daunting) mainly to understand the protocol, as I've taken the opportunity to port barrier to rust (client for now) purely for my own gain (learning rust). I will however contribute any learnings on how to support Wayland via uinput etc in some kind of doc if I actually manage to figure some things out. I am also not spending much time on it currently, so it will progress quite slowly.

Sounds like we need to put the word out there that this project could do with some more developers though.

[shymega]

Not all DEs or WMs default to Wayland. Neither do all distros. The fact remains that we have ~141 issues, and time needs to be better spent working on these issues, and then we can work on Wayland support. However, that said, if anyone wants to contribute a PR adding Wayland support that's clean, safe, and doesn't cause major breakages, they are welcome to do so.

[AdrianKoshka]

@BrendanBall One was a bit misleading on my part originally. Sorry about that, I have since fixed the comment.

[AdrianKoshka]

Also to add to what @shymega said, there's now a wayland project

[kayasoze]

It appears I am mistaken about Ubuntu--it does not yet enable Wayland by default. Arch and Clear Linux do.

While I realize that there are other bugs outstanding, Barrier is at least usable. For Wayland users, it doesn't work at all. In severity, that is a bug that seems to trump all others, but if someone can point to an issue that is worse for users than "doesn't work at all," I'd like to see it. As it stands now, users will uninstall the package and move on, so fixing this is important if Barrier wishes to remain relevant.

[shymega]

I'm not convinced that Wayland is a severe issue. Yes, its not ideal to not have Wayland support; I completely understand. But there's a lot of other issues that are yet, more important. We have two bug reports about a memory leak, another about a segmentation fault - these are more important.

[BrendanBall]

So I just managed to successfully move my mouse around in wayland (barrier client) using my very minimal wip rust client port. I have a minimal C prototype for setting up the virtual mouse and sending some events. If a C++ developer interested in wayland support is keen to start prototyping, that should be enough to get started.

[shymega]

Well, I'd prefer to stick with C++ at the moment, but the C prototype would be best ported to the existing C++ codebase.

With regards to Rust, I don't think it has good support on FreeBSD at this moment in time, from what I'm aware of?

Just my thoughts... :)

On this date - Wed, Aug 28, 2019 at 09:00:32AM -0700, Brendan Ball wrote:

So I just managed to successfully move my mouse around in wayland (barrier client) using my very minimal wip rust client port. I have a minimal C prototype for setting up the virtual mouse and sending some events. If a C++ developer interested in wayland support is keen to start prototyping, that should be enough to get started.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/debauchee/barrier/issues/109#issuecomment-525810650

-- Sincerely, Dom Rodriguez (shymega/dzr).

[valpackett]

Rust has very good support on FreeBSD.

[BrendanBall]

@shymega I'm in no way trying to push Rust onto this project or anyone else. At this point it's just a playground for me to learn Rust. As mentioned previously, I'm not a C++ developer so won't be directly contributing C++ code, hence the C prototype which you'll obviously port to C++ in this codebase. It's purely there for reference on how the uinput interface is used. Consider it documentation. I'm happy to help write up developer docs on how to use uinput (which honestly at this point is just this C prototype and maybe a few links to some linux doc comments) and whatever else is needed to support wayland, so that whoever eventually supports wayland in this codebase has an easier time with the implementation. If you can tell me the best place to put such resources, I can contribute any useful info that I learn along the way that isn't specific to Rust (possibly the wiki? but last time I checked barrier's wiki is lacking compared to the original synergy wiki because that doesn't just get copied over in a fork, so I'd prefer contributing it to the actual codebase somewhere.)

Unless FreeBSD has the same uinput interface as linux, it will probably be a lot of extra work supporting that as well, but I know nothing about FreeBSD.

[AdrianKoshka]

@BrendanBall we do have https://github.com/debauchee/barrier-wiki which is meant as a more publicly accessible way to "edit" the wiki via PR (it gets folded into this repos wiki eventually). and wikis on repos are just git repos, so I'm sure you could find some way to clone the synergy wiki and contribute to our documentation.

[valpackett]

@BrendanBall yes, we have uinput. I wrote evscript on FreeBSD.

https://github.com/myfreeweb/evdev/commits/uinput ← my fork of the evdev crate adding uinput

[BrendanBall]

@myfreeweb I'm still pretty new to all the low level interfaces and systems, you seem to know a lot more. Currently I'm using uinput straight without libevdev. I'm not sure what the difference is between going through libevdev for uinput and just using uinput straight, and whether libevdev is more or less supported. So basically for this codebase, is using that uinput C prototype wrong and should instead go through libevdev?

[valpackett]

It's not wrong but libevdev is higher level, more convenient for sure. libevdev is available everywhere and is well supported, it's a dependency of libinput.

[manfreed]

How far this project diverged from Synergy? They promised Wayland support for the next major version, so getting that from the upstream could be a solution.

[brianjmurrell]

I'm not sure I understand the Closed status of this ticket. AFAIU, there is no Wayland support in barrier, so why wouldn't there be a ticket open about that? An open ticket is not a "demand" for work. It's simply a book-marker of something that needs doing/doesn't work/etc.

This ticket already has the Help Wanted and Enhancement labels. Surely that is enough for people to correctly understand the status of the feature in an Open Issue.

[AdrianKoshka]

There's a project open for it. https://github.com/debauchee/barrier/projects/1

[brianjmurrell]

@AdrianKoshka But projects are just specially highlighted tickets, like this one, which is the ticket for the project. So why is it closed, unlike the other two projects on the project board:

whose tickets are still open.

[kendling]

Everyone, I found the x2vnc http://fredrik.hubbe.net/x2vnc.html can work on wayland!!

Can we migrate that keyboard/mouse hook for barrier?

But still some problem with it.

e.g: Can't catch super/PrtSc key.

[kendling]

The barrier/synergy can use in wayland in a little tricks. The mouse can move out when the GTK window in the edge of the screen.

e.g: I maximum the firefox window on gnome, now I can move out the cursor at left/right/bottom edge of screen. So I can config the another screen at left/right/bottom of server.

BTW: You can move out the cursor even active wayland window (wayland window not override the left/right/bottom edge of screen, depending on your barrier config).

My config:

1. Config the another screen right-side at server screen.
2. Maximum the firefox and let it shown.
3. If using wayland application, didn't maximum or override the right edge of the screen.
4. Now I can move out the cursor at right edge everytime.

[kallisti5]

The barrier/synergy can use in wayland in a little tricks. The mouse can move out when the GTK window in the edge of the screen.

LOL. So that's what's happening. I'm running Barrier on Fedora with a Haiku client, and dragging my mouse over with terminal full-screen doesn't work. As long as you have an X11 app next to the edge of the screen it gives you a "tunnel" to your other systems :laughing:

[kendling]

The barrier/synergy can use in wayland in a little tricks. The mouse can move out when the GTK window in the edge of the screen.

LOL. So that's what's happening. I'm running Barrier on Fedora with a Haiku client, and dragging my mouse over with terminal full-screen doesn't work. As long as you have an X11 app next to the edge of the screen it gives you a "tunnel" to your other systems laughing

Yes, The "GTK window" is the X11 app. Like: Firefox/Gvim.

[lukeab]

I have 2 laptops running wayland, seems like the firefox on the edges on the server instance allows it to transition across to the other screen, however, i dont get any mouse pointer visible on the client, the apps on the client are reacting like they would with the pointer hovering over then and some click events. Chrome windows registering clicks, chagne or create new tabs, and are re-arranging (bringing to front when clicked on) But:

• None of the tilix windows i had open behind the chrome windows are getting clicks or being brought to the front.
• Server keyboard input is still being actioned on the server instance, no affect on the client machine

seems like it's close but not quite there yet.

[friederbluemle]

Interesting observations @lukeab :+1: I tried this a few days ago with macOS as the server and Arch Linux as the client. I was able to move the curser off screen (i.e. it disappeared from the server), however it not only did not appear on the client, clicks also seemed to have no effect.

[BrendanBall]

I'm pretty sure you guys are just seeing some weird behaviour related to xwayland. I don't think any work has actually been done to support wayland.

[threefcata]

Wayland support is certainly needed. I'm using two monitors of different DPI settings, one is a older 1080p screen and the other is a 4K screen. Gnome over wayland is currently the only stable way to setup the monitors in a usable way, as I need different scale factors for each monitor. However, currently Barrier doesn't work. The server log says the client which is my laptop has connected, however, the mouse cursor does not move to the laptop when i place it at the edge of the screen.

[iMartyn]

Mostly commenting to follow the issue, but I agree, a closed bug has an intent to it, usually :

• Bug is fixed (in this case wayland support implemented)
• Bug is not valid (wayland support exists and user error in configuring)
• Bug will not be fixed (No intention of wayland support)

I don't think any of the above really apply so it should be an open bug, if only for the people who come along and look for open issues with wayland when they realise their distro is wayland by default (I think it's fair to say that most distros are now - when Debian stable defaults to it, you know it's mainstream!).

If the last statement is true (no intention), it should be clearly stated in the README.md file so people can move on.

[deisi]

@iMartyn I just hit the same trap as you described.

[jkolczasty]

Sorry to comment closed issue, but it may help:

I use Plasma (KDE) with Wayland (partial, not full, kwin_wayland --xwayland --libinput).

By accident I discovered, that when I open yakuake terminal (slide down) and then slide mouse (smoothly) to other screen (e.g. Windows) that it works! When I do this from desktop or other app, it does not work (mouse goes crazy).

Maybe this will helps to solve Wayland support somehow or at least will be useful as workaround for some users.

[shymega]

The fact remains, Barrier does not support Wayland, so any phenomena where Wayland and Barrier appear to co-operate, even to a degree, are merely coincidence. At least, as far as I can tell.

I will reopen this issue, so we have a tracker issue for Wayland support.

[jkolczasty]

Don't want to argue about barrier roadmap, if Barrier will or will not support Wayland. Just if will not, we can mark it as obsolete or legacy right now, as Wayland is not an experiment on the horizon anymore. It's a subject of current and on-going change in Linux desktop environments.

Btw, Synergy promised to support Wayland with next major release (there is stale tag on 1.x version, but as I understand, it's will happen on 2.x version). This promise is getting old ;-)

[shymega]

On this date - Mon, May 18, 2020 at 08:56:48AM -0700, jkolczasty wrote:

Don't want to argue about barrier roadmap, if Barrier will or will not support Wayland. Just if will not, we can surly mark it as obsolete or legacy right now, as Wayland is not a experiment on horizon anymore. It's a subject current and on-going change in Linux desktop environments.

Barrier will support Wayland at some point. But right now, we simply do not have the manpower to do so. We have very few developers, including myself, who don't always have unlimited time to work on Barrier.

Whilst I'm aware that Wayland is no longer an experiment, not every project can just magically support Wayland quickly. I know this issue is old. But unless we get more developers on the scene, there's really very little that can be done...

If you know of anyone who can help submit PRs or assist with the process of having Wayland support, you're more than welcome to let them know about Barrier!

Btw, Synergy promised to support Wayland with next major release (there is stale tag on 1.x version, but as I understand, it's will happen on 2.x version). This promise is getting old ;-)

Synergy is developed by programmers with dedicated time to work on their product. Barrier is not. We do this voluntarily. It is unfair to compare us to Synergy in terms of manpower and 'promises'.

I will keep this issue open now, despite my past comments, as my position has changed.

Thank you.

[jkolczasty]

You misunderstood me. I mention about Synergy not to compare, but just to point, that they are also struggling with Wayland support (they promised support some time ago, no progress so far). Also, if they will do some progress on open source version (afaik, 1.x is OSS and 2.x is not?), there will be some starting point for Barrier or sth.

[shymega]

I see. Apologies. Yes, I'm aware Synergy are struggling tbh..

[schauveau]

I am trying to use it to control a Raspberry Pi desktop (X11) from my Sway desktop (Wayland) and I managed to make it work reasonably well. The important thing to understand is that Border can only operate if a X11 window has the focus. That makes sense because, for security reasons, Wayland do not provide the ability to intercept keyboard and mouse events at the desktop level (except by grabbing the whole screen). X11 applications can do it because they all receive those events from a single Wayland client XWayland.

So my current setup for border switching is that I keep a very small X11 window on the border of my Wayland screen (so server side). Any X11 application should work but I am currently using 'xterm -e "sleep 1000d"'. I do not know if this is normal behavior but I noticed that switching does not works if I push the mouse too hard.

For keyboard switching, I have a method that almost works. The trick is to start a temporary xterm that sends the requested keystroke to itself using xdotool key --window $WINDOWID. Unfortunately, that does not work reliably so I will not give more details yet.

[schauveau]

By the way, when I say that I have a X11 window at the border that means that the border pixels must be inside that window. That may not work if the pixels are in the window decoration since decorations are typically managed by the Wayland compositor.

[chron-isch]

Don't know if it'll be of any use to you, especially since it's written in C, but you may want to take a look at wayvnc, a wlroots based VNC server and the protocols it uses virtual_keyboard_unstable_v1 and wlr_virtual_pointer_unstable_v1.

[tareko]

Would putting a bounty on the issue to financially support barrier help here?