Wayland support? [Donation target met] #109
Comments
|
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. |
walker0643
added
enhancement
|
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:
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](meh/rust-uinput#9 (comment)) for setting up the virtual mouse and sending some events. If a C++ developer interested in wayland support is keen to start prototyping, that should be enough to get started.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#109 (comment)
--
Sincerely,
Dom Rodriguez (shymega/dzr).
|
|
Rust has very good support on FreeBSD. |
|
I am now running input-leap on my laptop on fedora 39 successfully on top of wayland. It's not yet perfect[1], but I would count this as "done". Right now, most distributions don't have all the libraries up to date. I don't really know which exact versions are the minimum requirements, so I'd suggest just trying it. That is probably easier either way. [1] Not all keys work for me; And sometimes when I need to reconnect after standby my whole desktop environment crashes. |
|
I Can confirm that this is working , it doesn't have wayland support but it works when an specific apps that using X is running at foreground in fullscreen , for example Chrome browser , when this browser is in the foreground and currently in fullscreen i can control the participant computer , :) i think if someone can instead create compositor or a hidden box that fill the entire screen and always on top and it just captuire the mouse point location , barrier running on wayland is not be a problem anymore . the current app works . |
This is not what I am talking about. What I am describing is different. Since my previous post from ~2 weeks ago, I can now fully use input-leap on any window without any further tricks. Your experience reads much like the XWayland workarounds described earlier in this issue. |
|
I suspect this will never be fixed. |
And this type of useless comment won't help to fix, so there's no need to post them. |
|
You know, after several years of getting notifications from github about barrier, this is just funny. |
|
I am still waiting for the first release of InputLeap. Until then I still have to use X on all my machines. |
|
Here is a good and promising alternative: https://github.com/hrvach/deskhop |
Have you considered, unsubscribing from the Barrier repo/this issue? That would be an idea. |
As I have said, that's a fluke. This is not Wayland support. |
That's not an alternative because it can not share the clipboard. |
My understanding is that neither does the current Barrier/InputLeap Wayland implementation (currently). I'm unable to confirm given that InputLeap doesn't work on current Fedora 39. |
Try this: https://discussion.fedoraproject.org/t/input-leap-fedora-39-gnome-wayland/95856/3 |
I've already tried all of that. Just the fact that there is a copr repo necessary for any/all of this to work means that Wayland is simply (still) not ready for prime-time and that F40's plan to drop Xorg is very obviously premature and is going to break a lot of people's systems. |
On that specific topic, that's my fault, the builds I prepared with the input capture support enabled in my copr got superseded with newer builds from Fedora, so indeed, it would not work. I have now updated the builds for libportal and input-leap in my copr with the required features backported/enabled so that should be better now, if you're willing to give this another try.
A copr is necessary because projects add new features all the time. And EI support is not related to Wayland per se, you could use EI with X11 and Xorg if you wanted to. But anyhow, this is quite off topic here. |
But when a distro requires a copr project in order to actually function properly, that is a big red flag that the distro is broken and needs to slow down on future and make the present function first. Dropping Xorg in F40 when none of this stuff even works in F39 is a big red flag. IT'S NOT READY YET! IMO, Fedora should not be dropping such a major functional feature as Xorg until it has a track record of a release or two (at least) showing that there are no major functionality hurdles in doing it. That people are still reporting problems with using Wayland even now means it's not ready to be the one and only option in a distribution! But yes, way off-topic here. But nobody seems to be listening anywhere else either though. |
Fedora Workstation uses Wayland by default since Fedora 25. But who said that Xorg was dropped in Fedora 40? FWIW, Fedora is a community project and packages remain as long as people are willing to maintain them in the distribution. |
Gave it another try and it still crashes when I try to allow remote input capturing. The dialog for that starts to disappear after I click the Share button in the top right and then the session just crashes completely back to GDM. dnf-automatic upgraded the following components from your copr: Let me know if there is any additional information I can provide to diagnose. |
By default but not as a single option. Anyone here would not be using Wayland though as soft-KVM (barrier/input-leap) is obviously a use-case that doesn't work with Wayland yet.
Maybe I am conflating issues and the sky is not falling quite as quickly as I thought it was.
Yes, in general. But it's not quite that clear cut. If something already has a maintainer, like, say, GNOME for example and if that maintainer decides he wants to drop support for Xorg (for example), it's meaningless that somebody steps up to maintain Xorg if other maintainers are unwilling to work with/support it. But yeah, to your point in general. |
That means the whole Wayland session crashed. That's with GNOME, right? In which case that would be a mutter bug. |
|
Yes, it would be good to stay (calmly) on track and have some logs... |
|
Please take a look in |
|
https://bugzilla.redhat.com/show_bug.cgi?id=2262308 and https://gitlab.gnome.org/GNOME/mutter/-/issues/3272 Stacktrace is available in the RH bugzilla issue. |
|
The mutter issue above was resolved and now I don't get crashes on just trying to start InputLeap on the Wayland server. Yay and thanks much for that fix @ofourdan! I did open input-leap/input-leap#1840 though for big mouse wheel jumps on an X11 client with a Wayland server. Also confirming that copy and paste do not work between Wayland server and X11 client (or perhaps at all, between a Wayland server and any client). |
|
no way devs have been sleeping on this since 2018 bruh, I'm on KDE 6 and I got an error saying: barrier is not supported on wayland |
Dev efforts seem to be focused on input leap at the moment but not sure if that supports wayland either |
|
Barrier is no longer maintained. Input Leap supports Wayland on GNOME. |
|
Input Leap support on KDE is waiting on https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 |
|
If only using linux as client connect to Windows/Mac, try this https://github.com/r-c-f/waynergy/tree/master |
|
on KDE / wayland everything works but the mouse does not show. would it be possible to add a feature for a decoy emulated cursor so that we can see where our mouse is. other than that it works fine on wayland for me |
and others
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.
The text was updated successfully, but these errors were encountered: