recent libx* upgrade issues

Painless · 2012-03-09 20:54:15

Hi all!

I upgraded a number of packages today on my laptop today. I upgrade often so this wasn't a huge upgrade. After rebooting, I noticed that xmessage and xclock were using lots of CPU (about 60% of a core each), and that rxvt-unicode (Monaco font) was much wider than it used to be. I tried downgrading the kernel and nvidia driver, no change, so I reverted to the latest versions again. Then I downgraded the recent libx* upgrades, specifically:

libxext (1.3.1-1 -> 1.3.0-2)
libxxf86vm (1.1.2-1 -> 1.1.1-2)
libxxf86dga (1.1.3-1 -> 1.1.2-2)
libxv (1.0.7-1 -> 1.0.6-2)
libxvmc (1.0.7-1 -> 1.0.6-2)
libxtst (1.2.1-1 -> 1.2.0-2)
libxt (1.1.2-1 -> 1.1.1-2)
libxss (1.2.2-1 -> 1.2.1-2)
libxres (1.0.6-1 -> 1.0.5-2)
libxrender (0.9.7-1 -> 0.9.6-2)
libxpm (3.5.10-1 -> 3.5.9-2)
libxmu (1.1.1-1 -> 1.1.0-2)
libxkbfile (1.0.8-1 -> 1.0.7-2)
libxinerama (1.1.2-1 -> 1.1.1-2)
libxft (2.3.0-1 -> 2.2.0-2)
libxdmcp (1.1.1-1 -> 1.1.0-2)
libxcursor (1.1.13-1 -> 1.1.12-1)

Which fixed both the high CPU for xclock and xmessage and the "wide font" issue. xclock and xmessage are used by the xdm-arch-theme package from AUR.

I'm using i686 and my (Dell) laptop has an NVidia 8600M GT.

Has anyone else experienced this?

Rob

berbae · 2012-03-10 10:02:25

I use xclock in Openbox on my x86_64 system, and I don't notice any higher cpu usage with it after updating to the last versions of these libx* packages.
I don't use xdm.
Have you tried without the xdm-arch-theme package?

ReinisFMF · 2012-03-10 10:21:45

Hi!

I can confirm the font issue. (rxvt-unicode, DejaVuSansMono font) Downgrading libxft solved it.

I made some screenshots to compare the situation after and before upgrade:
FluxBB bbcode test

Found this:
http://cgit.freedesktop.org/xorg/lib/libXft/tree/NEWS

Version 2.3.0
Subpixel LCD text rendering improvements

I think the subpixel rendering improvements are guilty here (you can zoom in the image to see the effect).

Cheers!

loafer · 2012-03-10 10:56:32

The new version of libxt also breaks xscreensaver. It outputs corrupted graphics and the CPU hits 100%. Rebuilding screensaver does not wok but downgrading libxt fixes it. These a bug report regarding another problem too - FS#28844.

J. · 2012-03-10 11:27:42

Upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=47178

AndyRTR · 2012-03-10 11:47:54

Are you all running old Xorg from extra? I don't see anything broken on my testing systems with recent Xorg.

loafer · 2012-03-10 12:08:49

I'm running with a fully up-to-date testing.

bernarcher · 2012-03-10 13:31:44

I can confirm the urxvt issues with libxft 2.3.0-1. Downgrading to libxft 2.2.0-2 helped.

berbae · 2012-03-10 16:05:32

loafer wrote:

The new version of libxt also breaks xscreensaver. It outputs corrupted graphics and the CPU hits 100%.

I do not see that here: xscreensaver works the same as before the upgrade to libxft 2.3.0-1 and libxt 1.1.2-1.

HoZ · 2012-03-10 19:57:39

The problem I now have with xscreensaver after these upgrades, only involves specific screensavers that must load images from a user-defined location (GLSlideshow, photopile, etc..) Xscreensaver returns:

Warning: Select failed; error code 5

Painless · 2012-03-10 21:44:57

Hi all,

Thanks for the input - libxft downgrade has certainly sorted out the urxvt font width problem. Alas, xclock and xmessage still use high CPU, though I've managed to narrow it down to one (or maybe all) of these three:

libxmu
libxext
libxt

Reverting to earlier versions of these stops xclock and xmessage high CPU usage.

Rob

Last edited by Painless (2012-03-10 21:45:19)

loafer · 2012-03-10 21:49:00

Ignore this post, I misread the previous post.

Last edited by loafer (2012-03-10 21:51:45)

darkfeline · 2012-03-11 15:38:42

I am experiencing the same problem as HoZ

loafer · 2012-03-11 16:19:09

darkfeline wrote:

I am experiencing the same problem as HoZ

