Summary: | [G45] glyph updating is broken in some applications (especially emacs), other minor glitches | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | walch.martin | ||||||||||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||
Severity: | normal | ||||||||||||||||
Priority: | medium | ||||||||||||||||
Version: | unspecified | ||||||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||||||
OS: | Linux (All) | ||||||||||||||||
Whiteboard: | |||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||
Attachments: |
|
Description
walch.martin
2012-01-31 04:53:13 UTC
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.