st, xft and ubuntu 20.04.1

Some time ago I switched to AwesomeWM and with that came another change, my default terminal emulator. Having used GNOME terminal for years, I soon switched to Terminator back in the day. Leaving GNOME behind, in search for a more lean desktop with less frills and more keyboard centric features, I also had to ditch that terminal emulator (it has too many dependencies for my use case). Eventually I stumbled upon st, which fit the bill.

st still seems almost perfect for me and I’m sticking with it, for now. There is one annoying bug though, which came to light when I started receiving e-mails with emoticons. Those emoticons crashed my ‘st’ instance!

This is actually caused by an upstream Xft bug. When emoticons are displayed, they crash st. I had to resort to using xterm sometimes, which is, well, not a great experience nowadays. I set out on a journey to fix my desktop.

FAQ

So I checked the FAQ of st and found an answer to my issue:

 ## BadLength X error in Xft when trying to render emoji
 
 Xft makes st crash when rendering color emojis with the following error:
 
 "X Error of failed request:  BadLength (poly request too large or internal Xlib length error)"
   Major opcode of failed request:  139 (RENDER)
   Minor opcode of failed request:  20 (RenderAddGlyphs)
   Serial number of failed request: 1595
   Current serial number in output stream:  1818"
 
 This is a known bug in Xft (not st) which happens on some platforms and
 combination of particular fonts and fontconfig settings.
 
 See also:
 https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6
 https://bugs.freedesktop.org/show_bug.cgi?id=107534
 https://bugzilla.redhat.com/show_bug.cgi?id=1498269
 
 The solution is to remove color emoji fonts or disable this in the fontconfig
 XML configuration.  As an ugly workaround (which may work only on newer
 fontconfig versions (FC_COLOR)), the following code can be used to mask color
 fonts:
 
     FcPatternAddBool(fcpattern, FC_COLOR, FcFalse);
 
 Please don't bother reporting this bug to st, but notify the upstream Xft
 developers about fixing this bug.

The solution

Checking issue 6 at xft shows me that this is an active issue. Reading the posts I found this merge request which solves the issue in xft, but it is still being worked on by Maxime Coste.

Waiting for the patch to be finalized in xft, then released and then used in my Desktop distibution of choice (currently Ubuntu 20.04) will take too long (yes, I am impatient). So, I decided to patch libxft2 manually on my system, using the patch by Maxime (thank you Maxime!). I also created my own patch file, since I had merge errors. Here are the instructions:

apt-get source libxft2
patch -p0 < modified_for_ubuntu_20.04.1.patch
debuild -b -uc -us
sudo dpkg -i ../libxft2_2.3.3-0ubuntu1_amd64.deb

FAQ

The solution

attachments