No, it's not a Gala/Cinnamon issue, when I have it on other window managers too and only under Catalyst driver. And as mentioned doesn't happen on other drivers. Or does mesa/gallium also have wrong GLSL and whatever else specs.
I've asked to at least include Gnome Shells fixes on Gala and Cinnamon as well by default(note, I don't use Cinnamon, only test now and then). If that gets some response, I'll go on with more things to report, but I don't see much that traction in non game bugs.
I mentioned KWin to show you one(of many) example where developers have to treat Catalyst as a special case. Compiz also does that a LOT. Don't you think something is wrong with that?
In "no hacks mode" I can't even take proper screenshots(they might show the background, they might show an application that was previously open, weird stuff). Is that a window manager problem too? Again Catalyst specific.
Certainly everyone is broken and Catalyst follows everything to the letter, but most applications are apparently also developed in a broken way. Do you think that's how it is?
I am not an opensource driver fanatic, but at least the open drivers seem to (mostly) work without bugs when a spec is implemented. At least they are implemented properly I mean and no application specific hacks are used. Certainly I can't say quite the same for nvidia. But can you claim that such a different behavior just by renaming an executable file is not rational from a properly working driver. Past experiments have shown certain OpenGL extensions to be available or not depending on the name of application(let's say compiz). I haven't tested much on that now(not enough knowledge on my part), but I hope it's not as bad as it used to. Because having GLX_EXT_texture_from_pixmap or whatever(I don't completely recall the name of the extension) only when you're named compiz(probably a few other names as well) is pretty wrong from my point of view at least. (And racist, lol)
Btw, that's a bugfix update for Shell/libmutter, still it should be backported, but who am I who know whatever genius versioning system they'd use.
May I suggest an experiment. Copy "gnome-shell" executable to a file with another name. Run "/path/to/new-name --replace". See how well it runs on Catalyst now that application specific bug was fixed. You can try it with other wm's too. Maybe it runs fine, maybe not, who knows.
I wondering, did you know Cinnamon uses Muffin that fork of Mutter, and Gala is based on libmutter (maybe fork, I doesn't know) so both of them may share bugs with Gnome Shell?
No, where you read that?
I just say, even if some specific issue reproducible only with Catalyst, it doesn't mean it's Catalyst fault. That may be Catalyst fault, maybe not.
At least two hacks already there:
http://www.phoronix.com/vr.php?view=MTA0ODY
http://www.phoronix.com/vr.php?view=MTI2OTg
btw, maybe you will be interested in /etc/ati/atiogl.xml content.
I know they all use libmutter. That's why they have common bugs, as well as fixes. Why does that matter? If I can find the same bug on KWin, or even Openbox in some cases and Compiz.
I was just saying, if most stuff works well on the other drivers and not Catalyst, maybe that leads to a conclusion? No conclusion is 100%, but application specific bugs don't seem to be the most likely though.
Indeed, it is unfortunate "hacks" are used/needed, and I wasn't really aware of that. But compared to what I mentioned, I think there are significant differences.
Interesting, thanks for telling me about /etc/ati/atiogl.xml. Although I couldn't really make that much out of it. At least I can add whatever window manager I want there and not have a weird sitation with renaming executables on every upgrade .. In fact, Mint could use a modified fglrx package with Cinnamon in there was well to help a bit, as a temporary "fix".
Although I think not everything is there regarding profiles/hacks etc.
Mostly the glitches for fullscreen applications. And visible lag when moving/resizing windows(barely any with radeon), but that's not as much of a "bug", but still could take much improvement. Like Vsync/tearing(you can have tear-free experience or almost tear free, but it introduces some lag..). Those aren't KWin specific.
If I recall correctly the bug is that accelerated fullscreen windows are on the foreground no matter what. Even when the right click menu appears for example or Expose/Expo effect is triggered, they're still on the front.
Or is this a Xorg whatever bug? It's present on most(if not all) compositors I tried, and couldn't reproduce with different driver/GPU so I doubt.
I'd say the chrome case is application specific, but the same happens with games too and seems to be again only under Catalyst driver.
I don't know exactly what happens in this case, but it's mostly able to happen in any compositor under similar or different circumstances, glitchy graphics for a moment when transitioning between login/logout screens and desktop, game and desktop, when changing volume or something like that while a fullscreen accelerated window is active(apparently because the sound-notification thing goes above it). In some cases the glitched graphics may persist. I think t has to do with changing display buffer or something, but don't really know. With radeon all that is pretty smooth.
I remember this one, that probably because compositor doesn't use direct rendering of OGL2 with fglrx (because it was slow). Anyway, that fixed since fglrx 8.97. KWin is using direct rendering with fglrx since KDE 4.10 (also direct rendering may be forced using KWIN_DIRECT_GL=1 variable on KDE 4.8 and 4.9).
If this still happen for you on KDE 4.10 and some latest fglrx (8.97+) - record video, fill ticket, attach /usr/share/fglrx/atigetsysteminfo.sh report.
What Chrome case? As I remember Chrome developers whitelist fglrx 8.98 and newer.
I tested these drivers on MSI AMD X370 E-350 APU in Kubuntu 12.10 with KDE 4.9.5 and my kernels - based on: Linux-3.7.5 and 3.8-rc6 ... and they are slower than Catalytst 13.1:
- the environment is less liquid,
- gaming performance is either comparable to or lower than the 13.1
Regards
Last edited by ext73; 02-03-2013 at 04:58 AM.
Has anyone else had trouble with adjusting backlight on 13.2 beta?
I installed it yesterday (Ubuntu 12.10), and when I tried do adjust the backlight on my E-350(Lenovo Ideapad S205), most of the times it was ignored (the system notification would pop up and act as if something was happening, but the backlight would not change).
I tried restarting and same thing, then I reinstalled 13.1 and it went away. I'll try again today to see if it really was the beta driver acting up.