I also get corruption with gnome-shell. Also 50HZ output doesn't work anymore. My monitors show it is an unsupported mode but the even have the mode in EDID data.
Using Ubuntu 11.10 (x86) with GNOME Shell 3.2 and dual monitor set-up.
Still graphical corruption, though not constant, in different area's:
- Tooltips and scrollbar handle
- Glitches over the complete desktop when alternately hovering over two notification area icons (bottom right) a few times
Application overview appears to respond a bit slower and animates slightly less fluently
Enabling "Tear Free Video" in the CCC makes the complete desktop stutter.
In my case I see no notable improvements over 11.9. No Shell crashes/restarts so far though.
The Shell top bar still refuses to be moved to a primary monitor on the right-hand side. I'm, however, not sure if this is a driver or a Shell issue.
Last edited by Forage; 10-31-2011 at 01:04 PM.
I also get corruption with gnome-shell. Also 50HZ output doesn't work anymore. My monitors show it is an unsupported mode but the even have the mode in EDID data.
The Tear Free = stuttering and slow is the same thing that happens in KDE 4.7 if you force it to use OpenGL 2 shaders. In KDE's case, the default is it detects FGLRX and falls back to the legacy OpenGL 1.x fixed function backend.
My guess is with GNOME, there is no OpenGL 1.x fixed function backend for it to fall back to and you can't turn vsync off for mutter because GNOME = crusade against competent users who know what they need to do to make the system work right.
WIthout Tear Free on, but with kwin using vsync, you get graphical glitches if you force OpenGL 2 shaders.
But, KDE lets you turn vsync off. So if you're perfectly happy to live with tearing, then you can use the OpenGL 2 backend with kwin.
Did anyone try it with unity?
It's not broken, you need the build environment.
If you pay attention to the warnings, it's kind of obvious what all you need.
dh-modealiases, dkms, debhelper, build-essential, execstack, and dpkg-dev should be everything you need (or depend on everything anyway)
Installing from the script is a great way to get a broken system when it doesn't rebuild itself for X or kernel updates, and plows over your Mesa system files.
Bad idea. I think you got hit by this issue: http://wiki.cchtml.com/index.php/Ubu....22_after_boot
Reading documentation is often helpful toohttp://wiki.cchtml.com/index.php/Ubu...TI.27s_site.29
Actually, fglrx-updates package from the repo should have the latest Catalyst soon, and building manually shouldn't be necessary.