mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-03-02 19:26:56 -05:00
Wayland support #45
Labels
No labels
bug
documentation
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
question
unreproducible
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/rustdesk-rustdesk#45
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @botiapa on GitHub (Jun 4, 2021).
I wanted to try out this application, as it seems very promising, however as I understand it doesn't currently support wayland. What would be needed for wayland support? Screen capture support, GUI, or something else?
@rustdesk commented on GitHub (Jun 4, 2021):
screen capture and mouse/keyboard control
@rustdesk commented on GitHub (Jun 4, 2021):
for mouse/keyboard, https://github.com/ReimuNotMoe/ydotool or https://github.com/atx/wtype can help u
@botiapa commented on GitHub (Jun 4, 2021):
Screen capture is a bit trickier though, since gnome uses a whole different protocol than wlroots based compositors.
@rustdesk commented on GitHub (Jun 4, 2021):
Not sure if https://github.com/emersion/grim helps
@botiapa commented on GitHub (Jun 4, 2021):
I think that's for screenshots only (maybe not fast enough for streaming). I know wf-recorder works on wlroots based compositors.
@rustdesk commented on GitHub (Jun 4, 2021):
The bottleneck is the codec.
@botiapa commented on GitHub (Jun 4, 2021):
What are you using for encoding and decoding?
@rustdesk commented on GitHub (Jun 4, 2021):
vp9
@h33p commented on GitHub (Jun 15, 2021):
So it appears scrap would need to support wayland screen capture for this to work fully, but it doesn't seem to be a very active repo. Pipewire appears to be the way to go with screen capture there, it would most likely block until the user selects the screen to share, but it would end up being efficient. I know zoom takes screenshots for wayland capture, and it's awful. I could give a look at building pipewire into a scrap fork, but I've never done it so no promises.
@rustdesk commented on GitHub (Jun 15, 2021):
Looking forward to your scrap fork.
@rustdesk commented on GitHub (Jun 17, 2021):
clipboard etc：https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html
@rustdesk commented on GitHub (Jun 17, 2021):
KDE (krfb) and Gnome (gnome-remote-desktop)
@rustdesk commented on GitHub (Jun 17, 2021):
nomachine wayland support limitations: https://knowledgebase.nomachine.com/AR02P00969
@rustdesk commented on GitHub (Jun 17, 2021):
@xeechou commented on GitHub (Jun 17, 2021):
Hi, I am the author of a Wayland compositor, so I can provide a little bit idea here, for it to work with Wayland, you basically need a server (for example VNC) as a Wayland client doing the screen capture (read the compositor) then send it over to your application over network.
It's a bit hustle as there is no standard protocol for screen capture, fortunately the new effort of xdg-desktop-portal (a dbus front service) for providing what you neeed.
@H-M-H commented on GitHub (Jun 17, 2021):
I'd recommend looking into pipewire, if you use the gstreamer plugin it is not that bad to implement, you may want to have a look at my implementation here: https://github.com/H-M-H/Weylus/blob/master/src/capturable/pipewire.rs. Pipewire is supported by gnome, kde and wlroots based compositors, so there are already quite some compositors supporting it. You may hit some bugs though, I have documented that here: https://github.com/H-M-H/Weylus/issues/3#issuecomment-808940593
As for input, for my project I use uinput, it requires some meddling with the write permission of /dev/uinput though, so I am not sure if it is suitable for this project. There also is https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.RemoteDesktop but I do not know the implementation status of that among desktops.
@rustdesk commented on GitHub (Jun 18, 2021):
Great job, Thank you so much.
@rustdesk commented on GitHub (Jun 18, 2021):
@H-M-H
Advertise your project, HAHA
@rustdesk commented on GitHub (Jun 30, 2021):
@rustdesk commented on GitHub (Jul 17, 2021):
@H-M-H can I use your pipewire code in this project?
@H-M-H commented on GitHub (Jul 19, 2021):
Weylus is licensed under the AGPL but I am fine if you use my code for pipewire (
github.com/H-M-H/Weylus@4679d5220e/src/capturable/pipewire.rsandgithub.com/H-M-H/Weylus@4679d5220e/src/capturable/pipewire_dbus.rs) under the GPL-3.@rustdesk commented on GitHub (Jul 21, 2021):
The
org.freedesktop.portal.ScreenCastinferface is missing in the version shipped with Ubuntu 20.04 / 20.10.https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1879580
@rustdesk commented on GitHub (Jul 22, 2021):
@H-M-H do you know how to avoid "showing a privileged screenshot dialog every time you make a request"?
https://www.reddit.com/r/rust/comments/o99rtb/seeking_for_a_cross_platform_screencapture_crate/
@H-M-H commented on GitHub (Jul 23, 2021):
I do not know a way around this except using compositor specific APIs (https://github.com/H-M-H/Weylus/issues/3#issuecomment-652670480), which is not exactly desirable.
@rustdesk commented on GitHub (Jul 23, 2021):
I see OBS does not have dialog poped up, but its screen/display capture does not work(black screen, but cursor captured), window capture works fine.
@H-M-H commented on GitHub (Jul 23, 2021):
No dialog and a black screen except for the cursor sounds very much like XWayland, are you sure pipewire is used?
@rustdesk commented on GitHub (Jul 23, 2021):
Yes, it is xwayland
@rustdesk commented on GitHub (Jul 23, 2021):
https://github.com/obsproject/obs-studio/pull/4287 also has system dialog pops up
@rustdesk commented on GitHub (Jul 23, 2021):
first commit
github.com/rustdesk/rustdesk@c15c44788c@rustdesk commented on GitHub (Aug 11, 2021):
https://github.com/obv-mikhail/InputBot but have to run in root
@damnkrat commented on GitHub (Jan 15, 2022):
What about looking through obs-studio code? It can stream video on the wayland
@macpijan commented on GitHub (Feb 15, 2022):
I'm not sure if it fits here, but I've used the backend-vnc for Wayland in one of the projects (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/362) and it worked quite well.
EDIT:
Actually, I probably should have said that the backend-vnc is for weston compositor.
It uses https://github.com/any1/neatvnc library.
The same library is also used in the wayvnc, which is VNC server for wlroots-based compositors https://github.com/any1/wayvnc
The problem might be that e.g. GNOME uses neither of these (it uses mutter AFAIK). I'm not sure what KDE uses.
@ThatOneCalculator commented on GitHub (May 17, 2022):
Any update on Wayland support?
@rustdesk commented on GitHub (May 17, 2022):
hope some one can help
@bt90 commented on GitHub (May 19, 2022):
Teamviewer also went with the
xdg-desktop-portalsolution. This seems like the best approach to add compositor independent wayland support.https://community.teamviewer.com/English/discussion/122410/teamviewer-support-on-wayland-experimental-state-%F0%9F%A7%AA
@rustdesk commented on GitHub (May 19, 2022):
Thanks.
@R030t1 commented on GitHub (May 22, 2022):
Just to temper everyone's expectations here, this project (or any similar project) will likely never support Wayland, by design. Wayland does not want to allow you to do the things that this project needs to do, end of story, you're wrong per the Wayland developers, don't ask for support.
You can target a desktop environment/window manager if the manager provides an API for accessing those things as X11 currently does. So, putting two and two together, either we need to wait for each WM/DE to implement its own access/automation/accessibility API and then cater to each one or just continue to use X11 (nested in Wayland), or longer term, an X11-like shim layer may be made for Wayland.
@rustdesk commented on GitHub (May 22, 2022):
You are right, but normal users do not know and want to accept the fact. We are working on starting X when users are using Wayland.
@bt90 commented on GitHub (May 22, 2022):
@R030t1 i'd agree for unattended access.Everything else is covered by xdg-desktop-portal.
@rustdesk commented on GitHub (May 22, 2022):
Who will use a remote desktop application without unattended access?
@bt90 commented on GitHub (May 22, 2022):
At least my typical usecase is remote support for other people. Telling them to click "allow" in order for me to connect isn't a dealbreaker.
It's also possible that xdg-desktop-portal might add a mechanism which allows to setup secure unattended access in the future. You should probably open an issue and discuss this with their devs.
@maverick74 commented on GitHub (May 22, 2022):
I have to say that I have never needed unattended access.
while I do imagine it maybe useful in some cases, until now, like @bt90, I've just been using it to support (friends, coworkers, etc). Now I'm permanently using windows quick assist... But there's a problem: I can't do it from my Linux machine.
So, in my case, I don't need unattended access... (that's also a great way to stop me from working when I shouldn't!!! Ahah)
@daegalus commented on GitHub (May 22, 2022):
I will say that it's a shame to read unattended access is not possible atm. But I rather have Wayland support drop without it.
There is a huge lack of remote desktop solutions for Wayland.
So I'm hoping Rustdesk can fill the void. I read XDG Portal is the right way to implement it, along with pipewire for the actual video/audio data. Hopefully XDG Portal gets unattended access eventually.
Unattended access is important to me as I use remote desktop to access my own computers easily.
@rustdesk commented on GitHub (May 22, 2022):
can you accept we start a new X(xfce) for unattended access?
@daegalus commented on GitHub (May 22, 2022):
Will that create a new "desktop" or stream the existing desktop.
A lot of the things I do, I need to pull up existing windows, and leave windows open for when I sit down in front of that computer again?
Though I can accept a new X for unattended as a temporary solution. I can make that work as needed.
I appreciate you taking the time and even considering this feature. You are filling a huge void and i understand you can only do so much with the apis provided.
@rustdesk commented on GitHub (May 22, 2022):
no way for unattended access existing desktop.
@daegalus commented on GitHub (May 22, 2022):
Understood, i think this is better than nothing, until XDG Portal changes.
@daegalus commented on GitHub (May 24, 2022):
Just for tracking purposes, I think I found an XDG Portal issue that we can track for support for unattended access. The last comment has links to the variosu implementation status, looks like Gnome already has it implemented: https://github.com/flatpak/xdg-desktop-portal/issues/324
@rustdesk commented on GitHub (May 24, 2022):
@Daegalus Thank you very much
@maverick74 commented on GitHub (May 25, 2022):
KDE, apparently, has already implemented the fix as well (since 2022-04-07)!
See Implement screencast session restore
@fufesou commented on GitHub (Jun 7, 2022):
A simple summary here.
Unattended access can be implemented, but xdg-desktop-portal minimun version is requered.
xdg-desktop-portal has added restore_token since version 4.
Although the token can only be used once.
It is possible to stoe and set
restore_tokenthe value returned by last org.freedesktop.portal.ScreenCast.Start. org.freedesktop.portal.ScreenCast.Start will store the token every time on start_done if the backend support restore_data.The minimun version is 1.12.0 since 21-12-2021.
The backends are not well supported for now.
xdg-desktop-portal-gnome and xdg-desktop-portal-kde support
restore_data.xdg-desktop-portal-gtk and xdg-desktop-portal-wlr do not support
restore_data.@maverick74 commented on GitHub (Jun 7, 2022):
@fufesou so this means it would work well on gnome and kde (if the distro ships version > 1.12.0) but not on the rest?
@fufesou commented on GitHub (Jun 7, 2022):
The version is for xdg-desktop-portal.
gnome and kde have their own backend implmentations for
xdg-desktop-portalintefaces.Their own implemtations must also support restore_data.
@rustdesk commented on GitHub (Jun 13, 2022):
@H-M-H have you ever tried wtype https://github.com/atx/wtype?
@Ashark commented on GitHub (Jul 13, 2022):
I wanted to mention the netstick utility https://github.com/moslevin/netstick.
Probably its idea could be used by rustdesk. It sends keyboard and mouse events via network.
@Victor4X commented on GitHub (Jul 23, 2022):
If we could get keyboard working for a wayland self connecting to a windows machine, that would be enough for 90% of my use cases. Is this what we are discussing options for in the above comments, or do we have a set path forward for implementing this?
I see in #932 that: "Self side cannot be wayland. Keyboard and mouse are not hooked to listen" is this wrongfully trivializing the problem in my mind, or am I able to poke around and get it to work a little by myself?
@fufesou commented on GitHub (Jul 24, 2022):
We're now trying to implement input listening on Wayland.
@hboetes commented on GitHub (Jul 27, 2022):
I don't know if this suggestion is helpful or not, but https://github.com/any1/wayvnc has a VNC server for wayland.
@daegalus commented on GitHub (Jul 27, 2022):
It might help for Sway or wlroots implementations. But Gnome and KDE don't use wlroots.
@dylanmtaylor commented on GitHub (Jul 28, 2022):
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/79
It looks like KDE has a way to restore a stream with previously granted permissions
@rustdesk commented on GitHub (Jul 28, 2022):
@fufesou
@dylanmtaylor commented on GitHub (Jul 28, 2022):
If you follow the link to the KDE bug tracker from that GitLab MR I posted, https://bugs.kde.org/show_bug.cgi?id=445875 they mention a similar implementation existed in GNOME previously.
"There is a reference implementation in xdg-desktop-portal-gnome that is merged already: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/14"
Maybe this can be used to get KDE and GNOME unattended access working using session restore.
@rustdesk commented on GitHub (Jul 28, 2022):
Wondering if some one wanna dive into this with RustDesk?
@wildwestrom commented on GitHub (Aug 1, 2022):
So I don't use rustdesk to connect to my own computer, but to connect to another person, it works great!
My only problem is not being able to send keypresses to another client.
My setup is based on wlroots.
@marcos-mendez commented on GitHub (Aug 3, 2022):
This issues stils opened right? Rustdesk still doesn't support out of the box Wayland connections betwen client and server right?
@dylanmtaylor commented on GitHub (Aug 3, 2022):
That's correct, right now it only works on x11, hopefully somebody contributes to this project and makes the feature work
@rustdesk commented on GitHub (Aug 3, 2022):
We are working hard every day on it.
@fufesou commented on GitHub (Aug 3, 2022):
It's a long way. Capturing and IO.
For capturing, as mentioned here.
Session restore has a requirement of xdg-desktop-portal version. Default xdg-desktop-portal on Ubuntu does not support until 22.04.
@marcos-mendez commented on GitHub (Aug 3, 2022):
OK Im leaving a SOLUTION so people can Use RUST DESK until it is completly developed for WAYLAND compatibility.
On Debian Based Systems:
Edit the file the configures the system init display technology
$ sudo nano /etc/gdm3/custom.confMake x11 or xorg the main software to run the DISPLAY for that make WAYLAND enabled = false under the DAEMON section
WaylandEnable=falseafter that uncomment
This all was based on https://askubuntu.com/questions/1131921/anydesk-remote-server-display-not-supported-e-g-wayland
It worked perfectly here. Thanks
@ThatOneCalculator commented on GitHub (Aug 3, 2022):
This is an extremely naïve "solution" that assumes so many things and basically just says "don't use wayland".
@chiehw commented on GitHub (Aug 3, 2022):
Be patient, wayland is currently supported as a remote side. It is not stable enough, so it has not been released.
@ThatOneCalculator commented on GitHub (Aug 3, 2022):
This isn't about being "patient", this is just assuming a bunch of things (user is comfortable with xorg's security flaws, the user has xorg installed, the user uses gdm, the user uses GNOME, the user has sudo, the user has nano, etc). It isn't a solution at all.
@chiehw commented on GitHub (Aug 3, 2022):
You are right. Are there any good opinions?
@ThatOneCalculator commented on GitHub (Aug 3, 2022):
The good option would to be look into XWayland compatability for now, possibly with some sort of a xdg portal passthrough.
@marcos-mendez commented on GitHub (Aug 3, 2022):
@asur4s and @ThatOneCalculator maybe Naive is what you said as you don't know what type of support i provide. The day you have someone requesting remote support to you with a patient entubated and a diagnosis NFS image server providing MRI images to a surgeon on a live surgery maybe you will think that this type of complaint is Naive.
This change presumes that you will use SUDO and if you use sudo you are having responsabilities that you have to assume.
Next time i suggest offering alternatives, eventought they are temporary or even not secure.
Patience is something that some type of people, specially those laying down a surgury bad don't have to much.
Hope you find this philosophical aproach valid to the forum. Gratfully apreatiate this community and all the people here working to make this happend.
Big hug Marcos
@ThatOneCalculator commented on GitHub (Aug 3, 2022):
Literally nobody asked you. If you want to use Xorg so it fits your use case, go for it, but it's not a solution for Wayland users.
@bt90 commented on GitHub (Aug 3, 2022):
At least screen access is not possible with XWayland. Displaying the client should work already though.
@rustdesk could you hide comments which are not really focusing on the topic of actual wayland support? (workarounds, bickering, etc)
@ThatOneCalculator commented on GitHub (Aug 3, 2022):
I think it might be in some way? Whenever I run Discord under XWayland, it's able to share my entire screen in voice chat.
@bt90 commented on GitHub (Aug 3, 2022):
Isn't Discord electron based and supports Wayland natively?
@ThatOneCalculator commented on GitHub (Aug 3, 2022):
For a while I was running it under XWayland because of Hyprland previously not supporting ozone.
@maverick74 commented on GitHub (Aug 4, 2022):
Let me jump into this by saying that I - personally - don't think xWayland is the solution. Beside, the issue is about Wayland support, not xWayland.
Another important detail that should be taken into account: Fedora (which I don't use!) already defaults to Wayland.
And Fedora/RedHat does lead Linux development (either we like it or not). Others will soon follow...
@ThatOneCalculator commented on GitHub (Aug 4, 2022):
I completely agree. I was suggesting XWayland more as a band-aid for now before a proper Wayland implementation.
@maverick74 commented on GitHub (Aug 5, 2022):
I do also think that for a start targeting KDE Plasma and GNOME implementations would be ideal.
These are the two major and most used DE in the Linux land.
Other projects like LXQt (which we use around here), XFCE, Cinnamon, etc will eventually get support for the needed xdg tech, but that's out of our hands! (these sometimes end up adopting/adapting the implementations of plasma or gnome)
For those cases a message saying that:
"Your DE does not support the xdg tech needed to work with rustdesk. Please use Plasma or GNOME"
would be enough to let the user know it's a limitation of their DE and not from rustdesk.
Also, keeping up with Plasma&GNOME implementations will be painful enough.
but then again, this is just my POV
@bt90 commented on GitHub (Aug 5, 2022):
I wouldn't hardcode desktop environments. xdg-desktop-portal support might be added and the message is obsolete. (yours would already miss sway)
I don't think that rustdesk has to deal with DE specific stuff as XDG is designed to be DE agnostic. At least if an implementation exists.
@maverick74 commented on GitHub (Aug 5, 2022):
As i understand it, both gnome and plasma have xdg implementations that are different from each other and that would need to be addressed specifically (i can be wrong about it, however), but all in all, i do agree with all you said.
The more DE agnostic the better!
@ThatOneCalculator commented on GitHub (Aug 5, 2022):
Please scroll up as there's already been discussion about this. There's 3 XDG portals: GNOME, Plasma (KDE), and WLRoots.
@maverick74 commented on GitHub (Aug 5, 2022):
I was under the impression of something like that. Wasn't sure where i read it however and didn't scroll up :(.
Thanks for the alert!
So, plasma and gnome do have different XDG's... soo... we can't actually go for a "global" solution (for now at least...)
@ThatOneCalculator commented on GitHub (Aug 5, 2022):
Keep in mind that it's GNOME, Plasma AND WLRoots. There's 3. There is also a unifying solution for basic things like screen-sharing just called "xdg-desktop-portal" but it doesn't handle anything besides full screen sharing and audio sharing.
@maverick74 commented on GitHub (Aug 5, 2022):
Yeah, I keep jumping over WLRoots but its an important one as well.
Still @bt90 has a point that there should in "theory" be one implementation common across all desktops.
And i believe that will someday be the case. For sure around "the year of the Linux desktop" ;)
@bt90 commented on GitHub (Aug 5, 2022):
@ThatOneCalculator you always interact with the D-Bus interfaces provided by xdg-desktop-portal. The other ones are just backends with the DE specific implementations.
https://github.com/flatpak/xdg-desktop-portal/blob/main/README.md
And xdg-desktop-portal offers quite a bit more:
https://flatpak.github.io/xdg-desktop-portal/
@jokeyrhyme commented on GitHub (Aug 5, 2022):
Just to clarify, as I think there's some confusion about terminology and what roles and expectations there are around different related components here:
xdg-desktop-portalreads the requestxdg-desktop-portallooks for a service that implements the ScreenCast portal (e.g.xdg-desktop-portal-wlr), and starts the service if necessaryxdg-desktop-portalbecomes something like a proxy: forwarding the ScreenCast request to the implementation, getting the response, forwarding the response back to the applicationNotes:
xdg-desktop-portaland (for the purposes of portals) do NOT know what compositor or desktop environment is in usexdg-desktop-portal-wlrimplements ScreenCast by using wlroots APIs, and therefore doesn't work in a non-wlroots compositor, likewise ScreenCast fromxdg-desktop-portal-gnomewill only work in GNOMExdg-desktop-portal-gtkandxdg-desktop-portal-gnomeuses Nautlius, which loads just fine in KDE, but KDE users would probably prefer the look-and-feel offered by the FileChooser fromxdg-desktop-portal-kdeYou can read through what portals each implementation service offers (as of 2022-08-06):
@daegalus commented on GitHub (Aug 5, 2022):
Great job gathering the details. It seems based on this info. GTK, Gnome, and KDE portals all have ScreenCast and RemoteDesktop implemented.
That should cover most use cases. And unless I misunderstood what you said, the gtk one can cover what's missing in the WLR and Pantheon ones?
But if Rustdesk just implements it's stuff based on the portals apis, it will just be ready when the WLR and Pantheon portals are ready.
@jokeyrhyme commented on GitHub (Aug 5, 2022):
Yes this
@renemadsen commented on GitHub (Oct 10, 2022):
Any progress on this issue?
@rustdesk commented on GitHub (Oct 11, 2022):
Tyr out this https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.2.0.deb. Ubuntu 21+ required for Wayland support. Let me know if you have any problem. @fufesou
@renemadsen commented on GitHub (Oct 11, 2022):
@fufesou will assit you.
@rustdesk commented on GitHub (Oct 11, 2022):
@renemadsen sorry, I overwrote your message by mistake, can you write again?
@renemadsen commented on GitHub (Oct 11, 2022):
No problem,
There is no picture, like shown on this screenshot:
Any suggestions as how to debug this to get more information, to solve the issue.
@fufesou commented on GitHub (Oct 11, 2022):
If the peer side is Wayland. The system will ask the user for agreement to share a screen.
Can you please have a look a the peer side?
User's agreement is designed for safety. We can't get around this step. But you only need to agreen once in the app's lifetime.
By the way, Wayland only support new linux distributions. For Ubuntu, 21.04 or higher is required.
@fufesou commented on GitHub (Oct 11, 2022):
There're some additional limits on Wayland for now.
https://github.com/rustdesk/rustdesk/pull/932#:~:text=hooked%20to%20listen.-,Unsupport,-.%20Server%20need%20to
@muety commented on GitHub (Oct 16, 2022):
RustDesk is such an awesome piece of software - please add Wayland support as soon as you can! It's literally the only thing missing to make it perfect.
@hellmind commented on GitHub (Oct 21, 2022):
how is the current status of rustdesk on wayland?
As client keyboard doesn't work
@hellmind commented on GitHub (Oct 21, 2022):
@fufesou commented on GitHub (Oct 21, 2022):
Hi, do you use the pre-release build?
There're two known cases that input will not wok.
@FurtadoPires commented on GitHub (Oct 21, 2022):
Any chance we could get an official
1.2.0for arch? I want to test in my Manjaro Gnome the current status of Wayland support.Also I think this project should be advertised more in the linux / rust community, I don't know if the devs have a notion of how big is the fact that this foss multi-platform remote control software have Wayland support (even if in initial stage). That something even Anydesk don't have, and it might attract people who might be willing to donate / contribute with this project.
@rustdesk commented on GitHub (Oct 21, 2022):
Try out our nightly build https://github.com/rustdesk/rustdesk/releases/tag/nightly, arch is on the way.
BTW, how to advertise more in the linux / rust community?
@ThatOneCalculator commented on GitHub (Oct 21, 2022):
Id say a good start is posting to the Fediverse, as there's a lot of Rust developers and Linux users there, as well as Linux & Rust subreddits, and putting Rustdesk on Flathub if it isn't there already.
@bbigras commented on GitHub (Oct 22, 2022):
There's also a rust podcast. Tbh I wish I tried rustdesk earlier as I assumed, for some reason, that it wasn't ready. Maybe because of wayland.
@gilgwath commented on GitHub (Oct 22, 2022):
Try reaching out to Chris Fisher from Jupiter Broadcasting. They once featured rustdesk in their picks segment and were happy with it. Most of the hosts are fond of the rust apps as well. He might want to do an interview on Linux Unplugged, they often have interviews with devs of interesting projects. JB has quite the audience as well.
Also, a +1 from me for Wayland support :-) I run my families computers on Ubuntu MATE, and I'm a bit tired of Team Viewer.
@mon-jai commented on GitHub (Oct 22, 2022):
@rustdesk Seems that the install button is not working with the nightly build.
@maverick74 commented on GitHub (Oct 22, 2022):
HackerNews is also good and is also nice if you can get this in "the planets" ( e.g.:
planet.KDE.org, planet.opensuse.org, etc ).
But, as @ThatOneCalculator already said, I would bet in FlatHub a lot!!!
@FurtadoPires commented on GitHub (Oct 22, 2022):
I'll try to compile and test, thank you
My personal suggestions would be:
And a wild guess: Developers from Pop!_OS are developing a new desktop environment called Cosmic, which is entirely written in rust and they may or may not being interested in some integration with rustdesk (who knows...)
@rustdesk commented on GitHub (Oct 23, 2022):
We have two good posts on HackerNews, both were posted by friends we do not know. The one we posted failed to get attentions. :(
@rustdesk commented on GitHub (Oct 23, 2022):
@ThatOneCalculator @bbigras @maverick74 @FurtadoPires Thanks, we will try once our new version is stable.
@rustdesk commented on GitHub (Oct 23, 2022):
Noted.
@rustdesk commented on GitHub (Oct 24, 2022):
https://www.reddit.com/r/gnome/comments/yc0k3h/zoom_screen_sharing_disabled_for_wayland_users_on/
@maverick74 commented on GitHub (Oct 24, 2022):
What's up with KDE Plasma?!?!
Why everyone supports Gnome in everything and Plasma is always the big-bad-wolf?!?!?
I really don't get what companies have against it... :(
@jankatins commented on GitHub (Oct 24, 2022):
@maverick74
Every DE seems to have their own implementation of screen sharing (see above for a summary) and therefore different "details" (=bugs, implemented parts,...). So everything you claim to support needs a) dev effort to actually make it work and b) support effort (training, time to figure stuff out,...), both of which costs money. And so you take the biggest chunk(s) of customers (for which benefits > cost), support them and leave the long tails "unsupported" because it isn't worth the money.
(I do not like it either, but I do get the reasoning; Dropbox did the same with ext4 vs btrfs)
@FurtadoPires commented on GitHub (Oct 24, 2022):
Not sure why you posted this here (maybe it's your post?) but zoom it's probably making a check for specific distro name / version, because some companies usually like to state that they only support "specific distros" even if their software runs in another one. It's kind of a windows dev way of think, but I understand their desire of not wanting to waste resources investigating why the "random franken distro" is having a problem that doesn't happen on the "official systems we support"
@rustdesk to support wayland on linux, just focus on working with:
-
xdg-desktop-portalto communicate with other screens-
pipewire(in case you want to support remote audio)-
systemdto create the rustdesk service (and other init systems if you want to support of course)Any modern Linux distro that supports Wayland should have all the software above in their repositories, so don't be afraid of requesting them as optional dependencies in the project.
@maverick74 commented on GitHub (Oct 24, 2022):
meh...
i've tried a few times to let go of plasma and into gnome (because of company support)... but i just can't.
I need too many options to be able to do my job efficiently that just don't exist in gnome... ever...
I don't care what anyone says of plasma. That thing is far superior in features. And that's why i don't understand those kinds of decisions...
But then again, as you said, it's basically all about the money... sad...
@muety commented on GitHub (Oct 27, 2022):
Would there be an option to include Fedora-compatible RPM packages in the nightly release?
@jirutka commented on GitHub (Oct 27, 2022):
No, thankfully not all modern distros use systemd.
I agree with xdg-desktop-portal and pipewire.
@FurtadoPires commented on GitHub (Oct 27, 2022):
As I've said in the comment you've quoted, it's up to @rustdesk the decision to also support other init systems or not. My point is the three main families have systemd in their repos as default, so it's the first choice if you aim to support most of the linux distros. Which of course doesn't imply that it should "only" support it.
@jack9603301 commented on GitHub (Dec 14, 2022):
We can use the screen recording protocol support of pipewire, OBS uses pipewire
Pipewire not only manages audio but also manages video, maybe the best choice
@marcos-mendez commented on GitHub (Dec 14, 2022):
Yeah it seams so. Pipewire LGTM.
On Wed, Dec 14, 2022, 10:59 JACK @.***> wrote:
@Vorms commented on GitHub (Dec 17, 2022):
Because I am a newbie..
I have debian server using wayland.
Can I just install rustdesk from github and install rustdesk in my windows system ?
@wildwestrom commented on GitHub (Dec 18, 2022):
I don't understand what you mean. Are you asking for a workaround to try to remote into a Debian instance running a wayland compositor? Because if you had read before, that doesn't work, no matter where you're connecting from, wayland or not.
@michag86 commented on GitHub (Dec 25, 2022):
keyboard support
Tested latest nightly (2022-12-05) on Ubuntu 22.04 with wayland (which is default since 22.04). I tested Ubuntu as controlling client and Windows 10 as controlled client. Keyboard (map mode) is almost not working (german keyboard). I noticed that there are some letters, when I input the numbers above the letters. Some of the letters are working like control keys (arrow up and down, pos1, etc.).
If there is any progress I can test it on a german keyboard and tell what keys are working and what don't.
@wildwestrom commented on GitHub (Dec 25, 2022):
@michag86 I think this warrants another issue.
Wayland and X11 don't handle keys any differently (except for the fact that Wayland is only just starting to support global shortcuts.)
@zeroheure commented on GitHub (Jan 10, 2023):
Some tools for Wayland distant access:
Could Rustdesk connect to Wayland through Waypipe?
@rustdesk commented on GitHub (Jan 10, 2023):
https://github.com/rustdesk/rustdesk/pull/2785
@srsgores commented on GitHub (Mar 28, 2023):
Has this been fixed? I just tested on my SteamDeck from
1.1.9, and keyboard forwarding fails on Wayland.Going from Wayland KDE to my Steam Deck.
@dgalli1 commented on GitHub (Mar 28, 2023):
There was no new release since the fix, make sure to run from latest git (or nightly) if you need this feature. (It works fine from my end from KDE Wayland to KDE X11 (should be the same as on your steamdeck)
@rustdesk commented on GitHub (May 11, 2023):
Wayland support availabe in https://github.com/rustdesk/rustdesk/releases/tag/nightly though with some known issue https://github.com/rustdesk/rustdesk/issues/4276#issuecomment-1537105758 which we will not address lately.