> In X11, you can do it with xrandr --fbmm

Yeah, that's basically what I want, but for sway.

> Wayland applications should not be using that information to decide scaling. They should be using the wl_output.scale.

Maybe so, but the physical size is definitely exposed to the clients via the wayland protocol (see below). I'm pretty sure that the QT toolkit and Chromium both use the reported values.

    <event name="geometry">
      <description summary="properties of the output">
    The geometry event describes geometric properties of the output.
    The event is sent when binding to the output object and whenever
    any of the properties change.
    
    The physical size can be set to zero if it doesn't make sense for this
    output (e.g. for projectors or virtual outputs).
      </description>
      <arg name="x" type="int" />
      <arg name="y" type="int" />
      <arg name="physical_width" type="int" />
      <arg name="physical_height" type="int" />
      <arg name="subpixel" type="int" enum="subpixel" />
      <arg name="make" type="string" />
      <arg name="model" type="string" />
      <arg name="transform" type="int" enum="transform" />
    </event>

I will probably end up hacking it into sway, like I've done with other things.

It's just that the swaywm/libwlroots codebase is so utterly illegible. "wlroots is largely documented through comments in the headers. Read 'em." Yeah, those headers with no comments anywhere, egregious amounts of boilerplate code (because C), and naming conventions that take weeks to learn. Argh. I've spent entire days trying to figure out "how to I get a sway_foo pointer from a wlr_foo pointer". It's madness. There's so much typecasting going (with totally undocumented rules for when said typecasts are safe) on that you can't even use the compiler-visible types as a guide for these kinds of questions.