Hide Forgot
Description of problem: After hitting numerous show-stoppers with the nouveau driver in Gnome 3 / gnome-shell (dual monitor desktop usage/support is horrible, displays often never wake after being turned off, can't switch to single monitor mode after both have been enabled, etc, etc, etc) I decided to give the proprietary driver a shot. The "good" news (okay, so I'd love to see the open source nouveau driver be able to do everything I want so maybe calling it good news isn't exactly the right phrase to use) is that the nvidia module behaves *much* better for most tasks so far. The biggest current issue I'm seeing is there are problems with certain applications not showing their refreshed content properly now since the switch over. This was a known issue in older versions of Gnome with Compiz, and a work around in Compiz was developed that could be toggled via "force_glx_sync". From what I can tell, there is no equivalent functionality in gnome-shell, and I'm hoping it is something that can be implemented as the problem is manifesting itself identically for me again. There are a bunch of various detailed explanations of the issue floating around the web currently if you need a reference point for where this is coming from. A quick search of Red Hat Bugzilla turned this up: https://bugzilla.redhat.com/show_bug.cgi?id=474741 which gives a brief description and has some other links that may be of use in understanding the problem. I'm hoping I'm not going to just be told to blindly go suck eggs since I'm using the proprietary driver... Version-Release number of selected component (if applicable): Most recent F15-Beta packages from the public repository. How reproducible: Pretty frequently in my terminal when the screen needs to be redrawn. Much less so in other applications. Steps to Reproduce: 1. open terminal 2. perform some random tasks that redraw/output characters (seems to be most obvious in things like scrolling through a document with less, and an IRC client when new channel text arrives, though it can happen on simple command line output from things like "ls" as well) Actual results: Text that should be outputted is not displayed. Doing something to force the window manager to re-draw the window will then show the output that occured since the last update. Minimizing and restoring the window, switching to a different terminal tab and back again, etc. Expected results: Screen/text updates should draw properly when they are outputted. Additional info: This does in fact seem to only plague me with the nvidia driver at the moment and not nouveau, but as per other investigation (including some of the info/links in the post I referenced above) this doesn't seem to be something blindly blamed on the proprietary driver alone. I'm hoping that since it was deemed acceptable to include the workaround in Compiz, that something similar can be implemented in gnome-shell as well.
The original poster mentions that the redraw problem is encountered in a "terminal". I have been unable to reproduce the problem in a gnome-terminal, but it is frequently manifested in an xterm, to the point of making the xterm difficult to use. Fedora15 / Nvidia driver.
... same for me. Xterm is de-facto unusable in gnome-shell+Nvidia drivers (Dell Latitude e6500, i686). However nouveau is pretty unusable for all the rest...
Reassigning this to clutter since it's up to the screen drawer to fix this.
(In reply to comment #3) > Reassigning this to clutter since it's up to the screen drawer to fix this. clutter doesn't draw the screen. It's a library which abstracts GL/GL-ES from the application. It passes the GL through to the driver to actually render so its up to the driver to provide this interface. The driver is what should be providing the option "force_glx_sync" or more likely actually fix the driver so the issue doesn't need hacks, whether the UX then chooses to provide the option to enable/disable this is up to upstream. Does the driver provide the ability to set this either in the xorg.conf or via their proprietary management GUI? Closing this as CANTFIX as the request for a UI option needs to go upstream and the driver issues need to go to the vendor as its closed source as we can't fix this.
Yes NVIDIA's drivers are screwed, but it doesn't mean that it can't be worked around in gnome3. I'm pretty sure (but not 100%) that clutter is the one responsible for telling the backend to redraw a given section of the screen. All that needs to be done is to drop glXWaitX(); before redrawing the screen to allow the outstanding X commands to finish before redrawing the screen. If clutter isn't the one actually responsible for making the screen drawing actually happen, that is it's not the one executing the actual opengl commands to the driver, then of course this bug doesn't belong with clutter, but I'm hoping a clutter developer will be able to say "Oh hey that's component Y" and reassign it to who it belongs. Closing this CANTFIX by somebody who isn't actually involved in these projects is unhelpful.
> If clutter isn't the one actually responsible for making the screen drawing > actually happen, that is it's not the one executing the actual opengl commands > to the driver, then of course this bug doesn't belong with clutter, but I'm > hoping a clutter developer will be able to say "Oh hey that's component Y" and > reassign it to who it belongs. Closing this CANTFIX by somebody who isn't > actually involved in these projects is unhelpful. It should be filed upstream then, as its a development feature request.