server: Return success on resize vs forwarded

[derekschrock]

For clients (tigervnc) that don't support forwarded/async (4)resizing responses resizing does not work properly. Just returning success (0) should be alright until this more clients support it. If Wayland fails to resize the result will be from the server to the client to resize back.

[derekschrock]

Thinking about this would it be better to support a compat. mode? compat mode would return 0 vs strict (current and default) continue to return 4?

[CendioOssman]

I'm not familiar with this code, but I'm assuming there was a reason RFB_RESIZE_STATUS_REQUEST_FORWARDED was returned? Is desktop_layout_fn() guaranteed to have reconfigured the layout before it returns? Otherwise, it would be incorrect to RFB_RESIZE_STATUS_SUCCESS and might break clients in weird ways.

The protocol is designed to be asynchronous, specifically to support cases like this. But it might require some refactoring. E.g. in TigerVNC we have this draft PR in order to support resizing on Wayland:

TigerVNC/tigervnc#2074

[any1]

The layout is not guaranteed to have been reconfigured at the end of desktop_layout_fn, and that is indeed a problem.

If we want to decide that RFB_RESIZE_STATUS_REQUEST_FORWARDED should never have been a thing and that we want to eliminate it from rfb-proto, I'll have to do something rather complicated and drastic instead, i.e. freezing client communication until the resize has been processed.