Add xwayland command

[emersion]

This allows xwayland to be disabled at runtime.

Xwayland needs to be started in server_start, after the config has been read.

Closes #2965

[RyanDwyer]

No docs?

Also, I assume you mean config-time and not runtime.

[emersion]

No docs?

Oh right, I always forget those. Fixed.

Also, I assume you mean config-time and not runtime.

I meant "runtime" as the opposite of "compile-time". But yeah it can only be used in the config file.

[ddevault]

Hmm, I don't think I like this. I would prefer it as -Dxwayland=no

[emersion]

Disabling Wayland is not a debug option. It should be in the config file, you don't want to do it temporarily.

[ddevault]

If you want to do it long-term, just uninstall Xwayland?

[emersion]

The whole point is that uninstalling Wayland doesn't work. wlroots will still try to to launch it (which will fail, but set DISPLAY to a bad value). See the original issue.

[ddevault]

wlroots will still try to to launch it (which will fail, but set DISPLAY to a bad value).

Seems like a bug.

[emersion]

Seems like a bug.

Well, our only option would be to try to find Xwayland in $PATH which is not cool.

[emersion]

It's also useful to be able to disable Xwayland even if you have it installed.

[ddevault]

I dunno, I'm still -1 to this. We'll see what everyone else thinks.

[emersion]

You haven't explained why you don't like it, though.

[ddevault]

All features have a maintenance and complexity cost. I don't think this one pays its bill.

[emersion]

I don't think a +72 −39 feature will have a high maintenance cost. Users can disable Xwayland anyway at build-time, so doing it at runtime doesn't add complexity. Eventually we'll want to have it anyway, as more applications migrate to Wayland. It's also already available in rootston, and the maintenance cost there has been zero.

[ddevault]

rootston isn't a user-facing compositor, we don't have to deal with support.

[emersion]

Sure, I only mentioned rootston because you mentioned code complexity and maintainability.

@ianyfan @RyanDwyer @RedSoxFan Thoughts?

[RyanDwyer]

The only use case I can think of is a user who doesn't want to use Xwayland and who is using a distribution version of sway which has it enabled at compile time. It may be useful for someone who is running sway on a low memory device and wants as many resources as possible available for other things.

I don't see any maintenance or complexity overhead in having it, so +1 from me.

[RedSoxFan]

wlroots will still try to to launch it (which will fail, but set DISPLAY to a bad value).

Seems like a bug.

I agree that this does not sound like the correct/ideal behaviour, but I am not currently familiar enough with related code to suggest a solution.

With that said, I don't think that this adds any maintenance or complexity overhead since it can only be adjusted on launch so +1 from me.

I would like to suggest a small addition/change to this implementation however. Currently on reload, the command will be executed but silently ignored. I think that if the config is being reloaded and the value changes, swaynag should be spawned to notify the user that the new value won't take effect until sway is restarted.

[ddevault]

Thanks!