bug#63384: x-display-mm-width and x-display-mm-height both return 0 on wayland

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

tomasralph2000@gmail.com writes:

> The functions "x-display-mm-width" and "x-display-mm-height" both return
> 0 on Wayland, but on a specific display.
>
> I also have a laptop with the same setup (Arch Linux on Hyprland as
> window manager) and a similar emacs version (I compiled both on my
> desktop and laptop about ~1 hour from each other, my laptop went
> first). This problem is not present on my laptop.
>
> These functions should return the dimensions of my display in
> milimiters, as one would assume. This issue is causing numerous features
> to fail with an "Arithmetic Overflow Error" since at some point they
> divide by this number, and division by 0 is problematic of course.
>
> Most built-in games are broken (like tetris or snake) since they depend
> on these functions to compute the size of the game grid.
>
> More importantly, latex previews on org files are also broken, since
> they use the value to render the images.
>
> If I switch to X11 (more specifically, qtile) with this same setup, the
> functions return proper values, and these features are fixed.
>
> If I launch emacs with the "GDK_BACKEND" environment variable set to
> "x11" then emacs launches using xWayland, and once again, the functions
> return proper values and the issue is "fixed".
>
> This seems to be an issue with GTK, rather than emacs. I found another
> user complaining about this here:
> https://discourse.gnome.org/t/gdk-monitor-get-width-mm-failure-wayland/5412
>
> Since there doesn't seem to be much the emacs developers can do about
> this, I propose a workaround is set in place.
>
> The functions that return the display size in pixels do work. Maybe
> emacs could check if the mm dimensions are being reported as 0, and try
> to guess appropiate values. They may be wrong, but it's a better option
> than having these features outright fail with non-descriptive errors.
>
> Alternatively, since we now know that these functions can return 0,
> maybe it's more appropiate to put a check in place, and fail with a more
> descriptive error message.
>
> In the thread I linked, there's a code snippet of the xorg source code
> that showcases it doing exactly that. Maybe emacs could do the same.
>
> It is likely that my monitor is the problem here (it's a cheap one). It
> may not have these values properly set in its firmware. Probably Xorg
> isn't getting proper values either, and it may be relying on that code snippet.
>
> This would also explain why it works on my laptop.

I don't want to work around these painfully obvious GTK bugs, because
that just gives their developers an excuse to keep things broken.

Would you please report this to their developers?