Created attachment 56372 [details] /var/log/Xorg.0.log With new versions of xf86-video-intel, I get curroptions of text fields, open menus and sometimes of the whole screen. This does not happen when using xf86-video-intel-2.15.0. However, for this bug report I focused on the corruption in text fields that mainly happens in emacs. The latest version from GIT has the problem (at commit 0a748fc49d60dc2bc9494f95c4934592b111831a). Bisecting brought up this: c5414ec992d935e10156a2b513d5ec2dded2f689 is the first bad commit commit c5414ec992d935e10156a2b513d5ec2dded2f689 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Oct 2 12:02:41 2011 +0100 sna: Use BLT operations to avoid fallbacks in core glyph rendering Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> :040000 040000 4a8bca74078d17b8e1f132cabb55482db2532b7a 10f4339c905b6b07214374231ae027989971cfc2 M src However, that might not contain the actual bug. When converging to that commit from the "good" side, there also appeared more and more other minor glitches like half drawn rectangles around hovered buttons, yakuake screen corruption on startup and so on. chipset: G45 system architecture: x86_64 xf86-video-intel: "module version = 2.17.0" xserver version: 1.11.3 mesa version: 7.11.2 libdrm version: 2.4.30 kernel version: 3.2.1-gentoo-r2-libre Linux distribution: Gentoo Machine or mobo model: Asus P5Q-EM Display connector: VGA | DVI Reproduce steps: - run emacs in X and do something that modifes the buffer display Attachments: -- Xorg.0.log -- dmesg output -- screenshot
Created attachment 56373 [details] dmesg > dmesg
Created attachment 56374 [details] screenshot of corrupt emacs buffer, created with ksnapshot
Can you please attach the text shown in the buffer, and also a screenshot of the good state?
Created attachment 56379 [details] emacs right after starting up
Created attachment 56380 [details] corrupt buffer in emacs I have run emacs now with LC_ALL=C, instead of localized. This is now exactly what I get when - running "LC_ALL=C emacs" - moving the mouse to "Emacs Tutorial" and making a left click Nothing else. Especially I did not touch the keyboard (except the print key for the screenshot)
Created attachment 56381 [details] file TUTORIAL that is displayed This file is part of GNU emacs 23.3. (On my system I found it at /usr/share/emacs/23.3/etc/tutorials/TUTORIAL)
Thanks, that makes the form of the corruption much easier to recognise, it looks more like overdrawn glyphs, or perhaps incorrect choice of glyph for a character. Do you see similar corruption occurring in xterm/rxvt/xpdf/etc, or does it seem to be limited to emacs?
I dare say that this fresh installation of emacs is using Render glyphs. Presumably the font is selectable through an rc? Do you have a copy of your rc that I can use to recreate your setup?
> Do you see similar corruption occurring in xterm/rxvt/xpdf/etc, or > does it seem to be limited to emacs? Looks much like it is emacs only. I came across other graphic bugs, but regarding text and fonts, I did not see happen anything similar in other programs. (Besides lots of KDE and some GTK applications, I have tried now xterm, rxvt, xpdf, xmore, xman, xgc...) > I dare say that this fresh installation of emacs is using Render glyphs. > Presumably the font is selectable through an rc? Do you have a copy of > your rc that I can use to recreate your setup? I must admit that I do not know much about configuring emacs. However, when compiling a vanilla emacs build, I came across the configure option --with-xft respectively --without-xft. Ta-da! --without-xft brought up the font problem, while --with-xft did not trigger it. So I hope the list of steps I made to build and run the version of emacs with broken fonts answers your question: wget http://ftp.gnu.org/pub/gnu/emacs/emacs-23.3b.tar.bz2 tar -xpf emacs-23.3b.tar.bz2 cd emacs-23.3 ./configure --prefix=$(echo ~) --without-xft make make install ~/bin/emacs Before doing that, I removed all emacs and xemacs packages I found from my system. Furthermore I made sure that these files and directories did not exist: ~/.emacs* ~/.font* ~/.Xresources
Thank you, I was able to reproduce the corruption in emacs after building it from scratch. The issue appears to simply be me misunderstanding the spec for ImageGlyphs, I will have a finished patch in the morning.
(In reply to comment #10) > The issue appears to simply be me misunderstanding the spec for ImageGlyphs Do the specifications need a clarification accordingly, so future developers have better chances to avoid that pitfall? > I will have a finished patch in the morning. Great. This was quick. Thank you.
Thankyou for the report, please let me know if you see any more corruption. commit c8fc2cde53ef7aa011ec7c47e7fc5486de0651f5 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Feb 1 01:27:43 2012 +0000 sna: Fill extents for ImageGlyphs The spec says to fill the characters boxes, which is what the hardware does. The implementation fills the extents instead. rxvt expects the former, emacs the latter. Overdraw is a nuisance, but less than leaving glyphs behind... Reported-by: walch.martin@web.de Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45438 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #11) > (In reply to comment #10) > > The issue appears to simply be me misunderstanding the spec for ImageGlyphs > > Do the specifications need a clarification accordingly, so future developers > have better chances to avoid that pitfall? Possibly, but at this moment in time, the answer would be we have a reference implementation, if in doubt refer to that. The spec refers to character boxes which matches exactly what the hardware does. I should have known that would be too easy! ;-)
> Thankyou for the report, please let me know if you see any more corruption. Works perfectly. :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.