Hacker News Reader

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.

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..

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.

> 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.

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.

> 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?

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.