Description of problem: Screen changes are not always displayed immediately Version-Release number of selected component (if applicable): xorg-x11-drv-sisusb-0.9.3-1.fc12 How reproducible: Needs a few tries, but it reproduces consistently. Steps to Reproduce: 1. With a supported SiSUSB device plugged, and the xorg.conf attached 2. stop prefdm ; start prefdm 3. log into gnome, wait until the UI quietens. If you have any applet that is visually active, remove it. It is important to have _no changes_ in the display. 4. disable tooltips with gconf-editor -- at /apps/panel/global/tooltips_enabled 5. place the pointer over the 'Applications' menu. Click repeateadly to open and close it. 6. Try a few times, after less than 10 attempts, I get one where the driver forgets to paint or flush the changes to the device. 7. Move the pointer -- the changes will appear. Actual results: It sometimes forgets to display some changes. Expected results: They should get displayed immediately, always. Additional info: Happens much more noticeably on F11.
Created attachment 462460 [details] /etc/X11/xorg.conf
Tested on a F14 image on XO-1.5 -- the bug is present here as well. In my testing, it reproduces about the same frequency between F11, F12 and F14, so it is not more noticeable on F11. Instead, it is much more noticeable under Sugar. One good example is palette changes in the TurtleArt activity. This may be due to the extra care we take in Sugar to avoid extra screen refreshes/updates to conserve power (and CPU/GPU cycles) on limited-power-and-silicon XO hw.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 462676 [details] dmesg
Created attachment 462677 [details] Kernel config
Created attachment 462678 [details] Xorg.0.log
Created attachment 462679 [details] /var/log/messages
Created attachment 462680 [details] /proc/cmdline showing drm.debug param
Thanks Matej! We can also make available appropriate hardware for testing. Contact me at martin .
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening. This is definitely present on F14.
Almost certainly still present in F15. The only major "doesn't update right" bug i know of in the shadow code has to do with window borders; maybe tooltips have non-0 borders? Worth checking.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping