Hacker News Reader

Comment by proto_lambda | Hacker News Reader

I'd proceed with caution. Apparently it doesn't support Wayland, so when you run it under Wayland it offers you a "Fix it!" button that, when clicked, runs sed on some gdm system config files to revert it to X11 (nevermind that gdm is far from the only way to use Wayland): https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform.... If this is the kind of thing that's considered acceptable by the developer, I'd rather keep their products far away from my machines.

A quick glance at the code also reveals an almost complete lack of comments and copious use of unexplained `unsafe`.

View on HN

I don't think the application can work on Wayland because it can't inject commands. Screen sharing is a possibility, but that's it: injecting key strokes or mouse input into applications can only be done by even worse hacks. That said, the "let's disable Wayland to fix it" approach is very... pragmatic, to say the least.

This tool was clearly written by someone with a "make it work for the general public" mindset. And, to be honest, I'm not 100% opposed to this approach, although there should definitely be a giant warning system configuration is changed. When a piece of software says "You are using Wayland and this software requires X11, please change your desktop session type" then you're not helping most people. A simple button to fix the problem can be a lot better than an error message with a link to a complicated step-by-step guide.

As is often the case, this client seems to have been made for people running Ubuntu/Fedora, and a relatively recent version at that.

The copious amount of unsafe seems to revolve around operating system APIs being called. Interacting with X11 requires tons of unsafe operations, you can't really work around that. The best you can do is make your own wrappers to hide the fact you're calling unsafe code behind the scenes, but I can't see too much unnecessary unsafe code in there to be honest.

While I agree that a simple fix this for me button is a great option for users, being a destructive fix it for me button is not. If you want to argue that it is a good thing since this particular piece of software, for the typical linux user who uses without understanding it, I want to counter argument that breaking other software which might rely on wayland in some way and the system now being configured completely different as a side effect, is way worse for a usability point of view.

The user now has one app that works, potentially dozens that don't, doesn't know why it broke, and doesn't know how to fix it. Which is why destructive fix it's for a single app is not a great idea. If it was non-destructive, I would totally agree with you.

From a technical point of view I agree, but I haven't encountered any desktop applications that require Wayland and don't work on X11. It's almost exclusively the other way around in my experience.

I'm sure there are some applications out there that rely on Wayland support, but Wayland is unusable for proper remote tech support without some extensions to the API that Wayland developers don't want to add (notably, the ability to send input to running applications).

There are workarounds (hooking directly into the input system, for example) but those work despite Wayland, not because of it.

I'm willing to go as far as to say that by clicking the "fix me" button, the end user will probably end up fixing more applications than it breaks.

That’s not something you or the developer if this software have the authority to decide.

I think we can leave that up to the users of the software. If the users grant the developer that authority by running the software, and they're happy with the results, then who are we to say otherwise? True, we can decide not to use the software ourselves. But I don't think people like us that are savvy and contrarian enough to likely be affected by this pragmatic solution are the intended target users of this product anyway, at least not on the receiving end (sometimes called the "host" or "server"), where IIUC Wayland needs to be disabled.

The problem is the users are not informed what the software is about to do and have no way to evaluate the consequences.

Exactly, if it's not something that can be isolated/determined to ONLY affecting the app itself, it shouldn't be done, and if you really really want to do it, there should be a big fat warning, but I really wouldn't..

> without some extensions to the API that Wayland developers

Depends on what what you mean by "Wayland developers". Wlroots, and thus sway, support such extensions and I think KDE is open to standardizing such extensions. Gnome supports remote desktop through an xdg portal. The problem is that, as with several other things, all of the compositors haven't agreed on a single standard.

> The user now has one app that works, potentially dozens that don't,

Which apps work on wayland but not x11 ?

Unfortunately doesn't seem like many, as most apps use some sort of toolkit, and generally most support either only X11 or X11 and Wayland, supporting only Wayland isn't popular.

Though people who want to avoid using toolkits would probably do that, as Wayland's API is much more sane for apps.

