ddevault: i read through your pr. It looks good. Sadly i also dont know what the currently prefered opinion is. 3.1 release was far more important to most ppl than discussing the display abstraction.
have u looked at: https://github.com/godotengine/godot/pull/16744/files

It is using a different approach. instead of inheriting from os_generic_unix the os_unix class gets a implementation of the abstract class DisplayDriver. (Could be DisplayDriverWayland or DisplayDriverX11 or even DisplayDriverDummy to have a godot "server" version for running a gdscript interpreter, or a multiplayer server...) wmww and I ran into issues with that approach (i think) or we just decided the inheritance is the better way to go.

int OS_Wayland::get_screen_dpi(int p_screen) const {
	if (p_screen == -1) {			if (p_screen == -1) {
		p_screen = get_current_screen();				p_screen = get_current_screen();
	}			}
 	if (p_screen < 0 || p_screen >= outputs.size()) {		 	if (p_screen < 0 || p_screen >= outputs.size()) {
 		return 72;		 		return 72;
 	}		 	}
 	return outputs[p_screen]->scale * 72;		 	// 192 is the magic value at which the godot editor automatically scales
 	// itself up. 96 is 192/2.
 	return outputs[p_screen]->scale * 96;
 }		 }

I have a question about that function:
Is the concept of having access to the actual mm size of the deprecated in wayland? so you just get the desired scale factor which informs applications about the UI<->pixel relation?

How did you stop sway from just upscaling the rendered buffer (which resulted in a blurry editor)?

In reply to @ddevault:matrix.org
as for fixing the upscaled buffer, the solution is to create a buffer twice as large and use wl_surface_set_scale(..., 2)