Expose libWayland wl_display_set_default_max_buffer_size function.

[KosmX]

This is necessary to increase on higher-end systems (high polling rate hardware/high refresh-rate) to avoid crashing some apps that cannot keep up with the event loop momentarily.

For example, if a mouse has 1000 Hz polling rate (and one pointer event is 20 bytes), it takes only 200 ms to overflow the default, 4 kB buffer. This is not uncommon for an app to fail to receive events when something is loading. (personally it is an issue with Minecraft)

I need this patch upstream in Niri

[ids1024]

I guess we probably need something like this in the rs backend too? fill_incoming_buffers will read until self.in_data is full, which is defined as Buffer::new(2 * MAX_BYTES_OUT). Though remaining bytes would still be stored in the kernel socket buffer up to its limit. I assume libwayland is similar here.

(wl_connection_set_max_buffer_size in https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/connection.c?ref_type=heads#L296-315 is where the size of the libwayland ring buffers is set based on this.)

I also see in that function uint32_t max_size_bits; /* 0 for unlimited */. But wl_display_set_default_max_buffer_size and wl_client_set_max_buffer_size don't document anything like that...

[KosmX]

Most of those functions are for libwayland internal, called automatically when a new client connects, except for wl_display_set_default_max_buffer_size. That is called by almost all compositors to set some new limit (like 1MB in Mutter).

Right now I don't have time to dig into exact protocol, and how buffers are used, I just wanted to fix this bug in Niri (tested and works).

If needed, I can dig into this protocol much deeper and add the patch to the rust backend too after my exams.

[ids1024]

Yeah, the wl_connection stuff is internal, but is where the functionality is actually implemented. If the public function has the behavior that 0 means "unlimited" maybe a Option<NonZeroUsize> would be a better Rust API, but then it it would be good to get libwayland to document this behavior.

It looks like there are 3 public functions related to this in libwayland:

• wl_display_set_default_max_buffer_size (this one)
• wl_client_set_max_buffer_size (for a specific client)
• wl_display_set_max_buffer_size (for libwayland-client)

Though I don't know how commonly the latter two are used.

If the rs backend has the same issue, then we definitely do want a way to address it there too. Probably not that hard, I just need to understand exactly what the libwayland behavior is to match it.