https://bugs.freedesktop.org/show_bug.cgi?id=47203

eworm · 2012-03-12 08:50:41

Just opened a bug in Arch bug tracker: https://bugs.archlinux.org/task/28875

Onyros · 2012-03-12 13:02:53

Had to downgrade and freeze libxft, too. The fonts on urxvt were unbearable - unfortunately terminus doesn't do a good job in rendering some accented characters, otherwise that's what I'd be using. Terminus rendering didn't break with the upgrade, it only happened with some fonts - Bitstream Vera Sans mono in my case.

loafer · 2012-03-12 21:07:08

libxt 1.1.2-2 fixes the problem with xscreensaver.

Painless · 2012-03-12 22:14:36

libxt 1.1.2-2 has fixed the xclock and xmessage problems for me as per https://bugs.archlinux.org/task/28844

However, libxft 2.3.0-2 does not fix the wide fonts issue.

jakob · 2012-03-15 17:40:47

I’d also like to confirm the same here. My ~/.Xresources has

URxvt*font:             xft:Bitstream Vera Sans Mono:pixelsize=13:antialias=true

and urxvt gets wider with libxft-2.3.0-2 than with libxft-2.2.0-2. Downgrade helped.

pskept · 2012-03-15 19:15:59

jakob wrote:

I’d also like to confirm the same here. My ~/.Xresources has
URxvt*font:             xft:Bitstream Vera Sans Mono:pixelsize=13:antialias=true
and urxvt gets wider with libxft-2.3.0-2 than with libxft-2.2.0-2.

ditto.

urxvt.font:   xft:Inconsolata:size=15:antialias=true:hinting=true

jjacky · 2012-03-15 19:55:28

I don't have this problem and one thing I notice is that I have antialias off myself, everybody else with the issue seems to have it on. So I guess it's probably not linked to the font/size, but antialiasing...

Onyros · 2012-03-15 20:01:55

Yup, I confirm. Only antialiased fonts are wider.

Last edited by Onyros (2012-03-15 20:08:17)

pskept · 2012-03-16 12:59:40

pskept wrote:

ditto.

urxvt.font:   xft:Inconsolata:size=15:antialias=true:hinting=true

today's update to ttf-inconsolata fixed my problem.

jakob · 2012-03-16 16:35:49

Onyros wrote:

Yup, I confirm. Only antialiased fonts are wider.

jjacky & Onyros, you are right, if I turn off antialiasing, I don’t have the width problem, however fonts become unbearably ugly…

Onyros · 2012-03-16 16:40:42

Subpixel rendering improvements are the most probable culprit. If an update to inconsolata solved the issue, it'll be a matter of time until other fonts having problems catch up.

Arch Linux

#1 2012-03-09 20:54:15

recent libx* upgrade issues

#2 2012-03-10 10:02:25

Re: recent libx* upgrade issues

#3 2012-03-10 10:21:45

Re: recent libx* upgrade issues

#4 2012-03-10 10:56:32

Re: recent libx* upgrade issues

#5 2012-03-10 11:27:42

Re: recent libx* upgrade issues

#6 2012-03-10 11:47:54

Re: recent libx* upgrade issues

#7 2012-03-10 12:08:49

Re: recent libx* upgrade issues

#8 2012-03-10 13:31:44

Re: recent libx* upgrade issues

#9 2012-03-10 16:05:32

Re: recent libx* upgrade issues

#10 2012-03-10 19:57:39

Re: recent libx* upgrade issues

#11 2012-03-10 21:44:57

Re: recent libx* upgrade issues

#12 2012-03-10 21:49:00

Re: recent libx* upgrade issues

#13 2012-03-11 15:38:42

Re: recent libx* upgrade issues

#14 2012-03-11 16:19:09

Re: recent libx* upgrade issues

#15 2012-03-12 08:50:41

Re: recent libx* upgrade issues

#16 2012-03-12 13:02:53

Re: recent libx* upgrade issues

#17 2012-03-12 21:07:08

Re: recent libx* upgrade issues

#18 2012-03-12 22:14:36

Re: recent libx* upgrade issues

#19 2012-03-15 17:40:47

Re: recent libx* upgrade issues

#20 2012-03-15 19:15:59

Re: recent libx* upgrade issues

#21 2012-03-15 19:55:28

Re: recent libx* upgrade issues

#22 2012-03-15 20:01:55

Re: recent libx* upgrade issues

#23 2012-03-16 12:59:40

Re: recent libx* upgrade issues

#24 2012-03-16 16:35:49

Re: recent libx* upgrade issues

#25 2012-03-16 16:40:42

Re: recent libx* upgrade issues

Board footer