Add support for custom modes

[cmeissl]

It does not implement support for custom mode lines like discussed in #333, but setting a custom mode calculated from cvt timtings. I will extend this with support for custom mode lines in a separate PR.

[YaLTeR]

Thanks, the config syntax and the core logic seems ok. For the custom modeline extension I suppose we could have an extra modeline "1 2 3 4 ..." line that overrides the mode line if present?

The main leftover thing is advertising the custom mode to wlr output management.

Also, similarly, we need to advertise the custom mode (if any) in niri_ipc::Output and its current_mode. In this case I believe we could add an is_custom: bool to niri_ipc::Mode then just put the custom mode alongside the normal modes. And print it accordingly from niri msg outputs.

[YaLTeR]

Suggested change

	scale 2
	transform "flipped-90"
	position x=10 y=20
	mode custom=true "1920x1080@144"
	variable-refresh-rate on-demand=true
	background-color "rgba(25, 25, 102, 1.0)"
	mode custom=true "1920x1080@144"

[YaLTeR]

Would be good to have a few snapshot tests for this function, like here for example:

niri/src/utils/scale.rs

Lines 111 to 115 in 9fb02b9

	#[test]
	fn test_round_scale() {
	assert_snapshot!(closest_representable_scale(1.3), @"1.3");
	assert_snapshot!(closest_representable_scale(1.31), @"1.3083333333333333");
	assert_snapshot!(closest_representable_scale(1.32), @"1.3166666666666667");

There's an assert_debug_snapshot!() for using the Debug impl.

[YaLTeR]

Suggested change

	<sup>Since: unreleased</sup> A custom mode can be activated by setting `custom=true`, in which case the refresh rate is mandatory.
	```kdl
	/// Set a custom mode not offered by the connected display
	output "HDMI-A-1" {
	mode custom=true "2560x1440@143.912"
	}
	<sup>Since: next release</sup> You can configure a custom mode (not offered by the monitor) by setting `custom=true`.
	In this case, the refresh rate is mandatory.
	> [!CAUTION]
	> Custom modes may damage your monitor, especially if it's a CRT.
	> Follow the maximum supported limits in your monitor's instructions.
	```kdl
	// Use a custom mode for this display.
	output "HDMI-A-1" {
	mode custom=true "2560x1440@143.912"
	}

[YaLTeR]

It doesn't need to be null-terminated right?

[YaLTeR]

Does the custom mode need to be advertised to the client as part of the output modes? I think that's the only way to set it as current_mode.

It's not entirely clear what wlroots does in this case, but I think it does send the custom mode as one of the fake modes:

https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/22db307e4cd63f64228aaf3c763764470f112982/types/wlr_output_management_v1.c#L877

In our case here, we need to be careful with the mode index when the custom mode is set/unset, though I believe that should already be covered by the old.modes.len() == conf.modes.len() in the diffing code.

[rwx7]

My monitor's native resolution isn't recognized properly with an Intel Arc A310 on Arch and Fedora. Monitor works with Windows and Macbook.

I merged this PR into my local branch. I ran cvt -r 2560 1440 60 to generate a modeline that works in both Hyprland and Sway. I configured niri to use the calculated refresh rate and verified with niri validate.

output "HDMI-A-3" {
   mode custom=true "2560x1440@59.95"
   // mode custom=true "2560x1440@60"
}

Result is a blank screen for both mode entries.

[wrldspawn]

Tested this PR in a VM (trying to use ultrawide resolutions but VMware doesn't support them by default)

Result is a blank screen for both mode entries.

From log output: Smithay is erroring when creating DRM compositor with "No supported plane buffer format found"

[YaLTeR]

Implemented in #2479