Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

bug#43128: Acknowledgement (27.1; DPI change not detected after switching to Emacs 27.1)

0 views
Skip to first unread message

Vincent Bernat

unread,
Sep 2, 2020, 3:29:06 AM9/2/20
to 43...@debbugs.gnu.org
Hey!

After investigating a bit, I see that `read_settings()' is correctly
called and the DPI retrieved is correct. However, `apply_xft_settings()'
seems to be a noop for me. I am using the Debian package for
experimental. In the build logs, for the GTK build:

#v+
cd debian/build-gtk && CFLAGS="-g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" REL_ALLOC=no /<<PKGBUILDDIR>>/debian/build-src/configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-cairo --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
[...]
Does Emacs use -lxft? no
#v-

The lucid build has XFT:

#v+
cd debian/build-lucid && CFLAGS="-g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" REL_ALLOC=no /<<PKGBUILDDIR>>/debian/build-src/configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars --without-gsettings
#v-

Looking at the differences in the build, I see the GTK build tests until
FreeType then it doesn't look further for Xft:

#v+
checking for cairo >= 1.8.0... yes
checking for freetype2... yes
checking for fontconfig >= 2.2.0... yes
#v-

>From configure.ac, I see that I go into the Cairo branch which disables
Xft:

#+begin_src sh
if test $HAVE_CAIRO = yes; then
dnl Strict linkers fail with
dnl ftfont.o: undefined reference to symbol 'FT_New_Face'
dnl if -lfreetype is not specified.
dnl The following is needed to set FREETYPE_LIBS.
EMACS_CHECK_MODULES([FREETYPE], [freetype2])

test "$HAVE_FREETYPE" = "no" && AC_MSG_ERROR(cairo requires libfreetype)

EMACS_CHECK_MODULES([FONTCONFIG], [fontconfig >= 2.2.0])

test "$HAVE_FONTCONFIG" = "no" && AC_MSG_ERROR(cairo requires libfontconfig)
dnl For the "Does Emacs use" message at the end.
HAVE_XFT=no
#+end_src

So, no XFT seems to mean, no DPI change is possible. Is that expected?
--
Make sure input cannot violate the limits of the program.
- The Elements of Programming Style (Kernighan & Plauger)



Vincent Bernat

unread,
Sep 2, 2020, 3:52:05 AM9/2/20
to 43...@debbugs.gnu.org
❦ 2 septembre 2020 09:28 +02, Vincent Bernat:

> From configure.ac, I see that I go into the Cairo branch which disables
> Xft:
>
> #+begin_src sh
> if test $HAVE_CAIRO = yes; then
> dnl Strict linkers fail with
> dnl ftfont.o: undefined reference to symbol 'FT_New_Face'
> dnl if -lfreetype is not specified.
> dnl The following is needed to set FREETYPE_LIBS.
> EMACS_CHECK_MODULES([FREETYPE], [freetype2])
>
> test "$HAVE_FREETYPE" = "no" && AC_MSG_ERROR(cairo requires libfreetype)
>
> EMACS_CHECK_MODULES([FONTCONFIG], [fontconfig >= 2.2.0])
>
> test "$HAVE_FONTCONFIG" = "no" && AC_MSG_ERROR(cairo requires libfontconfig)
> dnl For the "Does Emacs use" message at the end.
> HAVE_XFT=no
> #+end_src
>
> So, no XFT seems to mean, no DPI change is possible. Is that expected?

Disabling Cairo fixes the problem for me.
--
Program defensively.

YAMAMOTO Mitsuharu

unread,
Sep 2, 2020, 4:00:07 AM9/2/20
to Vincent Bernat, 43...@debbugs.gnu.org
On Wed, 02 Sep 2020 16:28:38 +0900,
Vincent Bernat wrote:
>
> Hey!
>
> After investigating a bit, I see that `read_settings()' is correctly
> called and the DPI retrieved is correct. However, `apply_xft_settings()'
> seems to be a noop for me.

