Hide Forgot
In rawhide, under either compiz or gnome-shell, emacs doesn't draw its cursor correctly. Sometimes it doesn't update it at all (and so when you move it around, it appears to stay where it was until you do Ctrl-L). Other times it leaves a trail of pixel junk behind as it moves. Miscellaneous other bits of non-font-related drawing (underlines, parenthesis highlighting, etc) have the same problem; sometimes they don't get erased (either partially or entirely) when they should. I haven't noticed any problems with font drawing though. (And when I run in plain metacity or other non-composited wm, everything draws fine.) emacs-23.2-17 xorg-x11-server-Xorg-1.9.99.1-3.20101201 xorg-x11-drv-intel-2.14.0-1 (on a Thinkpad X61 tablet with 965GM graphics)
actually, this happens if I run the F14 emacs under rawhide X too (whereas F14 emacs under F14 X is fine), so I guess it's X, not emacs that's messing up?
I could reproduce it very easily in gnome-shell with jakoubek:sixties $ lspci |grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) jakoubek:sixties $ lspci -n |grep 00:02.0 00:02.0 0300: 8086:2a42 (rev 07) jakoubek:sixties $ and xorg-x11-server-Xorg-1.9.99.1-3.20101201.fc15.x86_64 xorg-x11-drv-intel-2.14.0-1.fc15.x86_64 emacs-23.2-17.fc15.x86_64 Just driving with cursor over the screen leaves behind traces of black rectangles. However, I cannot reproduce it with any other program. I would suspect some bug between emacs and libX11 (or pango/cairo).
Created attachment 476289 [details] strace of running emacs
I cannot attach ltrace and I don'ŧ see any errors in /var/log/XOrg.0.log or dmesg.
Using ssh between my f14 box and my rawhide box, running the f14 machine's emacs under the rawhide X server shows the bug, while running the rawhide machine's emacs under the f14 server does not. So it's definitely server or driver, not anything client-side.
<me too> Intel Q35 graphics, in case that's useful. Let me know if there's any other useful information I can provide.
Another oddity: if you turn on the magnifier in gnome-shell, the magnified version of emacs draws correctly. cc:ing Owen since he may have more insight on what that tells us... (keeping in mind that it happens under compiz too, so it's not a clutter bug. GLX bug?)
I'm wondering if damage is generated correctly for emacs' glyph drawing. Recently, I happened to notice that in EXA/UXA, glyphs that are drawn with format=None may not generate damage events because EXA/UXA don't go through the Composite hook, but just call their own composite routines. That could explain this bug, but I haven't verified that the X server bug actually exists, or that emacs would trigger it. If the magnification feature is less aggressive about clipping to damaged regions (which seems likely given that correctly scaling a damaged region would be a bit complicated), that could explain why it doesn't happen in that case.
A way to verify that this is the issue would be to turn off 2D acceleration for the driver, but I don't know if you can do that without also turning off 3D.
as an aside I've noticed that emacs over remote ssh misrenders its task-bar icons here, from rawhide client to EL6 server (no idea if its related).
Fixed by http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=da990536eca09c6de74627541cd56ecfad925eda qv https://bugs.freedesktop.org/show_bug.cgi?id=32734 can we get that in?
Created attachment 488763 [details] upstream patch
*** Bug 676934 has been marked as a duplicate of this bug. ***
*** Bug 692232 has been marked as a duplicate of this bug. ***
Would be great if we can get this in -- it should not be affected by the beta freeze, right?
I applied the patch to the latest F-15 xorg-x11-drv-intel build and did a Koji scratch build -- so far it's fixed the problem, and I've not noticed any regression: http://koji.fedoraproject.org/koji/taskinfo?taskID=2978237 Could an official update be issued?
xorg-x11-drv-intel-2.14.0-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.14.0-5.fc15
Package xorg-x11-drv-intel-2.14.0-5.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-intel-2.14.0-5.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.14.0-5.fc15 then log in and leave karma (feedback).
xorg-x11-drv-intel-2.14.0-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.