However for example Waydroid only supports running on Wayland, and somehow nobody has created a reverse XWayland yet (People that ask for this get constantly redirected to nested compositors which is absolutely the wrong thing, a proper reverse XWayland would seemlessly integrate the apps like Xwayland does, and you could drag them, transparency would work, and https://wayland.app/protocols/xdg-shell#xdg_surface:request:... would be converted to _GTK_FRAME_EXTENTS, etc)

"Unfortunately"? Isn't it a good thing that most apps support both?

I don't remember which anymore, but a bit over a year ago, I tried switching everything to Wayland, and had too many problems in my specific hardware setup, went back to x11 and some things just broke and some apps I couldn't use. It was not a pleasant journey, so to say. The transition itself can also be a problem, some things can stay in a config and then not be properly reconfigured.

I've used sway, as an example to Wayland only, and if you have specific things configured around Wayland as a compositor, they break too..

But that shouldn't really be the focus point of the discussion, what really is the point, you don't just yank a whole system wide config out from under an unsuspecting user, there's so many variables you just don't know or can account for. Creating a stable application, is also respecting other apps and the system it runs on, not just going in blazin' fixing things for yourself and then not caring about what side effect/consequences it can have. And worse, not informing about it properly.

> I don't think the application can work on Wayland because it can't inject commands. Screen sharing is a possibility, but that's it: injecting key strokes or mouse input into applications can only be done by even worse hacks.

This app probably should use libinput to emulate keyboard/mouse instead of tapping into X11. No need for crazy hacks as libinput supports Wayland. Applications that provide remote desktop-like functionality like Sunshine used it and runs well on Wayland.

I don't use it so I can't comment on this issue myself, but Wayland support for Sunshine seems all but guaranteed: https://github.com/loki-47-6F-64/sunshine/issues/44

Notably, the lack of a mouse cursor is kind of a big deal for remote support situations. You want the user to be able to indicate stuff with the mouse.

Have you tried this version from this repo? It's more up to date. https://github.com/SunshineStream/Sunshine

"Sunshine is a Gamestream host for Moonlight"

What is Gamestream ? What is Moonlight ?

Think of it as a low latency vnc server suitable for playing games on remote computers. If you want to play your PC games remotely on a raspberry connected to a tv, or on your iPad or laptop, this is for you. Basically self-hosted stadia. But I often use it for non gaming stuff instead of vnc because the latency is very low.

Nvidia gamestream is the proprietary server from nvidia, sunshine is an opensource server compatible with gamestream protocol, and moonlight is an opensource gamestream client.

Doesn't that require root?

You can create an udev rule to give the process permission to access uinput without giving it full root access.

> injecting key strokes or mouse input into applications can only be done by even worse hacks.

Hum I don't understand this, I've been injecting key strokes for a decade on any Linux-running system using uinput (which creates a new virtual /dev/input). Is this somehow broken by wayland? (I haven't ever really used wayland, nor do i understand how it works)

AFAIK uinput does work just fine with Wayland. I've used sc-controller under Wayland before without any issues, and I believe it makes use of uinput

I use Wayland + Sway plus ydotool(d) on a dailty basis (e.g. with libinput-gestures), as well as kbct to rebind keys (main purpose caps to esc and some ctrl/alt/meta/fn rebinds). Both use uinput. Things I could do with xdotool I can also do with ydotool.

I found this comment looking for exactly this. Can you share any advice / config / dotfiles?

It is absolutely possible though, see https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free... (And it really should use this on X11 too, and have the current X11 way as a fallback to insane systems that don't have portals in 2022)

https://knowledgebase.nomachine.com/AR02P00969 - and NoMachine seems to have decent support for Wayland.

The other day there was an article on HN about Cha Bu Duo. This is it. And it works for quick and dirty hacks. But you wouldn't share those and not care about improvement. You'd put a warning about not using this in production.

Yikes.

This is not well-written Rust; code like the below actually defeats the purpose of using Rust, and without any specific reason for doing so.

I personally discourage people from using this software.

    static mut KEYBOARD_HOOKED: bool = false;

    fn start_keyboard_hook(&self) {
        if unsafe { KEYBOARD_HOOKED } {
            return;
        }
    }

The build even requires an assembler (NASM), which is odd, in this context.

I disagree. Not all Rust code needs to be maximally generalized and reusable. If this were library code, I might feel differently. But here we're looking at code for installing a global, system-wide keyboard hook. Using a global variable is a direct, pragmatic, no-nonsense way of doing it.

Edit: Further, there's no such thing as "the purpose of using Rust". Different users can use the same tool for different purposes, and Rust is no different.

That's fair, but I seriously consider the danger of a slippery slope.

To keep in mind, on a pragmatic level, that this type of global can be trivially implemented, at a minimum, via atomics, so the cost to avoid the unsafe is near-zero.

Atomics are not supported by all the platforms, but based on my understanding of their targets (x86-64), they're supported.

At the very least, I would have used an AtomicBool rather than a static mut. See https://github.com/rust-lang/rust/issues/53639 . As a bonus, AtomicBool doesn't require any unsafe code.

It's not that big of a deal tbh and I'm actually not sure there's even a practical safety issue, though there could be bugs if the compiler makes some optimizations based on that (unlikely imo).

AFAIK on any typical platform there's no way you'd have "tearing" for a single byte ie: this will never store an invalid boolean representation.

Underexplained, permanent system config changes? That just about counts as malware, in my book.

(Since I use sway on Ubuntu, rather than gdm, I’d argue it’s a capital offense, but YMMV.)

I am not a user of rustdesk. But from its source code[1], I think does have some warnings about the change. It says,

> "Warning" > "Current Wayland display server is not supported" > `Fix it` => a button triggers system gdm config change > A 'Help' link to github, showing how to change the config manaully.

I wouldn't count it as malware. But I don't think it's OK to change the system configuration by pressing a button of a remote desktop software. It should simply provide a link to user instead.

[1] https://github.com/rustdesk/rustdesk/blob/45375517b960add901...

It doesn't adequately explain what it does before having you ruing your configuration nor should it really be part of this application. An informative message explaining that the application doesn't work on wayland, why, and a link to a page with solutions would have been much better and not placed the user at risk.

Thanks for the warning, that is brutal!

What the actual fuck…

The poor English, use of stock images, and absolutely zero information about the individual people behind the project are also red flags.

There's no way to get it to work with Wayland, by design.

Reply on news.ycombinator.com