The function apply_xft_settings wasn't a no-op when I originally
removed the dependency on Xft if USE_CAIRO. But it was changed to a
no-op as a workaround for Bug#36284.

As I mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36284#8,
a proper fix would be to implement replacements for
XftDefaultSubstitute and XftDefaultSet.

YAMAMOTO Mitsuharu
mitu...@math.s.chiba-u.ac.jp



Vincent Bernat

unread,
Sep 2, 2020, 4:21:05 AM9/2/20
to YAMAMOTO Mitsuharu, 43...@debbugs.gnu.org
❦ 2 septembre 2020 16:58 +09, YAMAMOTO Mitsuharu:

>> After investigating a bit, I see that `read_settings()' is correctly
>> called and the DPI retrieved is correct. However, `apply_xft_settings()'
>> seems to be a noop for me.
>
> The function apply_xft_settings wasn't a no-op when I originally
> removed the dependency on Xft if USE_CAIRO. But it was changed to a
> no-op as a workaround for Bug#36284.

It may be a bit late now that 27.1 is released, but #36284 has an easy
workaround of moving the default face outside init, while not being able
to adapt to the current desktop DPI settings has no obvious workaround
except restarting Emacs. I'll just compile Emacs without Cairo support
for now.
--
Let me take you a button-hole lower.
-- William Shakespeare, "Love's Labour's Lost"



Eli Zaretskii

unread,
Sep 2, 2020, 10:17:05 AM9/2/20
to Vincent Bernat, 43...@debbugs.gnu.org, mitu...@math.s.chiba-u.ac.jp
> From: Vincent Bernat <ber...@luffy.cx>
> Date: Wed, 02 Sep 2020 10:20:18 +0200
> Cc: 43...@debbugs.gnu.org
>
> It may be a bit late now that 27.1 is released, but #36284 has an easy
> workaround of moving the default face outside init

Can you elaborate on that workaround? I don't think I understand what
you mean by "moving the default face outside init". Did you mean some
code change? if so, could you tell more about the change you had in
mind?



Eli Zaretskii

unread,
Sep 2, 2020, 10:20:05 AM9/2/20
to YAMAMOTO Mitsuharu, 43...@debbugs.gnu.org, ber...@luffy.cx
> Date: Wed, 02 Sep 2020 16:58:59 +0900
> From: YAMAMOTO Mitsuharu <mitu...@math.s.chiba-u.ac.jp>
> Cc: 43...@debbugs.gnu.org
>
> > After investigating a bit, I see that `read_settings()' is correctly
> > called and the DPI retrieved is correct. However, `apply_xft_settings()'
> > seems to be a noop for me.
>
> The function apply_xft_settings wasn't a no-op when I originally
> removed the dependency on Xft if USE_CAIRO. But it was changed to a
> no-op as a workaround for Bug#36284.

Bug#36284 seems to be about an issue unrelated to DPI scaling. is
there perhaps a way to keep parts of it that will allow to adapt to
the DPI change?

> As I mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36284#8,
> a proper fix would be to implement replacements for
> XftDefaultSubstitute and XftDefaultSet.

How complicate will such a change be? Will it be simple and safe
enough to allow installing such a change on the emacs-27 branch?

Thanks.



Vincent Bernat

unread,
Sep 2, 2020, 2:11:05 PM9/2/20
to Eli Zaretskii, 43...@debbugs.gnu.org, mitu...@math.s.chiba-u.ac.jp
❦ 2 septembre 2020 17:16 +03, Eli Zaretskii:

>> It may be a bit late now that 27.1 is released, but #36284 has an easy
>> workaround of moving the default face outside init
>
> Can you elaborate on that workaround? I don't think I understand what
> you mean by "moving the default face outside init". Did you mean some
> code change? if so, could you tell more about the change you had in
> mind?

Oh, sorry, I thought the problem was when setting font in the early
init. In this case, the workaround would have been to move it to the
regular init. So, nevermind.
--
All things that are, are with more spirit chased than enjoyed.
-- Shakespeare, "Merchant of Venice"



0 new messages