Wayland support? [Donation target met]
JaneSmith opened this issue · 231 comments
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.
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.
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.
Reopen if a dev wants to tackle a wayland branch.
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.
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.
FreeBSD does seem to have uinput as well
Indeed we do :) It only works for GUI, but it's not like the current X implementation can type into the plain console.
BTW, https://github.com/Blub/netevent is a good uinput forwarder. Not smoothly moving the mouse across devices, just toggles between devices based on a key, but still works nicely.
+1 for netevent
All mainstream Linux distributions now default to Wayland on GNOME. This would seem to be a high priority.
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.
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.
All mainstream Linux distributions now default to Wayland on GNOME.
No, they don't. Ubuntu hasn't since 18.04. Doesn't look like Manjaro does either, but they can't seem to agree on if it does or not. I believe only Fedora uses Wayland by default, and only for some configurations (Nvidia non-free drivers cause problems with Wayland).
Time is definitely better spent on fixing current bugs, as @AdrianKoshka said.
FWIW Debian 10 now defaults to Wayland (which is why I'm watching this issue).
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.
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.
@BrendanBall One was a bit misleading on my part originally. Sorry about that, I have since fixed the comment.
Also to add to what @shymega said, there's now a wayland project
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.
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.
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.
Rust has very good support on FreeBSD.
@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.
@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.
@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
@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?
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.
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.
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.
There's a project open for it. https://github.com/debauchee/barrier/projects/1
@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.
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.
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:
- Config the another screen right-side at server screen.
- Maximum the firefox and let it shown.
- If using wayland application, didn't maximum or override the right edge of the screen.
- Now I can move out the cursor at right edge everytime.
The barrier/synergy can use in wayland in a little tricks.
The mouse can move out when the GTK window in the edge of the screen.
LOL. So that's what's happening. I'm running Barrier on Fedora with a Haiku client, and dragging my mouse over with terminal full-screen doesn't work. As long as you have an X11 app next to the edge of the screen it gives you a "tunnel" to your other systems 😆
The barrier/synergy can use in wayland in a little tricks.
The mouse can move out when the GTK window in the edge of the screen.LOL. So that's what's happening. I'm running Barrier on Fedora with a Haiku client, and dragging my mouse over with terminal full-screen doesn't work. As long as you have an X11 app next to the edge of the screen it gives you a "tunnel" to your other systems laughing
Yes, The "GTK window" is the X11 app. Like: Firefox/Gvim.
I have 2 laptops running wayland, seems like the firefox on the edges on the server instance allows it to transition across to the other screen, however, i dont get any mouse pointer visible on the client, the apps on the client are reacting like they would with the pointer hovering over then and some click events. Chrome windows registering clicks, chagne or create new tabs, and are re-arranging (bringing to front when clicked on)
But:
- None of the tilix windows i had open behind the chrome windows are getting clicks or being brought to the front.
- Server keyboard input is still being actioned on the server instance, no affect on the client machine
seems like it's close but not quite there yet.
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.
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.
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.
Mostly commenting to follow the issue, but I agree, a closed bug has an intent to it, usually :
- Bug is fixed (in this case wayland support implemented)
- Bug is not valid (wayland support exists and user error in configuring)
- Bug will not be fixed (No intention of wayland support)
I don't think any of the above really apply so it should be an open bug, if only for the people who come along and look for open issues with wayland when they realise their distro is wayland by default (I think it's fair to say that most distros are now - when Debian stable defaults to it, you know it's mainstream!).
If the last statement is true (no intention), it should be clearly stated in the README.md file so people can move on.
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.
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.
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 ;-)
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.
I see. Apologies. Yes, I'm aware Synergy are struggling tbh..
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.
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.
Don't know if it'll be of any use to you, especially since it's written in C, but you may want to take a look at wayvnc, a wlroots based VNC server and the protocols it uses virtual_keyboard_unstable_v1 and wlr_virtual_pointer_unstable_v1.
Would putting a bounty on the issue to financially support barrier help here?
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.
Exactly. I don't have much motivation for Barrier right now, due to a mix of things.
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.
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.
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 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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
@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.
@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.
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.
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).
@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 :-)
@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.
@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 :-)
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
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.
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.
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
I think if u use Wayland, you automatically will use XWayland depending on the Program you use. So yes.
The bounty is funded, am excited to see progress on this!
@p12tic please confirm the clock has started and that you will be able to begin work on this no later than July 1st.
@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.
@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/
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.
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.
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
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?
Is anyone using XWayland here?
However i'm using wayland on ubuntu 21.04. Let me know if you need any help @nbolton
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.
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
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?
@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.
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.
@p12tic any progress to report?
As it has been over 3 months since 2k was collected, has the wayland work been started as promised?
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.