mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #109] Wayland support? [Donation target met] #84
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#84
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @JaneSmith on GitHub (Aug 2, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/109
Originally assigned to: @BrendanBall on GitHub.
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 commented on GitHub (Aug 2, 2018):
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 commented on GitHub (Sep 8, 2018):
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 commented on GitHub (Sep 8, 2018):
Reopen if a dev wants to tackle a wayland branch.
@BrendanBall commented on GitHub (Jun 13, 2019):
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 commented on GitHub (Jun 28, 2019):
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 commented on GitHub (Jul 3, 2019):
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 commented on GitHub (Aug 5, 2019):
+1 for netevent
@kayasoze commented on GitHub (Aug 12, 2019):
All mainstream Linux distributions now default to Wayland on GNOME. This would seem to be a high priority.
@BrendanBall commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 12, 2019):
FWIW Debian 10 now defaults to Wayland (which is why I'm watching this issue).
@BrendanBall commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 12, 2019):
@BrendanBall One was a bit misleading on my part originally. Sorry about that, I have since fixed the comment.
@AdrianKoshka commented on GitHub (Aug 12, 2019):
Also to add to what @shymega said, there's now a wayland project
@kayasoze commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 12, 2019):
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 commented on GitHub (Aug 28, 2019):
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 commented on GitHub (Aug 28, 2019):
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:
--
Sincerely,
Dom Rodriguez (shymega/dzr).
@valpackett commented on GitHub (Aug 28, 2019):
Rust has very good support on FreeBSD.
@BrendanBall commented on GitHub (Aug 28, 2019):
@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 commented on GitHub (Aug 28, 2019):
@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 commented on GitHub (Aug 28, 2019):
@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 commented on GitHub (Aug 31, 2019):
@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 commented on GitHub (Aug 31, 2019):
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 commented on GitHub (Nov 14, 2019):
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 commented on GitHub (Nov 17, 2019):
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 commented on GitHub (Nov 18, 2019):
There's a project open for it. https://github.com/debauchee/barrier/projects/1
@brianjmurrell commented on GitHub (Nov 26, 2019):
@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 commented on GitHub (Dec 20, 2019):
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 commented on GitHub (Dec 20, 2019):
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:
@kallisti5 commented on GitHub (Feb 8, 2020):
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 😆
@kendling commented on GitHub (Feb 26, 2020):
Yes, The "GTK window" is the X11 app. Like: Firefox/Gvim.
@lukeab commented on GitHub (Mar 16, 2020):
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:
seems like it's close but not quite there yet.
@friederbluemle commented on GitHub (Mar 16, 2020):
Interesting observations @lukeab 👍
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 commented on GitHub (Mar 21, 2020):
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 commented on GitHub (Apr 4, 2020):
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 commented on GitHub (Apr 20, 2020):
Mostly commenting to follow the issue, but I agree, a closed bug has an intent to it, usually :
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.mdfile so people can move on.@deisi commented on GitHub (May 7, 2020):
@iMartyn I just hit the same trap as you described.
@jkolczasty commented on GitHub (May 18, 2020):
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 commented on GitHub (May 18, 2020):
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 commented on GitHub (May 18, 2020):
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 commented on GitHub (May 18, 2020):
On this date - Mon, May 18, 2020 at 08:56:48AM -0700, jkolczasty wrote:
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!
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 commented on GitHub (May 18, 2020):
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 commented on GitHub (May 18, 2020):
I see. Apologies. Yes, I'm aware Synergy are struggling tbh..
@schauveau commented on GitHub (Jun 2, 2020):
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 commented on GitHub (Jun 2, 2020):
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.
@chronically-late commented on GitHub (Jun 15, 2020):
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_v1andwlr_virtual_pointer_unstable_v1.@tareko commented on GitHub (Jul 2, 2020):
Would putting a bounty on the issue to financially support barrier help here?
@p12tic commented on GitHub (Jul 2, 2020):
Any financial contribution is good. However it's hard to say how large the bounty should be to shift the priorities of the Barrier maintainers or attract new developers. Implementing Wayland support is a significant amount of development.
@shymega commented on GitHub (Jul 2, 2020):
Exactly. I don't have much motivation for Barrier right now, due to a mix of things.
@p12tic commented on GitHub (Jul 2, 2020):
I don't want to discourage @tareko though. Personally, I could work on implementing Wayland support in Barrier, especially since I'm doing some Linux input related stuff in other projects already. But the contribution would need to be sizeable as like any other person I have limited amount of time that I can devote to programming.
@ackstorm23 commented on GitHub (Jul 13, 2020):
If it could be decided just how big of a bounty it would have to be to be sure this gets prioritized, the community would likely rise up to provide it. This is a increasingly hot subject.
Synergy has already announced that Wayland won't come until the new major version is released, which they at the same time announced will not release for 3-4 years yet.
If Barrier does it first, you will gain a considerable amount of attention including users of Synergy who make the switch because of this one single feature.
@shymega commented on GitHub (Jul 14, 2020):
I would say that regardless of how much money is thrown at the issue, its not necessary going to happen sooner. The problem is that the codebase is heavily targeted at X11. Adding support for Wayland and X11 would require significant code changes, and man power.
Whilst its possible to do so in theory, in practice it is not as simple.
@TobiaszCudnik commented on GitHub (Jul 14, 2020):
So a wayland fork is way more feasible is what you’re saying? For the time
being ofc
On Tue, Jul 14, 2020 at 7:35 PM Dom Rodriguez notifications@github.com
wrote:
--
Tobiasz Cudnik
tobiasz.cudnik / gmail.com
@shymega commented on GitHub (Jul 14, 2020):
@TobiaszCudnik I wouldn't say a fork is necessary at this point.
I'm already looking into various solutions - my Rust project of a software KVM is a possible candidate for a new design. I would rather keep it C++ at the moment, but my new design does seem to solve existing problems with Barrier.
We could look into a rewrite, but we would certainly have to make a major release for that.
@p12tic commented on GitHub (Jul 14, 2020):
There's no need for a fork. Architecturally Barrier is geared towards X11 as much as it's geared towards Windows. We would just need a separate backend for it. That's a lot of work.
I think the best bet would be to create a bounty on a website such as https://www.bountysource.com and try to attract backers. When there's a large enough contribution some developer will work on it.
@ackstorm23 commented on GitHub (Jul 14, 2020):
Being that Wayland is considered the future and Xorg has gone into fixes-only state of development, I would have expected that Barrier would follow suit by putting the Xorg codebase into the same fixes-only development state and dedicating any new development on a branch/fork/rewrite.
The further development on Xorg is bound to make the transition harder as more and more of the users moved away from it by the maintainers of the operating systems who are already making Wayland the default on install.
Is the problem that there are only enough developers to handle fixes-only development on Xorg in the first place?
@p12tic commented on GitHub (Jul 14, 2020):
I'm not convinced a rewrite would be required for implementation of wayland backend. That would be a significant project just by itself and would likely hit unforeseen bugs that have already been ironed out in Barrier.
@shymega commented on GitHub (Jul 14, 2020):
I don't agree with the current codebase... if I could move
Hurdleto the organisation, we could see if work on that 'paves the way'. But we're all welcome to our different opinions - I just think the current codebase is a total mess.@p12tic commented on GitHub (Jul 14, 2020):
I've seen a fair number of commercial and open source codebases and Barrier is not that bad in comparison. It's just stuck in decade old C++ practices. Cleaning that up is much less work than a rewrite.
@shymega commented on GitHub (Jul 14, 2020):
Hm, maybe. Is it though? Our design could be improved.. and we're not obliged to stay that close to Synergy internally right, no? With your point about ironed out bugs - that's perfectly true, but its not inherently going to happen in a rewrite either.
@p12tic commented on GitHub (Jul 14, 2020):
Yes, Barrier is a fork and we can do anything. We can even break protocol backwards compatibility with ourselves if really needed. It always looks that a rewrite will be easier, but there's a large number of edge cases that Barrier already handles which have long been forgotten. Rediscovering these will be a pain.
@ackstorm23 commented on GitHub (Jul 14, 2020):
One of the barriers (hah) you may have with
I would think finding someone to take that bounty on who has to conform to the constrictions of your existing code-base would be a lot more difficult because of the limitations in flexibility. No?
@p12tic commented on GitHub (Jul 14, 2020):
Contract developers do this all the time, this is not a problem.
@torvitas commented on GitHub (Aug 14, 2020):
Hi - xorg is not an option for me as the Multihead-setup with DP and MSP is not working reliably - so I just wanted to stop by and thank for all the fish.
@hunterzero99 commented on GitHub (Aug 27, 2020):
I put this feature request up on Bountysource and put $20 towards it. Hopefully others can contribute and we can direct some attention towards development.
I just want to say thank you to the development team for their work on Barrier. It's a lesser known piece of software, but I use it daily; my workflow would be hindered without it.
@TobiaszCudnik commented on GitHub (Sep 17, 2020):
Just a shameless bump that the bounty is at $120 now :) Any estimations from the potential takers? Can be useful in promoting the feature, thx.
@p12tic commented on GitHub (Sep 22, 2020):
@TobiaszCudnik, @hunterzero99, @tareko
I have spent the last three months working on stuff related to Linux input (unrelated to Barrier), so now I have enough knowledge of the landscape and could estimate how much work is there to add Wayland support to Barrier.
I could implement this for $2000-$5000. The range represents how much priority I would give to this project and thus how soon we get the results. $2000 means I start working on it within the next 3 months and spend some time on it each week. $5000 means I start working on the project pretty much immediately. Note that this depends on stuff that's not in Wayland yet, so I would need to work on these core projects too, it's not just Barrier.
So the larger the bounty, the earlier we would get Wayland support in Barrier as I would dedicate more time per week to it.
@shymega commented on GitHub (Sep 22, 2020):
You have my approval for this.. also, doesn't each Wayland compositor have to support the interfaces with the Wayland protocol? My (limited) understanding is that its up to each compositor to support what they want to support. So, presumably your work with Barrier's Wayland support would be within the remits of the core Wayland 'interfaces'?
I would certainly like to add GitHub Sponsors support, but I can't do that, as I'm not the owner of the repo, nor a co-owner. There is only one owner, so we would have to ask.EDIT: See comment below.
Thanks for your work btw, @p12tic.
@shymega commented on GitHub (Sep 22, 2020):
Sorry, just to revise my comment about GitHub Sponsors - upon further investigation, it would require a legal business entity behind the project. This is a bit more complex than I envisaged, and so to make things easier for the Barrier devs, we would rather accept donations via BountySource, or to donations to the developer assigned to the task.
@quoing commented on GitHub (Oct 22, 2020):
Hi all,
I wrote client for synergy and barrier for wayland. It is kinda work-in-progress, so it might contain bugs, possibly memory leaks. If you find something feel free to send pull request :)
https://github.com/quoing/wlr-synergy-client
It is working (mouse and keyboard sharing) on my setup windows [barrier server] + swaywm 1.5 [client] (requires wlroots with virtual keyboard and mouse interfaces).
What need to be done: clipboard sharing and pointer locking doesn't work (yet).
@p12tic commented on GitHub (Oct 22, 2020):
@quoing: I see that wlr-synergy-client uses
virtual_keyboard_unstable_v1andwlr_virtual_pointer_unstable_v1protocols which are not part of the upstream wayland protocols (repository here: https://gitlab.freedesktop.org/wayland/wayland-protocols). There's a PR to includezwp_virtual_pointer_unstable_v1but there's been no activity for 9 months.So it seems that wlr-synergy-client would only work on wlroots Wayland compositor, but not much else.
I've been in discussions with the Wayland input guru Peter Hutterer and the proper solution for Barrier will be using the
libeilibrary which is currently under heavy development. This is the only current solution that has upstream support which means it won't be thrown away after a couple of years. The fact that these discussions happened were the reason why I was able to estimate how much work needs to be done and submit a proposal :-)@quoing commented on GitHub (Oct 22, 2020):
@p12tic Yup, correct - wlroots only. Well, I wanted to share my part of work. It is not generic solution, but somebody might find it usefull :) It works for my use-case.
@p12tic commented on GitHub (Oct 23, 2020):
@quoing Thanks. I agree, many people will find it useful. I just wanted to make it known that it's not a long-term solution :-)
@BrendanBall commented on GitHub (Jan 16, 2021):
Another new project has cropped up: rkvm. It sidesteps the whole wayland issue by not implementing certain barrier features, but I think given the current state of things, this is probably the best solution for now if you really want wayland support
@ctsrc commented on GitHub (Jan 19, 2021):
For anyone else coming across this here it might be worth to note, as you discovered, that rkvm currently has issues with working with Wayland.
https://github.com/htrefil/rkvm/issues/10
@Szpadel commented on GitHub (Jan 19, 2021):
i think your comment is misleading, because it works with wayland, but there is some issue with sway compatibility.
it works with gnome under wayland, or even plain tty (console without any WM) as it's implementation is dead simple -> after keyboard combo, forward all input events over network to other system.
But there might be some conflict in accessing those events in specific implementations of WM
@ackstorm23 commented on GitHub (Mar 6, 2021):
The next major version of Synergy is estimated in 3-4 years, with wayland
development only happening at the tail end of it.
The reason this pool is growing is because the userbase does not want to
wait that long.
On March 6, 2021 12:08:09 AM pYFZOS5 notifications@github.com wrote:
@nbolton commented on GitHub (Mar 8, 2021):
Is anyone using XWayland here?
@deisi commented on GitHub (Mar 9, 2021):
I think if u use Wayland, you automatically will use XWayland depending on the Program you use. So yes.
@rmanne commented on GitHub (Mar 26, 2021):
The bounty is funded, am excited to see progress on this!
@ackstorm23 commented on GitHub (Apr 11, 2021):
@p12tic please confirm the clock has started and that you will be able to begin work on this no later than July 1st.
@p12tic commented on GitHub (Apr 13, 2021):
@ackstorm23 FYI I've already started working on that even before the bounty was funded. I have some success moving mouse on KWayland on KDE. The problem here is not that Barrier needs a lot of additional code, but that each wayland compositor will need a separate implementation to support it. With that also comes all the usual pains of collaborating with multiple projects.
@miguelbernadi commented on GitHub (Apr 13, 2021):
@p12tic maybe it's worth adding this as a protocol extension (I'm not klowledgeable on how it all works)? I think Simon Ser may be a good person to guide how/where the discussion should happen. https://emersion.fr/
@aspiringnobody commented on GitHub (Apr 20, 2021):
@p12tic
Kind of a hack but can we use the work done by rkvm as a fallback for wayland compositors we don't support as guests? Except where they invoke uinput/evdev forwarding on a key combo we would be watching the mouse position and triggering with our existing logic?
Would allow some limited functionality (no copy/paste, no setting the cursor position on entering a screen) even if whatever compositor they are running is not standard.
From looking upstream it seems like KDE should be easy to implement, Sway would be next hardest, and Gnome is going to be --- difficult. I'm not even sure Gnome is worth the effort considering how often they change their backend.
@hpfr commented on GitHub (Apr 21, 2021):
@p12tic https://gitlab.freedesktop.org/libinput/libei may be of use.
https://gitlab.freedesktop.org/libinput/libei/-/issues/1
It's all WIP at this point, though. But if you're looking for a protocol extension, this appears to be it (or more specifically, the blessed alternative).
Edit: My bad, you're already aware.
@Queuecumber commented on GitHub (Apr 24, 2021):
I'm hearing a lot about barrier client support but not a lot about server support. Currently with barrier server running under Wayland I can only control the client if my mouse happens to be over an XWayland window, also mouse capture doesn't seem to work. I'm curious what the current plan for the server side is
@naDevi commented on GitHub (Apr 26, 2021):
Synergy company CEO was active on this issue. I think they may have coded that already or partially. In this case, it'll be better if he provided some useful resources or details for community instead ask such weird type questions o_0
I think, may be @nbolton expected some beta testers?
@naDevi commented on GitHub (Apr 26, 2021):
However i'm using wayland on ubuntu 21.04. Let me know if you need any help @nbolton
@aspiringnobody commented on GitHub (Apr 26, 2021):
I think it's fair to assume that >95% of people running wayland are also running xwayland.
@nbolton commented on GitHub (Apr 27, 2021):
Please follow the Wayland issue on the Synergy GitHub project for updates.
Happy to talk about it if you want to drop me an email: nick@symless.com
@naDevi commented on GitHub (Apr 28, 2021):
I don't have any intention to harass you; as mentioned above you're the CEO of synergy and we know barrier is a fork of your company software, if you decided to change that project to closed source then synergy will continue its business but barrier may not goes well.
In this case, indirectly i wanted to suggest you to drop some resources to this community that may helpful to this project maintainers (you can see their effort for address this problem)
The comment details express that looks like already or partially implemented but your comment and silent made feel boring.
@clort81 commented on GitHub (Jun 26, 2021):
@naDevi: Synergy is a for-profit company. It has the financial incentive to stay a step ahead of Barrier, and Wayland support would present a significant advantage to drive sales. Asking them to give-away that competitive advantage - should they ever achieve it - is like asking someone to kill himself for you.
@ccoenen commented on GitHub (Jun 26, 2021):
I paid for Synergy two or three times over the years. To be perfectly honest, I haven't ever had the feeling that this was money well spent. I switched to barrier because I was unhappy with the state of Synergy. I am not confident that they solve Wayland before anyone else. If they do, good for them. But I wouldn't wait for it.
@sheepdestroyer commented on GitHub (Jun 26, 2021):
I don't believe Synergy has the technical expertise to address Wayland support.
It remains to be seen if they'll actively try to do anything after all these years neglecting the issue.
They could participate in funding those who can though.
On Sat, Jun 26, 2021, 21:25 Claudius Coenen @.***>
wrote:
@ackstorm23 commented on GitHub (Jul 22, 2021):
@p12tic any progress to report?
@Corodius commented on GitHub (Aug 1, 2021):
As it has been over 3 months since 2k was collected, has the wayland work been started as promised?
@ccoenen commented on GitHub (Aug 1, 2021):
You're right, the bountysource is at $2550.42 at the moment. It crossed the $2000 on March 29th.
The amount in the post at the top hasn't been updated since january.
@joshskidmore commented on GitHub (Aug 12, 2021):
Please excuse me if this is a bit inappropriate for this thread, but I wanted to point out this project. It's a pretty simple Barrier/Synergy client for Wayland loosely based on the uSynergy library. Clearly, this is about 1/10th of the functionality of Barrier/Synergy, but it works and works pretty well for anyone that's looking to simply connect a Wayland client to an existing Barrier/Synergy server. I had to tweak the xkbmap to match my Barrier linux server, but other than that, I haven't had any issues.
Edit: Also wanted to mention that SSL works as well as clipboard synchronization. The clipboard does occasionally sync some odd entries, but they're easy to work around. Hopefully, I'll be able to spend some time to debug this problem and help.
Edit 2021-09-13: I use this setup every week day, and haven't had any real issues. Occasionally, the Wayland client's clipboard gets odd characters on copy from the server. There have been a few times where, after a while (usually after many laptop lid closing suspends and resumes from both the client and server), the client doesn't gracefully reconnect. In those cases, I just restart the Waynergy daemon, and it's good to go. This is rare (and also happens on Synergy/Barrier), so it's not that big of an issue - at least for me.
@sujaldev commented on GitHub (Aug 15, 2021):
When wayland is finally supported, will it work with following configuration:
Device A with xorg as server -> Device B with wayland as client
@joshskidmore commented on GitHub (Aug 15, 2021):
In theory, when Wayland is fully supported, that scenario as well as Wayland as the server and Xorg/Windows/MacOS as clients.
For the exact scenario you've mentioned, the Waynergy client I posted above would work as well (today).
@sujaldev commented on GitHub (Aug 16, 2021):
Thanks for the info, I'll try out Waynergy today!
@sheepdestroyer commented on GitHub (Aug 16, 2021):
Hey, @nbolton
So, since the linked Synergy issue is locked and not being updated,
I guess we have to inquire here about Synergy's actual technical plans if they now exist, progress made if at all, or possible (technical or financial) collaboration from Synergy with the broader community to finally make it happen.
Any news?
@aspiringnobody commented on GitHub (Aug 16, 2021):
Presumably Nick is waiting on the same thing as barrier: for the desktop environments to implement features that allow this functionality. Wayland doesn't provide the backend features needed for this, and the maintainers have made it clear that they view it as the responsibility of the compositor to provide the needed hooks.
So each and every compositor needs this functionality created. There are no standards. Gnome doesn't even seem to want to do it at all.
I don't see synergy or barrier ever being fully wayland compatible unless someone is willing to work with all the desktop environments to develop a common framework for this. It is not a one person job. This will take a lot of effort and until x.org is untenable there won't be any real motivation to make the switch.
On Mon, Aug 16, 2021 at 4:00 AM, sheepdestroyer @.***> wrote:
@joshskidmore commented on GitHub (Aug 16, 2021):
My issue with this entire thread is that there's an overall lack of communication and/or honesty regarding this. Symless needs to remove "Wayland support" from the top of their roadmap and Barrier probably needs to remove or reword the Wayland bounty. Stop tainting this by accepting money under the guise that this will (a) be a feature of a (near) future version of Synergy or (b) be developed once a specific Barrier bounty amount is hit. A more honest approach would be to start breaking down potential options that might move this forward in some way. Currently, non-developers/technical users are under the assumption that by purchasing a Synergy license or contributing to a bounty, they're moving the ball forward, and it's pretty obvious that this is too big for Synergy and/or one Barrier developer working on this in a genuinely FOSS type of way.
Thoughts: Could we build in Wayland client-only support using something like Waynergy as an model implementation? Could we start trying to using a build some hooks into a popular Wayland compositor (Sway?) as a proof of concept? It would be nice to move this forward because more and more linux distributions will be defaulting to Wayland and this thread is so damn tiring.
Edit: And if progress is being made, let's discuss it.
@hunterzero99 commented on GitHub (Aug 16, 2021):
Symless is unaffiliated with Barrier in any way, and In my opinion we should really stop discussing anything regarding their operations here.
I started the bounty for Wayland, and I'm not affiliated with the Barrier project in any way. When I started the bounty, Wayland support for Barrier was not on any roadmap, and no one seemed to be working at all. The stance was largely, 'it will be needed some day, and someone should contribute to make it happen'. So, having no programming ability, I started a bounty and tossed some money at it to try to draw a developer in to contribute.
So, to be clear, no one associated with Barrier is even accepting money under any guise. The bounty is with a 3rd party (bountysource) and would only be released once the feature is being implemented and some source code is available.
I don't think anyone really anticipated just how involved supporting Wayland would be, but that's the rub.
We should be supportive here, especially if we're not in a position to review of commit code. I am grateful that anyone is even looking at this feature now. I've wanted it for years and no one has been working on it before the bounty was presented.
@torvitas commented on GitHub (Aug 16, 2021):
I wasn't aware that there is code publicly available regarding the wayland integration progress. Could you point me to the code that needs to be reviewed?
@joshskidmore commented on GitHub (Aug 16, 2021):
Sorry for the confusion. I was unaware of how the bounty started, but it seems like a lot of people believe things are moving because of it (or because they contributed to it).
To help with communication, it would be nice to have confirmation to know if anyone (or any contributor) to the Barrier project is actively working on anything related which would provide support for Wayland. It seems like the answer is no, but it hasn't been directly addressed (and is causing a lot of tension in this thread). I ask this, not to be spiteful, but to get an honest view of where we're at with supporting this.
I am in a position where I might be able to contribute to the development of this feature, but as it stands now, it's being treated as an giant, single issue rather than smaller, palatable tasks. And it seems like the weight of this momentous task is on one developer?
@hunterzero99 commented on GitHub (Aug 16, 2021):
I'm not aware of any at the moment either. I didn't mean to imply that there was any production code available as of yet.
@p12tic had a rough roadmap laid out, and confirmed he was in working towards wayland support. He is a developer with past history working on Barrier. I trust he is still working towards this if/when he can. And if he's not, it's not exactly discouraging any other developers from stepping up. The issue has been wanted for several years now with no progress.
https://github.com/debauchee/barrier/issues/109#issuecomment-696715175
https://github.com/debauchee/barrier/issues/109#issuecomment-818691872
@joshskidmore commented on GitHub (Aug 16, 2021):
@p12tic - Could you provide an update when you get a chance? Do you see any areas where you could use some help directly?
@shymega commented on GitHub (Aug 16, 2021):
OK, so Symless and Barrier are different entities, and we do not collaborate. I would advise not tagging Nick - they've got Synergy to work on.
@shymega commented on GitHub (Aug 16, 2021):
With regards to Barrier support, @p12tic is working on it when he can. But we have only one active developer /maintainer who knows C++, and me as a maintainer who works on the issues etc. Open source isn't easy, Barrier isn't a company like Symless, we don't have the resources that they have. Please be patient. There are only two of us that are active now, we can't do anything more - I'm busy myself, but trying to dedicate time to Barrier, but I'm becoming burnt out...
@jemc commented on GitHub (Aug 16, 2021):
@shymega - could you please update the ticket title to reflect that the donation goal has been met, or at least remove the outdated "61%" indication?
@shymega commented on GitHub (Aug 16, 2021):
@jemc Done.
@joshskidmore commented on GitHub (Aug 16, 2021):
I don't think the issue is necessarily patience, but lack of any sort of update, roadmap or plan on what/how "Wayland support" looks like. I'm positive that the team could get some extra development support if this issue was broken down a bit more. A development update, (public) branch or overview/roadmap to "Wayland support" would be much appreciated. I'd love to help out with this effort!
@shymega commented on GitHub (Aug 16, 2021):
Fair enough. I think Povilas is also busy in their employment too - I agree that there should be an update. I will create a development progress tracking issue so @p12tic can provide updates there. It would be desirable if only comments there are directly related to Wayland development. See #1251.
Cheers.
@ccoenen commented on GitHub (Aug 17, 2021):
@shymega thanks! Might I suggest strongly moderating that new issue to stay on topic? This one here has gotten pretty long and probably half of it is not helpful (ironically, including this comment I'm writing right now 😕 which is why i bring it up here and not in the new issue)
@shymega commented on GitHub (Aug 17, 2021):
Yes, I intend to. I do have conflicts of removing comments, or being a strong moderator, as I don't want to be seen as a bad maintainer, but I also think, like you, it's necessary to keep on topic. Your comment is helpful; don't worry about it...
@darkdragon-001 commented on GitHub (Aug 18, 2021):
@shymega I think it is possible to hide comments instead of deleting it 😉
@shymega commented on GitHub (Aug 18, 2021):
Ah yes, didn't know that was a feature... will do that then...
@GreenMan36 commented on GitHub (Sep 7, 2021):
Hi any clue when or if Wayland support will be added?
I'm in a situation where Wayland is really my only option and it would be a shame if I couldn't use this amazing program because of it...
@shymega commented on GitHub (Sep 8, 2021):
No update yet, as I said before if there's no update on the issue, it's likely that state for a reason. I've hidden your comment to keep the issue tidy.
@ghost commented on GitHub (Sep 13, 2021):
Welp, I guess it's time for a whole array of hidden comments, because X may as well be dead and multiple distros are getting ready for the wayland transition. I can't even pull myself to look how barrier supports multiple backends, with the lack of a null implementation, and you know, @p12tic promising to work within 3 months of receiving $2,000, then ghosting the issue for 6 months while sitting on what amounts to 1.5 months of the average salary in his country. Nobody is going to think about contributing anything until Povilas provides an update. Get scammed, y'all.
@quoing commented on GitHub (Sep 13, 2021):
@ReeceSX
I doubt the bouty will be released before the functionality is submitted and confirmed working.
@ghost commented on GitHub (Sep 13, 2021):
Cute way to miss the point for the sake of quote mining 3 words. The point is, $2.5k was donated, not pledged, taken from users looking for wayland support. How many people do you believe are eager to jump right into this when a crowdfunding campaign exists with that amount of backing, controlled by an inactive user, and sniped by someone who won't comment on this issue? Wayland progress is locked until the OP and/or p12tic says something. Edit: Scrap the op part. I guess you don't need the op to release funds from bountysource, but still, lord only knows how much drama this platform might be.
@joshskidmore commented on GitHub (Sep 13, 2021):
I understand your frustration (as mentioned in my comments about a month ago). It would be really wonderful to get a development update from @p12tic - even if it's just, "I haven't been able to work on this; there's no new code available" so that we can start moving this forward in another way.
Note: Personally, I would not recommend hiding comments on this issue thread, and instead focus on doing what it takes to provide a status update so that this thread isn't flooding with the exact same question. People are repetitively asking this for a multitude of reasons.
@GreenMan36 commented on GitHub (Sep 13, 2021):
Thanks allot for this, checking it out right now!
@ccoenen commented on GitHub (Sep 13, 2021):
I think we should continue under the assumption that there has not been made any progress by anyone. I'm not namechecking anyone, because actually nobody in here made any demonstrable progress.
What I'm trying to say: anyone who feels up for the task should just start working on it right now. Anyone who has progress to report should do so in #1251.
@p12tic commented on GitHub (Sep 23, 2021):
Hi all,
I'm sorry for abandoning this issue for so long. I fully understand everyone who feels frustrated. Not providing updates to an issue when there was a bounty and an agreement to work on in is really poor handling of the matter. I take the blame and whatever expletive thrown at me whether written or not - situation is what it is, bad reactions are expected and perfectly normal.
So what happened? I indeed was planning to work on implementing the wayland support and had a plan and so on, then I met the hard fact that there are 24 hours a day. I work with other clients, they pay more and there are contractual guarantees with deadlines, so Barrier naturally has lower priority. Due to some planning mishaps it ended up that I did not have as much time for Barrier as expected.
However, while lack of communication is indeed a problem, I don't feel that I've misled anyone. I didn't promise any particular amount of work to put into Wayland support each week. Quoting: "I start working on it within the next 3 months and spend some time on it each week." I have already implemented partial Wayland support for KWin back in spring and could move mouse and type text on Wayland session there. Spreading this work across whole period since the bounty target was met was somewhere between 1-2 hours per week of time. Not enough, but not insignificant either.
The following is the current progress:
There's a toy implementation of Barrier on top of libei library by Peter Hutterer, who's a Red Hat employee working on libinput and other things related to input. I've been in contact with him and discussing how things should work since last year. The issue with Wayland support in particular is that every one wayland compositor - sway, mutter, kwin and so on will need a separate implementation. I've worked on kwin, Peter worked on mutter and libei itself. There are lots of things still to be done in Barrier side, a lot of it related to keyboard handling which is nasty thing. We've been in discussions with him about what's left as late as last month, he wants someone else to finish the work and does not want the bounty (I offered him to take it all if he wants). There is a significant chunk of work to implement libei support in the wayland compositors as well which is still pending. I estimate that maybe around 70-80% of work is still remaining.
By the way, the design of libei changed significantly at least once, so we would had to redo a bunch of stuff had we implemented support for it from the start before it was clear what the final design of libei is.
Below I'll answer any questions and just provide miscellaneous comments:
Not so soon :) The world is small and I'm actually the maintainer of X server 21.1 release series. The first release candidate has been released a couple of days ago. My work on X server is related to my other open-source efforts to improve touchpad gesture support in Linux ecosystem, see here.
Believe it or not, $2k is very small amount of money in the world of software development. It buys less than a week of a software developer who knows what they're doing. Also remember that there are taxes and the take-home amount is much lower. If one were to hire a contractor who worked on a commercial basis and not because they liked Barrier, I doubt that even $20k would be enough given how much work needs to be done in order to implement full feature. Personally I work on this because I use Barrier myself and see it as a way to make use of old hardware, meaning less electronic trash worldwide.
Indeed, the feature needs to be merged and fully tested.
I agree, all comments are equally important, even those that just vent frustration (but please think about using the reactions if possible).
I think that I will have more time from now on and will be able to give Barrier more priority. Having said that I've already promised this myself several times and each time something more important came up. In a perfect world I would have more time for Barrier and I'm frustrated that I can't work on it myself.
By the way, in case I'm not responding here in the future, my github notification inbox from Barrier sometimes is overflowing, so in case you really want for me to respond to some comment, send me an email at
povilas at radix dot lt.I hope that I've answered most of the questions, if not, please ask below.
@rektide commented on GitHub (Sep 26, 2021):
if we don't give at least 1/3rd of this bounty to Peter Hutterer it will be a travesty. Peter has done the impressively hard & complicated work, not just for Barrier, but for everyone, and he absolutely deserves a huge chunk of that bounty.
@sheepdestroyer commented on GitHub (Sep 26, 2021):
Thank you for that too then!
@p12tic commented on GitHub (Sep 29, 2021):
I've offered full bounty, he refused because, among other reasons, filing taxes is a pain and his work has already been financed by Red Hat. If he ever reconsiders we can of course do differently.
@kevindurb commented on GitHub (Nov 3, 2021):
I use Barrier every single day and its straight up life changing for me! Kudos to absolutely everyone that has worked on this project and kudos to all the work that has been done and all the work that is still to be done on adding Wayland support. Thank you @p12tic for the update thats super encouraging to read!
@ganadist commented on GitHub (Nov 10, 2021):
Current workaround to use barrier as server
@hunterzero99 commented on GitHub (Nov 10, 2021):
I wish we could somehow spawn fullscreen, transparent xwayland windows that passed through all clicks on all desktops as a temporary workaround.
@twnaing commented on GitHub (Nov 21, 2021):
Is Waynergy - A synergy client for wlroots-based Wayland compositors relevant to this?
Don't know how much barrier is compatible with synergy.
@r-c-f commented on GitHub (Dec 23, 2021):
It's compatible with barrier, but only supports the wlroots protocols for virtual input meaning it would be of little help here (no GNOME or KDE support).
@mazunki commented on GitHub (Jan 18, 2022):
As a Sway user, this is quite useful. Thanks for creating it, @r-c-f. Although Waynergy does not seem to work as a server, only a client. Would it be complicated to set it up as/implement a Wayland server?
@r-c-f commented on GitHub (Jan 18, 2022):
It would be rather complicated, yes. One of the purported security benefits of Wayland is that keylogger applications (which is what Barrier is) are impossible to implement as standard clients, and I'm not convinced it will ever be allowed in enough cases to avoid an suid helper listening at the evdev level. And that's aside from the fact that my own primary server can't run Wayland at all, so I wouldn't even be using such a feature.
Ultimately my goal is to have a working stopgap solution until libei gains enough traction for the proposal here to move forward, and then contribute any alternative approaches that now work in waynergy (like the wlroots or KDE protocols, or a plain uinput implementation) should libei not attain universal adoption.
@joshskidmore commented on GitHub (Jan 18, 2022):
@r-c-f Your work is greatly appreciated. I've been using Waynergy for almost a year without issues and also suggested the project as a stopgap on this thread. Thank you.
@mazunki commented on GitHub (Jan 18, 2022):
Thanks for the explanation. My current setup consists of running Barrier under
QT_QPA_PLATFORM=xcbmode, using a shortcut to swap the target display while the XWayland barrier window is in focus, and making sure I don't move the mouse of my main machine. At least it saves me a keyboard on my desktop. Still need two mice, one for each machine, though.I suspect if wlroots had support for XWayland applications being allowed to grab focus and withhold the mouse, I would be able to use the mouse too. Maybe this is possible, but I have no idea how. Until real Wayland support is implemented, that's what I'm stuck with.
@ccoenen commented on GitHub (Jan 19, 2022):
I read earlier comments as "waynergy does not work on GNOME", so I almost didn't try to use it. But I can confirm that waynergy (as a client) connects to barrier (as a server). Currently, I have to disable TLS for some reason, but this is besides the point, I'll raise this in waynergy, first.
@joshskidmore commented on GitHub (Jan 19, 2022):
@ccoenen I had a similar issue with SSL. There were some changes in a recent Barrier update which hardened OpenSSL security. What I ended up doing:
~/.local/share/barrier/SSL/Fingerprints/Local.txtand both lines in the file started withv2:vs a multi-line.--disable-client-cert-checkingparameter.-t("enable trust-on-first-use") and-e("enable TLS encryption") parameters are set.I use this server with a mix of SSL/TLS-enabled Barrier clients as well and haven't had any issues.
@ccoenen commented on GitHub (Jan 19, 2022):
I have verified all three steps, but I still get the handshake failure. My barrier 2.4.0 is on openssl 1.0.21 from 2017. Maybe this is a windows thing?
@brmnjsh commented on GitHub (Feb 7, 2022):
@ccoenen
I have a windows 11 server and a Fedora 35 client with openssl 1.1.1l, that connects fine. It may be your openssl version?
@ccoenen commented on GitHub (Feb 8, 2022):
I think I'll make this a seperate issue. Thanks for everyone who already helped me, but this is getting off track for wayland support.
@cptn-cosmo commented on GitHub (Feb 12, 2022):
not sure if it does help, but i am on Gnome Wayland and have tried both barrier and waynergy. Barrier works perfectly, except for the fact that my curser is not displayed (mouse input is working fine though, just... invisible...). Waynergy has a working cursor, but they keyboard layout is all broken, which is worse than an invisible cursor for me. So, if there is a way to get the cursor displayed with barrier it would work as expect on wayland for me.
@aKn1ghtOut commented on GitHub (Feb 12, 2022):
Same as @yaccin ^ for me. If there is a way to display the cursor in the xwayland windows, that would be more than enough. Good enough for multi-laptop setups as most of the work is in Chrome or other XWayland windows anyway.
If anyone is aware of how this will be implemented and can point me in the right direction, I'll be happy to pick this up too!
@ccoenen commented on GitHub (Feb 12, 2022):
I have a working keyboard config with notes on how I did it (the whole issue might be relevant, but I'm linking my solution). Maybe you can adapt this to your case?
@joshskidmore commented on GitHub (Feb 12, 2022):
This is essentially what I did for the keyboard as well. I'm unsure of the hidden cursor. I don't remember ha ING this issue, but I'll check when I'm home.
@whot commented on GitHub (Feb 24, 2022):
fwiw, I just filed https://github.com/flatpak/xdg-desktop-portal/pull/714 and https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/80 with what I hope provides the infrastructure for Barrier to support capturing input on Wayland.
@hpfr commented on GitHub (Feb 24, 2022):
It's also worth mentioning that p12tic and shymega, two of the most active Barrier maintainers, have migrated to a new repo as of a few months ago: https://github.com/input-leap/input-leap/issues/1414. The fork has quite a few more commits already.
This issue has been duplicated there: https://github.com/input-leap/input-leap/issues/109.
@shymega commented on GitHub (Feb 25, 2022):
@hpfr is right, but I'm thinking that
rkvm's approach is better for Input Leap. For my own KVM I've started, I'm planning to uselibinput, but whilst @whot's PR is a great idea, I'm concerned that it won't be available for older distros that IL/Continuity plan to support...@whot commented on GitHub (Feb 27, 2022):
fwiw, rkvm is a fundamentally different approach. it can only works with root privileges which makes it impossible to use inside a sandbox. And the idea for libei/capture portal is to add this to barrier/input-leap. There are already windows/macos/x11 backends, libei would just be another backend.
@shymega commented on GitHub (Feb 27, 2022):
OK. Well, I suppose a portal might work too. Continuity uses portal screencasts, or will do once I finish the support crate.
@karypid commented on GitHub (Jun 4, 2022):
So, just trying to understand this: the freedesktop PR is what you need to capture events, whereas the flatpak/xdg-desktop-portal PR is to allow you to package the software in flatpak format?
I see the libei change is merged, does that mean that a new version of libei with barrier installed using the native package manager will work on Wayland?
@whot commented on GitHub (Jun 5, 2022):
tbh, it's bit more complicated than that. libei is basically just the transport layer for the events, it defines which devices are available and the events themselves.
libei's server says "here are N devices" and then, depending on client mode, either receives events or sends events for those devices. For event replay (barrier client) that's almost enough, but for the capture part you also need to decide when to start capturing. That requires a full API of available screen zones, establishing pointer barriers, etc. That part is in the desktop-portal.
Whether the application is flatpak'd [1] or not doesn't matter per se, what matters is that the portal is the connection point for that API. This could be done elsewhere but since we need the portal part anyway, might as well be there.
[1] the only special thing about the portal is that it's always accessible from within the sandbox. if you're outside the sandbox, you can connect to it too but the portal can't really restrict you. Functionality-wise, it's identical to the application otherwise.
@jhay06 commented on GitHub (Jul 18, 2022):
is there API for wayland ? maybe i can help?
@whot commented on GitHub (Aug 11, 2022):
ftr, I'm solely focusing on input leap now, simply because of https://github.com/input-leap/input-leap/issues/1414
@dim6003 commented on GitHub (Jan 5, 2023):
Hello,
Trying to use it between 2 ubuntu 22.04 machines (one Intel, the other Arm). Same as many, machines do connect, but no sharing. Any progress on this issue ?
Server log :
Thanks.
@hunterzero99 commented on GitHub (Jan 5, 2023):
@dim6003 multi monitor is not supported yet.
[edit] you also need to launch the server from the command line with 'barriers --use-ei' I don't believe it's supported from the GUI yet.
In your specific case you probably want to run something close to this:
barriers --use-ei -f --no-tray --debug DEBUG1 --name T580 --disable-crypto --disable-client-cert-checking -c /home/didier/configs/barrier.conf --address [192.168.0.32]:24800@dim6003 commented on GitHub (Jan 5, 2023):
option --use-ei does not appear from "barriers --help".
@dim6003 commented on GitHub (Jan 5, 2023):
After removing the option --use-ei, and changing the odroid to be down instead of left, I can see that the mouse switches from server to client and back, but nothing appears on client screen.
@hunterzero99 commented on GitHub (Jan 5, 2023):
@dim6003 if there's no --use-ei option then you haven't patched, compiled and installed all of the necessary components from source to test the experimental Wayland support. Specifically input-leap with the applicable PR gets the --use-ei option.
This code is not in any releases yet.
@dim6003 commented on GitHub (Jan 5, 2023):
Right, just installed from ubuntu's repositories. willing to do, if this can help the community, but I will need some guidelines. Can you direct me to some ?
@p12tic commented on GitHub (Jan 21, 2023):
Wayland support has been merged to InputLeap today in https://github.com/input-leap/input-leap/pull/1594. It still requires custom builds of mutter, libportal, xdg-desktop-portal and xdg-desktop-portal-gnome, so the code is not directly useful to the end users just yet. Thanks a lot to @whot and @ofourdan for making this happen.
@Okazakee commented on GitHub (Feb 6, 2023):
Is there an easy way to build the patched package for xdg-desktop-portal-gnome or others?
@whot commented on GitHub (Feb 6, 2023):
Not yet, short of getting the respective PRs for each package and building it from git.
@Queuecumber commented on GitHub (Feb 7, 2023):
Related question: what is the current plan for getting those patches upstreamed?
@whot commented on GitHub (Feb 7, 2023):
working hard at it. libei needs a stable API before we can upstream the rest and that requires a stable protocol which I'm currently trying to sort out.
@karypid commented on GitHub (Mar 4, 2023):
Much appreciated and donated to bounty. Hope you manage to get this working, there are clearly so many people looking forward to it.
@stefantsov commented on GitHub (Mar 15, 2023):
I'm certainly looking forward to the new version working with Wayland. I've set Debian 11 (alpha 2) - the Wayland session is there by default. Barrier connects to another barrier (with ssl) and in the logs everything works (info is displayed that the "leaving screen""entering screen" is working), but the cursor does not move.
@voodoonofx commented on GitHub (Mar 17, 2023):
I wanted to report success using
barrier-2.4.0-1.fc36.x86_64on a Fedora Core 36 Workstation as server, and a MacBook Pro as client using the following as a command line argument:/usr/bin/barriers -a 172.16.0.200 -n voodoonofx-pc --disable-crypto --no-daemon --config /etc/barrierd.conf --display ":1". Using wayland as the default interface, I was even able to load this using supervisord at startup.@shymega commented on GitHub (Mar 17, 2023):
@voodoonofx That's invalid, Barrier doesn't support Wayland. You're likely using XWayland, and seeing a fluke...
@MarekPikula commented on GitHub (Mar 17, 2023):
Actually, it simply works the other way around (i.e., Barrier server running on (X)Wayland). That's how I'm using Barrier on Fedora with Wayland as well.
@shymega commented on GitHub (Mar 17, 2023):
Same principle applies. Barrier doesn't have any Wayland support, so what you're seeing is an illusion. Just a heads-up, it's not native Wayland.
@whot commented on GitHub (Mar 19, 2023):
ftr, in that case it's expected that nothing happens. Barrier on X uses XTEST to inject events and on XWayland those events effectively go to
/dev/null- because Wayland has no xtest-like protocol (well, nothing standard anyway). Likewise, XWayland can forward events but only while related windows are in focus because it won't get events or updates otherwise. A fun demo to show this is xeyes - in XWayland the eyes will only move while the window is under the cursor.@p6002 commented on GitHub (Apr 1, 2023):
After four years, still zero progress? Why is this so difficult? Some kind of licensing?
@sheepdestroyer commented on GitHub (Apr 1, 2023):
progress is reported here : https://github.com/input-leap/input-leap/issues/109
@shymega commented on GitHub (Apr 1, 2023):
Well, considering it's a voluntary effort, with that kind of attitude, I wonder if we maintainers/developers will even want to continue. Not really. But luckily for you, there is progress - see the link that @sheepdestroyer kindly linked to.
@JaneSmith commented on GitHub (Apr 1, 2023):
What attitude? It seemed to me he/she was just asking a question... a perfectly valid one!
@shymega commented on GitHub (Apr 1, 2023):
Specifically, this:
Came across as a bit of attitude, and given it's a voluntary effort, and they haven't made any code-based contribution to my knowledge - that's why it came across that way to me. Of course, I may have misinterpreted, and I apologise for this. Things don't happen magically, there's been PRs upstream to
libportalandlibei, made by whot, who has been instrumental to this work. It takes time. We don't get paid. I personally feel a bit burned out, so I have to take breaks from time to time.@JaneSmith commented on GitHub (Apr 1, 2023):
I see. I'm sorry you're feeling burned out! I don't know that other person and can't really say what their intention was, but just from my perspective there didn't seem to be any attitude and I've asked similar questions to other projects before, so I found your response a bit surprising.
Of course, things take time, and with a free project being worked on voluntarily nobody is entitled to anything. But some things just are difficult, with that not being any fault of the people working on the project. It can just be nice to know what makes a certain feature difficult or time-consuming to implement — hence the question, "Why is this so difficult?". I don't see that question in a hostile or aggressive way, like "Hurry up, get on with it!!!", but rather just as an enquiry as to the reason for the difficulty.
Thanks for your work.
@karypid commented on GitHub (Apr 1, 2023):
@JaneSmith Why not just edit your issue description at the very top to redirect people there, so that "new arrivals" that just searched for "barrier wayland" and are too lazy to read the wall of text can get their executive summary?
Sorry, but if someone reads the flurry of the activity here and sees that: the project was literally forked to achieve this goal, there's a bounty on it that people actually contribute towards, there are multiple PRs pending, etc, the logical conclusion is would not be posting "why is this so diffficult?" in the old project. Notice how you did not actually answer them, but instead referred them to input-leap for the 5th (!) time so they can read through themselves. But they don't need that do hey? So please edit the issue and put the reference at the very top.
When I came to this issue a while back, I followed one of the many comments pointing to the input-leap issue, subscribed to that and even the several PRs referenced there over time to track progress, and even donated to the bounty (out of appreciation for the difficulty and the fact that I cannot contribute actual time/skills to help out).
I'm sorry, but the last thing I want is for the burned out people doing actual work, to also get demotivated...
@JaneSmith commented on GitHub (Apr 1, 2023):
I can edit the post, but what exactly do you want me to change it to? What do you mean by "redirect people there"?
Sorry — I don't know what you're referring to / talking about. Was this directed at me?
@alerque commented on GitHub (Apr 2, 2023):
For others hitting this issue from a Google search, waynergy may be what you are looking for.
@p6002 commented on GitHub (Apr 2, 2023):
Thanks, but I don't think more than 1% can install it.
Has anyone tested the paid Synergy service? Does it work perfectly on any system?
Maybe this is the only way, spend $30 and forget about this problem?
It seems that the developers dont care to fix the bugs in Barrier, which from a financial point of view makes sense.
@Frenzie commented on GitHub (Apr 2, 2023):
Synergy doesn't support Wayland yet either for the same reason.
@ccoenen commented on GitHub (Apr 2, 2023):
I have been a paying customer of Synergy from Symless. Let's just say I was glad when I switched to barrier.
@shymega commented on GitHub (Apr 2, 2023):
@p6002
First of all, Barrier isn't maintained anymore. I think the original post on this issue needs to be updated to direct people to the new efforts.
The maintainers of the fork, and the valuable contributors towards libei and Wayland, do care about development. But it's hard to do so when you get a bit burned out, so it's important to remain civil. I am aware I have come across as a bit rude, but it's primarily due to burnout. Often I have to take breaks and/or apologise. I don't want to come across as rude, I want Input Leap to be a welcoming project. I've just found myself getting burned out, tired, and feeling a bit bitter. I know that's not the best thing to be feeling - I'm trying to remain positive.
We have made leaps & bounds, thanks to @whot to support Wayland, it's in ongoing development.
Symless haven't gotten that far yet, but I daresay they'll take advantage of the work. This is unavoidable; 'tis the nature of open sources, like it or hate it - a la marmite.
(Edited, wrote this on netbook, needed to expand)
@brianjmurrell commented on GitHub (Apr 2, 2023):
Sadly, they don't have to. They can just wait for the FOSS world of developers to do the work for them and then they incorporate it and profit.
@shymega commented on GitHub (Apr 2, 2023):
I've just edited my previous comment to expand, I wrote it originally on a netbook. But yes, this is the sad truth of FOSS.
@penyuan commented on GitHub (Apr 2, 2023):
True, but depending on the open source license of a project, it doesn't always end sadly.
For example, the license of barrier is the GPLv2. This means that, yes, anyone including a company can incorporate this into their product and add to it, but they have to keep whatever they do under the same license. This then means that the wider community can potentially benefit from that, too. This can be a positive for copyleft licenses like the GPL that is often not talked about.
I suspect many people on this thread already knows this, but just adding this point about barrier's GPLv2 license that some people don't know.
@brianjmurrell commented on GitHub (Apr 2, 2023):
I guess I was being unfair here.
Barrier (only?) exists as a fork of symless/synergy-core, so we are all benefiting from each others' work which is ultimately the goal of FOSS IMO.
@ccoenen commented on GitHub (Apr 4, 2023):
The full story goes back WAAAAAAY longer, though.
This used to be Synergy and it was hosted on sourceforge (Archive Link from 2004), if memory serves. This goes back to the early 2000s.
Then there was a fork called synergy+, hosted on google code (archive from ~2009) because the original synergy was not maintained any longer. That fork, as far as I know, was when Nick Bolton joined the project. He was lested as "member" until somewhere in 2009, and as an "owner" somwhere between 2009 and 2010.
Then Synergy (the original) and Synergy+ joined forces, forming Synergy-foss.org (2011 archive link) was. Around this time they started using 10$ donations to vote on features and bugs. During that time it had MAJOR bugs as well, and one I remember in particular was Alt+Tab on Windows. That was open for over a year. It is more or less when money entered in to the equation.
In May 2014 the domain changed to http://synergy-project.org/ (Archive Link 2014) but it is still the team from synergy-foss as far as I can tell. This was later rebranded to symless with their product Synergy.
barrier was forked off from symless/synergy and input-leap was forked off from barrier. But I would really like to drive the point home that this has been a FOSS project from the beginning, and that Symless is just one stop along the way. I would also like to add that their care of the project was, in my opinion, motivated by turning it into a business. I hinted at this earlier: I do not think they were particularly good stewards of this project (see Windows bug linked above, see handling of wayland currently but also overall stability and so on). Which is why I was delighted to see barrier when it came around.
If course they are within the license to use this code and even to sell it. But this project hardly originated there.
@p6002 commented on GitHub (Apr 4, 2023):
Your answer only confirms to me that nothing will come of it.
Maybe I'll ask a silly question; how can I control with the mouse and keyboard of the host computer, my virtual machines?
What are the professional solutions, what do the specialists use?
@brianjmurrell commented on GitHub (Apr 4, 2023):
@ccoenen Fair enough. But my point was not to illustrate the full history of the code but to simply state that barrier (and, yes, subsequently input-leap) are benefiting from the FOSS contributions of others so it was unfair of me to single out Symless as unfairly benefiting from FOSS.
We are all standing on the shoulders of giants.
@ccoenen commented on GitHub (Apr 4, 2023):
No argument there, we are indeed standing on the shoulders of giants :-)
I added this to the input-leap discussions in a slightly different format as well: https://github.com/input-leap/input-leap/discussions/1633 in case someone can fill some of the gaps, that's probably the more appropriate place to continue this particular topic.
@Nerpson commented on GitHub (Jan 4, 2024):
Hello, excuse my total lack of expertise in this area, from what I saw in this PR https://github.com/input-leap/input-leap/pull/1594 Wayland support is now complete, or am I missing something?
@ccoenen commented on GitHub (Jan 4, 2024):
I am now running input-leap on my laptop on fedora 39 successfully on top of wayland. It's not yet perfect[1], but I would count this as "done". Right now, most distributions don't have all the libraries up to date. I don't really know which exact versions are the minimum requirements, so I'd suggest just trying it. That is probably easier either way.
[1] Not all keys work for me; And sometimes when I need to reconnect after standby my whole desktop environment crashes.
@jhay06 commented on GitHub (Jan 17, 2024):
I Can confirm that this is working , it doesn't have wayland support but it works when an specific apps that using X is running at foreground in fullscreen , for example Chrome browser , when this browser is in the foreground and currently in fullscreen i can control the participant computer , :)
i think if someone can instead create compositor or a hidden box that fill the entire screen and always on top and it just captuire the mouse point location , barrier running on wayland is not be a problem anymore . the current app works .
@ccoenen commented on GitHub (Jan 17, 2024):
This is not what I am talking about. What I am describing is different. Since my previous post from ~2 weeks ago, I can now fully use input-leap on any window without any further tricks. Your experience reads much like the XWayland workarounds described earlier in this issue.
@p6002 commented on GitHub (Jan 17, 2024):
I suspect this will never be fixed.
@Nerpson commented on GitHub (Jan 17, 2024):
And this type of useless comment won't help to fix, so there's no need to post them.
@p6002 commented on GitHub (Jan 17, 2024):
You know, after several years of getting notifications from github about barrier, this is just funny.
@NicolasGoeddel commented on GitHub (Jan 17, 2024):
I am still waiting for the first release of InputLeap. Until then I still have to use X on all my machines.
@evilbulgarian commented on GitHub (Jan 17, 2024):
Here is a good and promising alternative: https://github.com/hrvach/deskhop
@shymega commented on GitHub (Jan 17, 2024):
Have you considered, unsubscribing from the Barrier repo/this issue? That would be an idea.
@shymega commented on GitHub (Jan 17, 2024):
As I have said, that's a fluke. This is not Wayland support.
@NicolasGoeddel commented on GitHub (Jan 18, 2024):
That's not an alternative because it can not share the clipboard.
@brianjmurrell commented on GitHub (Jan 18, 2024):
My understanding is that neither does the current Barrier/InputLeap Wayland implementation (currently).
I'm unable to confirm given that InputLeap doesn't work on current Fedora 39.
@shymega commented on GitHub (Jan 31, 2024):
Try this: https://discussion.fedoraproject.org/t/input-leap-fedora-39-gnome-wayland/95856/3
@brianjmurrell commented on GitHub (Jan 31, 2024):
I've already tried all of that.
Just the fact that there is a copr repo necessary for any/all of this to work means that Wayland is simply (still) not ready for prime-time and that F40's plan to drop Xorg is very obviously premature and is going to break a lot of people's systems.
@ofourdan commented on GitHub (Feb 1, 2024):
On that specific topic, that's my fault, the builds I prepared with the input capture support enabled in my copr got superseded with newer builds from Fedora, so indeed, it would not work.
I have now updated the builds for libportal and input-leap in my copr with the required features backported/enabled so that should be better now, if you're willing to give this another try.
A copr is necessary because projects add new features all the time. And EI support is not related to Wayland per se, you could use EI with X11 and Xorg if you wanted to. But anyhow, this is quite off topic here.
@brianjmurrell commented on GitHub (Feb 1, 2024):
But when a distro requires a copr project in order to actually function properly, that is a big red flag that the distro is broken and needs to slow down on future and make the present function first.
Dropping Xorg in F40 when none of this stuff even works in F39 is a big red flag. IT'S NOT READY YET!
IMO, Fedora should not be dropping such a major functional feature as Xorg until it has a track record of a release or two (at least) showing that there are no major functionality hurdles in doing it. That people are still reporting problems with using Wayland even now means it's not ready to be the one and only option in a distribution!
But yes, way off-topic here. But nobody seems to be listening anywhere else either though.
@ofourdan commented on GitHub (Feb 1, 2024):
Fedora Workstation uses Wayland by default since Fedora 25.
But who said that Xorg was dropped in Fedora 40? FWIW, Fedora is a community project and packages remain as long as people are willing to maintain them in the distribution.
@brianjmurrell commented on GitHub (Feb 1, 2024):
Gave it another try and it still crashes when I try to allow remote input capturing. The dialog for that starts to disappear after I click the Share button in the top right and then the session just crashes completely back to GDM.
dnf-automatic upgraded the following components from your copr:
Let me know if there is any additional information I can provide to diagnose.
@brianjmurrell commented on GitHub (Feb 1, 2024):
By default but not as a single option. Anyone here would not be using Wayland though as soft-KVM (barrier/input-leap) is obviously a use-case that doesn't work with Wayland yet.
Maybe I am conflating issues and the sky is not falling quite as quickly as I thought it was.
Yes, in general. But it's not quite that clear cut. If something already has a maintainer, like, say, GNOME for example and if that maintainer decides he wants to drop support for Xorg (for example), it's meaningless that somebody steps up to maintain Xorg if other maintainers are unwilling to work with/support it. But yeah, to your point in general.
@ofourdan commented on GitHub (Feb 1, 2024):
That means the whole Wayland session crashed. That's with GNOME, right? In which case that would be a mutter bug.
@shymega commented on GitHub (Feb 1, 2024):
Yes, it would be good to stay (calmly) on track and have some logs...
@ofourdan commented on GitHub (Feb 1, 2024):
Please take a look in
journalctland check incoredumpctlto see if you can get a backtrace and file an issue in gitlab.gnome.org (FWIW, I am not seeing such a problem here).@brianjmurrell commented on GitHub (Feb 1, 2024):
https://bugzilla.redhat.com/show_bug.cgi?id=2262308 and https://gitlab.gnome.org/GNOME/mutter/-/issues/3272
FWIW.
Stacktrace is available in the RH bugzilla issue.
@brianjmurrell commented on GitHub (Feb 5, 2024):
The mutter issue above was resolved and now I don't get crashes on just trying to start InputLeap on the Wayland server. Yay and thanks much for that fix @ofourdan!
I did open https://github.com/input-leap/input-leap/issues/1840 though for big mouse wheel jumps on an X11 client with a Wayland server.
Also confirming that copy and paste do not work between Wayland server and X11 client (or perhaps at all, between a Wayland server and any client).
@nyxar77 commented on GitHub (Mar 7, 2024):
no way devs have been sleeping on this since 2018 bruh, I'm on KDE 6 and I got an error saying: barrier is not supported on wayland
@NovaXe commented on GitHub (Mar 9, 2024):
Dev efforts seem to be focused on input leap at the moment but not sure if that supports wayland either
@shymega commented on GitHub (Mar 10, 2024):
Barrier is no longer maintained. Input Leap supports Wayland on GNOME.
@grmrgecko commented on GitHub (Mar 10, 2024):
Input Leap support on KDE is waiting on https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12
@FuLygon commented on GitHub (Apr 21, 2024):
If only using linux as client connect to Windows/Mac, try this https://github.com/r-c-f/waynergy/tree/master
@fennectech commented on GitHub (May 2, 2024):
on KDE / wayland everything works but the mouse does not show. would it be possible to add a feature for a decoy emulated cursor so that we can see where our mouse is. other than that it works fine on wayland for me
@artfox3 commented on GitHub (Jul 4, 2024):
@fennectech how did you manage to make it work on KDE wayland ? it is working for me If KDE is the client, but not if i want it to be the server
@shymega commented on GitHub (Jul 4, 2024):
What @fennectech is seeing is a fluke. It is not supported. I keep having to reiterate this.
Input Leap has KDE and GNOME Wayland support. Your best bet is to move to that.
There will be no further development of Barrier unless the owner picks up development again. Right now, that does not look likely.
@fennectech commented on GitHub (Jul 5, 2024):
Sent from my iPhoneThank you. I’ll have to do switch to thatOn Jul 4, 2024, at 12:27 PM, Dom Rodriguez @.***> wrote:
What @fennectech is seeing is a fluke. It is not supported. I keep having to reiterate this.
Input Leap has KDE and GNOME Wayland support. Your best bet is to move to that.
There will be no further development of Barrier unless the owner picks up development again. Right now, that does not look likely.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
@shymega commented on GitHub (Jul 5, 2024):
Just be aware we're doing a LOT of refactoring and changes on Git master, so you may not want to use it yet. And no, a release will not be made yet. Only when we're happy with the codebase stability and features.
@nbolton commented on GitHub (Sep 3, 2024):
Big Wayland Update! 🚀
Deskflow v1.16 (free and open source Synergy upstream), Synergy and Input Leap now have Wayland support:
Announcement: https://github.com/deskflow/deskflow/discussions/7456
feschber/lan-mouse (written in Rust) also supports Wayland.
Special thanks to Peter Hutterer (@whot), Olivier Fourdan (@ofourdan), and Povilas Kanapickas (@p12tic) for their work on implementing Wayland support. Special thanks to @GeorgesStavracas for releasing libportal 0.8.0 which introduces input capture and other things needed for Deskflow, Input Leap and Synergy to work on Wayland.
@mistyron commented on GitHub (Oct 7, 2024):
Try input leap. Works with Wayland!
@tkna91 commented on GitHub (Oct 7, 2024):
https://github.com/input-leap/input-leap/releases/tag/v3.0.0
@mistyron Thanks. That's great.
@QazCetelic commented on GitHub (Dec 21, 2024):
For anyone else who just found out it doesn't support Wayland, I just installed deskflow, and it took less than a minute to set up and successfully connect. I recommend just going with that.
@mistyron commented on GitHub (Dec 25, 2024):
Also see: https://github.com/deskflow/deskflow/wiki/Project-Forks#history-summary
@robin-degen-tfs commented on GitHub (May 6, 2025):
Various distributions are now defaulting to Wayland and are even starting to drop X support. It won't be much longer and Barrier won't work on any modern linux system at all. Is there any update on this?
@kevindurbpp commented on GitHub (May 6, 2025):
This project is unmaintained, go checkout https://github.com/input-leap/input-leap
@nbolton commented on GitHub (May 6, 2025):
Please try Deskflow or Input Leap as Barrier is no longer in development.
https://github.com/deskflow/deskflow
https://github.com/input-leap/input-leap
Both are compatible with Barrier client/server so you can try on one of your computers.
If this is still an issue in those projects, we would appreciate a cross-post of this issue.
Not sure which to use? The 'Insights' tab of each project may help you decide.