GNU bug report logs -
#63384
x-display-mm-width and x-display-mm-height both return 0 on wayland
Previous Next
Full log
Message #8 received at 63384 <at> debbugs.gnu.org (full text, mbox):
tomasralph2000 <at> 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?
This bug report was last modified 2 years and 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.