Add support for dynamic resizing of headless outputs based on VNC client size changes

[Consolatis]

This is just an initial draft to discuss the overall design of the feature.
Fixes:

• Client side desktop resizing #57 (for headless outputs at least)

Todo:

• When declaring pointer variables, the asterisk (*) is placed on the left with the type rather than the variable name.
• User-visible string such as log messages must not be split up
• Move output->is_headless to Automatically resize headless outputs on client request commit
• Remove the [wip]
• Test display hotplug
• Squash the fixup commits

Also: /me likes brown M&Ms.

[any1]

The over all approach seems fine to me.

[Consolatis]

Fixed the first codestyle issue with pointers on the left.
There are some more in the codebase (found via grep -Rn '. [*][^/ ]' src/ and the same for include/):

include/ctl-server.h:28:        const char *hostname;
include/ctl-server.h:29:        const char *username;
include/ctl-server.h:30:        const char *seat;
include/ctl-server.h:73:                const struct ctl_server_client_info *info,
include/ctl-server.h:77:                const struct ctl_server_client_info *info,
include/strlcpy.h:21:size_t strlcpy(char *dst, const char *src, size_t siz);
include/transform-util.h:22:void wv_region_transform(struct pixman_region16 *dst,
include/transform-util.h:23:            struct pixman_region16 *src, enum wl_output_transform transform
src/main.c:335:static int find_render_node(char *node, size_t maxlen) {
src/main.c:337: drmDevice *devices[64];
src/main.c:341:         drmDevice *dev = devices[i];
src/main.c:538:static struct ctl_server_client *client_next(struct ctl* ctl,
src/main.c:539:         struct ctl_server_client *prev)
src/main.c:551: const struct nvnc_client *vnc_client =
src/main.c:553: const struct wayvnc_client *client = nvnc_get_userdata(vnc_client);
src/output.c:272:static void output_power_mode(void *data,
src/output.c:273:                    struct zwlr_output_power_v1 *zwlr_output_power_v1,
src/output.c:293:static void output_power_failed(void *data,
src/output.c:294:                    struct zwlr_output_power_v1 *zwlr_output_power_v1)
src/strlcpy.c:28:strlcpy(char *dst, const char *src, size_t dsize)
src/strlcpy.c:30:       const char *osrc = src;
src/shm.c:29:static inline int memfd_create(const char *name, unsigned int flags) {
src/shm.c:35:static void randname(char *buf)
src/option-parser.c:119:static void print_string_tolower(FILE* stream, const char *src)
src/ctl-server.c:862:           const struct ctl_server_client_info *info,
src/ctl-server.c:915:           const struct ctl_server_client_info *info,
src/ctl-server.c:924:           const struct ctl_server_client_info *info,
src/ctl-server.c:932:           const struct ctl_server_client_info *info,

[Consolatis]

This PR is ready from my point of view. Will obviously address further review comments.

[any1]

output-manager is notoriously finicky and tends to crash due to object id re-use.

Have you tried adding and removing headless outputs while running? Perhaps event disconnecting and connecting a physical display?

[Consolatis]

output-manager is notoriously finicky and tends to crash due to object id re-use.

Have you tried adding and removing headless outputs while running? Perhaps event disconnecting and connecting a physical display?

No, in fact I didn't. Will test when I get some time.
In the meantime I added fixup commits for the two code style issues, will squash them when I confirmed outputs being removed or added works correctly.

[any1]

It's fine if you don't have time for though testing. We can just push things to master as-is and people who use the master branch might report crashes if they run into them.

By the way, what happens if multiple clients with resizing capability connect? Won't they start fighting?

[Consolatis]

It's fine if you don't have time for though testing.

Main issue for this is that my daily driver and my test system both only have a single HDMI output. So I need to setup an old laptop for testing it.

We can just push things to master as-is and people who use the master branch might report crashes if they run into them.

That is obviously your decision as the maintainer of the project. I'll squash the commits later today.

By the way, what happens if multiple clients with resizing capability connect? Won't they start fighting?

I didn't test that but I'd assume that would only happen if they react to a resized framebuffer by enforcing their current window size again rather than using scaling or adjusting their window size. I am not sure how wayvnc could prevent that scenario though. (Although we could try to prevent resizing if the size is already set to the target size, but that is more of a small generic optimization as I think we wouldn't send a new size to the clients if the size didn't actually change).

Just a heads up: I also did not test output scaling or transform and how that may affect the "physical hardware units of the output device" when using set_custom_mode().

[any1]

Just a heads up: I also did not test output scaling or transform and how that may affect the "physical hardware units of the output device" when using set_custom_mode().

Scaling is probably not a problem, but 90 or 270 degree rotation will swap width and height. That's why we have output_get_transformed_width() and output_get_transformed_height(). But, it doesn't make sense for a headless output to be rotated, because wayvnc is just going to rotate the image back anyway. Maybe we should just force 0 degree rotation when a client sets the resolution.

Perhaps the simplest way to keep clients from fighting would be to only enable dynamic resizing when a single client is connected. If you connect while another is connected and you want to resize, then you can just kick the other client out by not setting the "shared" flag when connecting.

[any1]

Merged. Thanks!