Wayland support? [Donation target met] #109
Comments
|
Peter Hutterer's comment on the Barrier issue may be of interest. |
|
I'm subscribed to that issue, thanks for the heads-up. |
|
Is the bounty link still valid for this task? I'm just a bit unclear on whether the bounty was affected from the project fork. Is the link at the top of this post going towards the people doing the actual work in input-leap, or is it a older competing effort in the original repo by other people? Or is it the same people, just they decided to fork the project but still collect the bounty as per the original link? |
|
as far as I understand bountysource*, the people who donated get to decide if they want to award the bounty. You can claim it, and then they get a 2-week deadline to agree or disagree with that claim. After 2 weeks, and if there is no disagreement, that bounty is paid out. So, from my understanding it might work here, too. But if anyone who donated would object to paying out the bounty, it might not work. *) I might be wrong, I avoid bountysource. |
|
I know Povilas has addressed this in the 'Fork-related Discussions' discussion, but I'm also aiming for the solution to be a I don't use Bountysource myself, and would like to setup Open Collective on this project, but we will see. |
|
It is possible to to control the mouse and keyboard of a gnome environment by using the GSconnect extension and a mobile device running KDE connect. Would taking a look at how GSconnect works be useful or would it not be relevant due to it being a gnome extension? |
|
I think it'd be irrelevant, as a GNOME Extension. We're more looking at a Wayland-native solution, such as a XDG portal. That's making good progress, but this isn't as simple as X11 - we'd need every Wayland compositor maintainer to add support for the XDG portal interface, and I can't see that happening easily. Unless I misunderstood how the portal would work. |
|
For reference, there's a (very much a) Draft PR available now: #1524 |
|
@whot This work is incredible all around, I want to say thank you to all of you for your hard work! I can't believe how many different parts of the system you have had to work on to get to this point and the dedication is just incredible from all of you. Thank you, thank you, thank you. I'm sure you won't be too thrilled to hear this, but I spent two days building everything and worked out the kinks to get this running on my system. It does work in the wild! I'm running GNOME. I'm sure you definitely know this, but having to allow remote input capturing every time is annoying, I would prefer it to be remembered after it's enabled the first time. I wouldn't even mention it if I wasn't posting about everything else, since I'm sure you have it in your long term plans already. You may know this already, but multi-monitor support does not work. It seems to fail with the following: It also doesn't re-initialize if I change my screen layout in GNOME settings, so I have to restart input-leap after disabling my second monitor for it to work. Changing resolutions also causes it to stop working. Finally there may be a change needed in your draft PR 1524, or more likely a change happened after in input-leap that is causing the build to fail. Line 219 in ' I changed both of these to just Again, I can't say thank you enough, this is really amazing to see progress that gets us to this point. If there are any logs or testing that I could do that would be helpful to any developers don't hesitate to ask. Otherwise I'll slink back into the dark and get back to waiting patiently while you put in the hard work. |
|
@hunterzero99 thanks for testing this! yes, the capability bit needed changing, was a late API change that the input leap branch didn't have yet - fixed now. Your fix was correct either way.
On the plus side, this is something independent of InputLeap, it's something that can be handled in the portals. Dunno yet where exactly, but that's a policy decision/implementation rather than an intrinsic requirement.
IIRC none of that code is hooked up yet, everything is really just the basics for now. The API is there for the portal/libei to deal with it, but these are some of the bits that are simply missing at this point. |
|
Hi @p12tic, what's next to do in order to support for say Sway (I3WM's Wayland equivalent) ? |
|
right now the main thing blocking all this is libei needing a stable protocol. Once that's out we can get xdg-desktop-portal* out and work from there. sway uses wlroots so I'm guessing that it uses xdg-desktop-portal-wlr - that would need a similar set of patches as this xdg-desktop-portal-gnome MR. Then sway (wlroots?) itself will need the integration for that and libei. |
|
Hey @whot any news so far ? Any blocking issues ? I can't really see if there is any follow ups PR about libei getting a stable protocol, I also saw that the patch for xdg-desktop-portal-wlr is still bot merged yet, I'm not sure if there is any progress at the moment ? |
I really hope Thanks for the link to ashpd. I am aware of that library - I haven't added it to my rewrite yet. |
I've since filed an issue over at bilelmoussaoui/ashpd#156 :)
The plan is for them to have a Wayland protocol that libei is built on top of. Or compositors can implement libei support themselves. In both situations, Input Leap would still just go through the portal, and deal with it the same as on wlroots and GNOME :D Since most of the required sources seem to be available, at least in the prereleases of many libraries and projects (and Fedora 39) I'll be taking a closer look at assisting with jamming Input Leap into a Flatpak :) |
|
// @orowith2os
Cheers! I'll comment on that issue shortly.
Sure, I'll reply to your post on the Flatpak discussion soon. I might move my FlatHub repo to this organisation, and grant you access as an external collaborator if you want. |
Sounds good 👍 Direct uploads should be coming soon too, so it shouldn't be necessary to duplicate it on Flathub when the time comes. |
|
I'll need to check with @p12tic, in case they don't want the Flathub repo on the org. For now, I've added you to my fork - https://github.com/shymega/flathub-inputleap |
|
Just posting a follow up to avoid an influx of reports or issues when the GNOME 45 release hits. We still need this pull merged into libportal before input-leap will work correctly. It seems fairly straightforward to package, I might spend the time later this week to put a version on the AUR if there's no plans timeline for the commits to be added. Only issue I have is that input sharing with multiples monitors is still not working for me. I know whot is aware of it already, so there's nothing for us to do but wait patiently |
fwiw, I'm currently swamped with some high-priority items so it will take me a few days at least to get to this. it is on my list though. |
|
Referring this issue here: #1673 (comment). |
I was under the impression GNOME 45 has already hit. I vaguely remember seeing it on Reddit. It might explain the sudden influx of interest, for sure. |
it has, you can install Fedora 39 Beta if you want to play with it. libportal however is mostly independent of GNOME - it's a client side library and nothing but input-leap uses the new bits yet. |
|
ok! Finally flatpak/libportal#96 got merged. Awesome :D Can you please tell us what are the possibilities of the desktop compatibility with input-leap, as of now?
NOTE: I have genuinely no idea. I built this table somewhat randomly |
|
input-leap abstracts the client/server so you don't need to care what the other side runs. You can connect any client to any server. To run a client or server on Wayland, right now you need to run those on GNOME, nothing else has the pieces in place. But you can connect those to a remote server/client of any other backend. |
I think this table would be a lot to maintain for a single project. There are so many combinations possible. |
|
I've submitted AUR packages to get support more available on Arch. I don't want to spam the devs here for things that are outside of their control, so please don't report packaging issues here. Be warned, there a definitely bugs possibly including a complete freeze of the display server and ttys (I haven't reproduced it or tracked it down yet, it could be unrelated to input-leap and input sharing or unique to my system including QEMU use). It may be slightly difficult to roll back the versions of everything once you install. If you know absolutely nothing about installing packages on Arch, then you probably shouldn't install this. I plan to delete these packages from AUR once upstream support is released in libportal, and the maintainer of the input-leap package enables the build flag. Anyone using this will probably need to manually switch what packages they are using at that time. Anyone who wants to try it should be able to install things with the following command if you use yay:
|
|
@hunterzero99 Thanks for those packages, they work great! I haven't experienced any crashes yet- the only issues I've hit are:
Latency is good and the mouse works consistently. I wonder if there's a way to permanently allow remote control access for input-leap rather than having to toggle it to enabled each time. EDIT: It seems like the actual culprit causing the loss of keyboard input isn't changing focus, it's the alt key (which of course gets triggered when you alt+tab) |
I presume this is where the Clipboard portal comes in? This would be a question for the input-leap devs.
The RemoteDesktop portal supports persistent sessions, apps just have to request it, like with the ScreenCast (screensharing) portal. See the |
See #1705 fwiw, this will be my last comment in this issue, it is a mix of too many things and newcomers cannot really search for the multitude of things here. Future issues please file as separate ones and if they affect the libei/wayland implementation please cc me so I see it in a timely manner, thanks. |
|
Apologies, I wasn't trying to list out issues to be tackled so much as give others who landed here an idea of what to expect without having to get everything running on their own (I assumed most or all of the issues I've run into are known, and that at least some of them would be related to pieces of the stack other than input-leap). That PR looks good on that note! EDIT: Also, thank you thank you for all the work you've done- you've already made Wayland a viable option when it absolutely wasn't before. |
|
Agreed, thanks for your efforts here @whot. Appreciated. We would never have gotten to this stage with Wayland's support without you. |
|
Someone mentioned that Fedora 39 made this work and I tried it with Fedora 39 and Input Leap from packages, and now I can connect to my Windows PC (which still runs Barrier). THIS IS SO GREAT. Thanks everyone who contributed! |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
As per this comment, please open bugs in the issue tracker, and questions in the Discussions tab. This issue is for tracking progress, not for bugs or questions. Hiding the last two comments now. Thank you. |
@MulverineX @icedream KDE does not support the inputcapture portal and so it will not work. As it is now, gnome is the only DE that supports it. You can express your desire for inputcapture at the KDE portal gitlab as I did 4 months ago. More users upvoting and commenting tells the developers that should consider prioritizing the feature. https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 |
|
Clearly my last comment wasn't heeded, so as we now have Wayland support, we're just waiting for various projects to implement support for the portals, I'm going to lock this issue. Users can continue to open bug reports for quirks and bugs, and discussions for exchanging knowledge. However, this is a tracking issue, and not for support. |
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.
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.
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.
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).
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:
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 😆
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:
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 :
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.@iMartyn I just hit the same trap as you described.
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 ;-)
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.
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_v1andwlr_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.
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.
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 [email protected]
wrote:
--
Tobiasz Cudnik
tobiasz.cudnik / gmail.com
@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.
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?
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
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.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.
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
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.
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_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 :-)@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.
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
@ALL Hell, Have anyone seen this?
symless/synergy-core#4090
Barrier
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
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 [email protected] wrote:
@ackstorm23 A update from @nbolton today
Is anyone using XWayland here?
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/
@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.
@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.
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
I think, may be @nbolton expected some beta testers?
However i'm using wayland on ubuntu 21.04. Let me know if you need any help @nbolton
I think it's fair to assume that >95% of people running wayland are also running xwayland.
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: [email protected]
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.
@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.
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:
@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.
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.
When wayland is finally supported, will it work with following configuration:
Device A with xorg as server -> Device B with wayland as client
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).
Thanks for the info, I'll try out Waynergy today!
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?
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:
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.
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.
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?
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?
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.
debauchee/barrier#109 (comment)
debauchee/barrier#109 (comment)
@p12tic - Could you provide an update when you get a chance? Do you see any areas where you could use some help directly?
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.
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...
@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?
@jemc Done.
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!
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.
@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)
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...
@shymega I think it is possible to hide comments instead of deleting it 😉
Ah yes, didn't know that was a feature... will do that then...
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...
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.
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.
@ReeceSX
I doubt the bouty will be released before the functionality is submitted and confirmed working.
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.
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.
Thanks allot for this, checking it out right now!
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.
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.
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.
Thank you for that too then!
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.
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!
The text was updated successfully, but these errors were encountered: