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]

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]

Exactly. I don't have much motivation for Barrier right now, due to a mix of things.

[p12tic]

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]

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.

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]

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]

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:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/debauchee/barrier/issues/109#issuecomment-658314188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAWWY4D6UTI47IDZD6BVS3R3SJPPANCNFSM4FNTQKUA .

-- Tobiasz Cudnik tobiasz.cudnik / gmail.com

[shymega]

@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]

So a wayland fork is way more feasible is what you’re saying?

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]

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]

We could look into a rewrite, but we would certainly have to make a major release for that.

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]

I don't agree with the current codebase... if I could move Hurdle to 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]

I just think the current codebase is a total mess.

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]

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]

Our design could be improved.. and we're not obliged to stay that close to Synergy internally right, no?

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]

One of the barriers (hah) you may have with

So a wayland fork is way more feasible is what you’re saying?

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.

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]

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?

Contract developers do this all the time, this is not a problem.

[torvitas]

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]

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]

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]

@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]

@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.

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]

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]

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]

@quoing: I see that wlr-synergy-client uses virtual_keyboard_unstable_v1 and wlr_virtual_pointer_unstable_v1 protocols which are not part of the upstream wayland protocols (repository here: https://gitlab.freedesktop.org/wayland/wayland-protocols). There's a PR to include zwp_virtual_pointer_unstable_v1 but 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 libei library 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]

@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]

@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]

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]

rkvm

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]

rkvm

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.

htrefil/rkvm#10

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]

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:

@ALL Hell, Have anyone seen this? symless#4090 @nbolton Hello, we do plan on adding Wayland support to the next major version. Barrier 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. It's already collected $1,340.42 on https://www.bountysource.com/issues/61664045-wayland-support-donations-are-being-accepted-61-has-been-collected-so-far — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[nbolton]

Is anyone using XWayland here?

[deisi]

I think if u use Wayland, you automatically will use XWayland depending on the Program you use. So yes.

[rmanne]

The bounty is funded, am excited to see progress on this!

[ackstorm23]

@p12tic please confirm the clock has started and that you will be able to begin work on this no later than July 1st.

[p12tic]

@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]

@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]

@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]

each wayland compositor will need a separate implementation to support it

@p12tic https://gitlab.freedesktop.org/libinput/libei may be of use.

The use-cases libei attempts to solve are:

• on-demand input device emulation, e.g. xdotool or more generically the
• XTEST extension
• input forwarding, e.g. synergy

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]

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]

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

Is anyone using XWayland here?

I think, may be @nbolton expected some beta testers?

[naDevi]

Is anyone using XWayland here?

However i'm using wayland on ubuntu 21.04. Let me know if you need any help @nbolton

[aspiringnobody]

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

Is anyone using XWayland here?

I think, may be @nbolton expected some beta testers?

I think it's fair to assume that >95% of people running wayland are also running xwayland.

[nbolton]

instead ask such weird type questions o_0

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]

I think it's time for me to bow out of this thread.

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)

@ackstorm23 A update from @nbolton today

When Nvidia XWayland support is out, then Wayland will really start to take off https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-GL-VLK-XWayland

The comment details express that looks like already or partially implemented but your comment and silent made feel boring.

Is anyone using XWayland here?

[clort81]

@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]

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]

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:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/debauchee/barrier/issues/109#issuecomment-868993955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQJR4B7ETZQ3M3VA76L6TTUXBMXANCNFSM4FNTQKUA .

[ackstorm23]

@p12tic any progress to report?

[Corodius]

As it has been over 3 months since 2k was collected, has the wayland work been started as promised?

[ccoenen]

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.