| Summary: | emacs misdraws cursor and some other things when compositing is active | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Winship <danw> | ||||||
| Component: | xorg-x11-drv-intel | Assignee: | Adam Jackson <ajax> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rawhide | CC: | airlied, ajax, corbet, dwalsh, jonathan.underwood, kklic, mcepl, michel, myhity, nareshov, otaylor, rjones, sandmann, xgl-maint | ||||||
| Target Milestone: | --- | Keywords: | Patch, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | xorg-x11-drv-intel-2.14.0-5.fc15 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-04-15 21:43:01 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Dan Winship
2011-01-27 14:57:43 UTC
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. |