Summary: | Bitmap-font glyph corruption in Gnome-terminal [EXA enabled] | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Bryce Harrington <bryce> | ||||
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||
Severity: | normal | ||||||
Priority: | high | CC: | dragos.delcea, oyvind | ||||
Version: | 7.4 (2008.09) | ||||||
Hardware: | All | ||||||
OS: | Linux (All) | ||||||
URL: | https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/291040 | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Bryce Harrington
2008-11-05 14:33:12 UTC
does: Option "AccelDFS" "False" help? Disabling accelerated download-from-screen resolves the corruption issues with bitmap fonts (or non-anti-aliased fonts) in Gnome-terminal. However, it slows down immensely without this kind of acceleration. Scrolling in Gnome-terminal is unbearable, maximizing/minimizing is very slow (probably because this triggers huge redraw-operation). I prefer it faster with slight corruption ;). Also, notice that when I use a regular anti-aliased font (like Ubuntu's default Monospace), then the corruption _never_ occurs, even with accelerated DFS. [As another side note, Firefox scrolling seems not to suffer much when disabling accelerated DFS. There's also slightly more tearing when motion is rendered in Compiz.] (In reply to comment #2) > Disabling accelerated download-from-screen resolves the corruption issues with > bitmap fonts (or non-anti-aliased fonts) in Gnome-terminal. So it looks like at least some of the issues you reported boil down to AccelDFS being broken on your setup. Can you try if the radeon kernel module built from git://anongit.freedesktop.org/git/mesa/drm fixes the AccelDFS issues? > However, it slows down immensely without this kind of acceleration. Scrolling > in Gnome-terminal is unbearable, maximizing/minimizing is very slow (probably > because this triggers huge redraw-operation). > > I prefer it faster with slight corruption ;). Also, notice that when I use a > regular anti-aliased font (like Ubuntu's default Monospace), then the > corruption _never_ occurs, even with accelerated DFS. This is because anti-aliased font rendering is accelerated whereas aliased font rendering is not (which BTW is fixed in current upstream xserver Git). (In reply to comment #3) > (In reply to comment #2) > > Disabling accelerated download-from-screen resolves the corruption issues with > > bitmap fonts (or non-anti-aliased fonts) in Gnome-terminal. > > So it looks like at least some of the issues you reported boil down to AccelDFS > being broken on your setup. > > Can you try if the radeon kernel module built from > git://anongit.freedesktop.org/git/mesa/drm fixes the AccelDFS issues? I will try this later (when I get home from work ;) and report back. <snip> > This is because anti-aliased font rendering is accelerated whereas aliased font > rendering is not (which BTW is fixed in current upstream xserver Git). > Ah, I see :). The only place I ever use a non-antialiased-font is in Gnome-terminal, because the classic MiscFixed 6x13 just has unbeatable clarity. I am not quite familiar with git, yet, but did: $ git clone git://anongit.freedesktop.org/git/mesa/drm $ cd linux-core; make Installed the modules drm.ko and radeon.ko into kernel module tree. Ran a depmod and re-loaded modules and started up X: [87994.909647] [drm] Num pipes: 1 [87996.157780] [drm] Loading R500 Microcode [87996.157864] [drm] Num pipes: 1 [87998.280369] [drm] Num pipes: 1 [88041.332267] [drm] Module unloaded [88066.769737] Symbol init_mm is marked as UNUSED, however this module is using it. [88066.769757] This symbol will go away in the future. [88066.769763] Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. [88066.800478] [drm] Initialized drm 1.1.0 20060810 [88066.805623] radeon 0000:01:00.0: setting latency timer to 64 [88066.805902] [drm] Initialized radeon 1.29.0 20080613 on minor 0 [88096.034523] [drm] Setting GART location based on new memory map [88096.037116] [drm] Loading R500 Microcode [88096.037228] [drm] Num pipes: 1 [88096.037245] [drm] writeback test succeeded in 1 usecs The date reported for the radeon module is newer than what comes with Ubuntu, so I'm pretty sure I'm running with the updated module. But .. it did not resolve the issue :(. It works fine, but the problems are still there. *** Bug 18398 has been marked as a duplicate of this bug. *** Upating to latest radeon DRM kernel module had another positive side effect, it seems: it fixed OpenGL VSYNC support. I no longer get something like "drmWaitBlank returned -1: IRQs not working" (or similar) when forcing VSYNC through the vblank_mode parameter. I need this because Textured Video has severe tearing problems, while fullscreen OpenGL with VSYNC is perfect for movies. Sorry for the off-topic comment, I'm just happy I can now watch movies properly with the radeon driver :) I'm seeing radio-button corruption in firefox; gentoo 32bit, xorg 1.5.3 (no compiz), latest radeon git (EXA/DRI1 enabled), kernel 2.6.29 - hw is thinkpad t60, radeon mobility x1400. (In reply to comment #8) > I'm seeing radio-button corruption in firefox; gentoo 32bit, xorg 1.5.3 (no > compiz), latest radeon git (EXA/DRI1 enabled), kernel 2.6.29 - hw is thinkpad > t60, radeon mobility x1400. > Please also see bug 18397, which deals with exactly this problem on ATI X1400 .. (In reply to comment #9) > Please also see bug 18397, which deals with exactly this problem on ATI X1400 > .. I found bug 18398 (Form check-box corruption in Firefox..) which was closed as a duplicate of this one, that was the reason for posting here.. (In reply to comment #10) > (In reply to comment #9) > > Please also see bug 18397, which deals with exactly this problem on ATI X1400 > > .. > I found bug 18398 (Form check-box corruption in Firefox..) which was closed as > a duplicate of this one, that was the reason for posting here.. > Yes, I understand. I initially reported four different bugs IIRC, and some of those turned out to be the same problem. Bug 18398 should be a duplicate of bug 18397 instead, because bug 18397 is more complete and has more data. *** This bug has been marked as a duplicate of bug 18397 *** |
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.