Bug 323065

please attach the output of "qdbus org.kde.kwin /KWin supportInformation"

Created attachment 81494 [details]
kwin support info

output of qdbus-qt4 org.kde.kwin /KWin supportInformation > kwinSupportInfo.txt

Created attachment 81495 [details]
Screenshot1

Screenshot of the issue on the latest stable driver. Note that  taking the screen shot actually fixes it (although it shows up in the screen shot).

Created attachment 81496 [details]
Screen shot demonstatring beta driver issue

Mock up on what happens in the latest beta drivers. The same on the side thing happens, but the corners also disappear (red boxes to demonstrate). Hovering over the missing corners will make the buttons visible  again, but there are transparent lines around them (i.e. only the  buttons are shown, the rest of the corner/background remains transparent). To get it fully rendered properly, the window needs to be either  resized, minimized, or something like switching tabs in it.

OK, I attached that plus 2 screen shots demonstrating the problem (note the second one is what happens on the Beta drivers - I no longer have them installed, so I just kind of mocked it up).

Things to try:

1. use the native graphicssystem
2. disable the "maximize" effect
3. disable the blur effect
(all  in "kcmshell4 kwincompositing")
4. run
   kwriteconfig --file kwinrc --group Compositing --key GLStrictBinding false
   qdbus org.kde.kwin /KWin reconfigure
   qdbus org.kde.kwin /KWin reconfigure
   qdbus org.kde.kwin /Compositor suspend
   qdbus org.kde.kwin /Compositor resume

Does any of this have any impact?

If not, run "kdebugdialog", activate "1212 (KWin)" and run "kwin --replace &"
Are there any  GL error messages when unmaximizing windows?

About the login corruption: does eventually kwin crash on login (is there any Dr. Konqui crash dialog?
If not, what's the output of "ps ax | grep kwin"?
Does it say anything like "/usr/bin/kwin --crashes 1"?

Created attachment 81505 [details]
Bad repaint (what the beta drivers look like) after changing

When enabling/disabling effects (latest stable catalyst), this happens, which is exactly what was happening all the time (when maximizing/restoring windows) in the Beta drivers.

Created attachment 81506 [details]
replacing kwin log

Attached is the terminal output when running the kwin replace command.

Created attachment 81507 [details]
ps -aux | grep kwin

Attaching output of ps -aux | grep kwin

OK, nothing really worked:

1) Had no effect
2) & 3) See my new screen shot - it had  no effect and caused the issue I said the Beta drivers had
4) This didn't help anything (in fact it kind of broke my desktop, I had to nuke my .kde4 directory, were the second and third commands supposed to be the same?)

So no (or worse impact) for those.

5) "kwin --replace &" - I attached the output from the terminal, as far as I can see/tell there were no errors

I played  around with it a bit, and changing  the compositor to XRender from OpenGL2.0 actually solves the problem. However, XRender is much slower.

Startup problem:

6) On startup, there  are no errors/crashes. I attached the output of 'ps -aux |grep kwin'. It is kind  of odd - like I said its a black desktop, then the remembered  windows popup (in the wrong place/size), this it kind of things for a  second, pops all of the windows to where they should be, kind of pauses  again, adds in the taskbar and the window decorations, and then finally the background. The entire process doesn't take too long, it just looks odd compared to say KDE 4.10.

(In reply to comment #10)
> 4) This didn't help anything (in fact it kind of broke my desktop, I had to
> nuke my .kde4 directory, were the second and third commands supposed to be the same?)

Sorry for that - i forgot that this could break GL compositing.
Resetting the value (or deleting the key) would have done - in doubt ever just delete ~/.kde4/share/config/kwinrc - no need to nuke everything.

One of them is just a copy and paste leftover (has no effect though)

> I played  around with it a bit, and changing  the compositor to XRender from OpenGL2.0 actually solves the problem.

Not much of a surprise.
For some reason mapping the updated decoration images into textures does not happen (in time)

Question is why and why on this occasion.

Last wild shot:
run "oxygen-settings", select "Window Decorations" and in the "Aniamtions" tab, just deactivate animations.
Restart kwin to be on the safe side and see what happens. (This does for sure not severely break things ;-)

> However, XRender is much slower.
Driver (fglrx) issue (for sure: already ATi had a record here and unrelated to KWin or KDE)

> 6) 
> the remembered  windows popup (in the wrong place/size), this it kind of
> things for a  second, pops all of the windows to where they should be, kind
> of pauses  again, adds in the taskbar and the window decorations, and then


Ahhh ... plasma panel containment strut updating fun.
Set all panels to "window can cover" - funky animation gone?

OK, so I tried disabling the animations per your instructions, but it had little/no effect. Also, I attached an odd screen shot I got on the newest beta driver (13.8). But yeah, I would give anything to go back to my old laptop with Intel graphics at this point, Catalyst is a pretty 'special' driver.

On the brighter side - enabling 'window can cover' on the taskbar did in fact clear up most of my funking login stuff, its just too bad I can't have it enabled all the time, heh.

Created attachment 81588 [details]
Catalyst 13.8 Beta

With the latest beta, you can get it so the button corners actually show up in the wrong window's corners.

Any updates on this? Not sure if there will be an RC3 or not, but it seems like a pretty good bug, heh.

No, but i'm not sure whether any developer is using fglrx.

- You could first try to disable all effect plugins (ie. zoom, fade etc.) but keep compositing enabled.

- Second a different decoration (try "laptop" and "plastik")

- And third indirect rendering:
   KWIN_DIRECT_GL=0 LIBGL_ALWAYS_INDIRECT=1 kwin --replace &
(temporary, so even if it breaks, it's gone with the next login latest)

OK, so disabling the effects had no effect (anyway to easily restore the default ones?). Plastik actually kind of works better - it doesn't mess up rendering  as often (although full screening a window seems to  cause half of the title bar to disappear from time to time). The laptop theme was probably more broken that Oxygen. Lastly, I tried the indirect rendering with KWin. This seemed to correct the glitches in the window decoration, however, everything overall was pretty janky, so I had reverted.

And yeah, really wish I had my ol' Intel integrated graphics back, heh. I will note though, that these issues were not present in  4.10, if that helps anything.

(In reply to comment #16)
> anyway to easily restore the default ones?
delete the kwin4_* entries in the [Plugins] section of ~/.kde/share/config/kwinrc

> The laptop theme was probably more broken that Oxygen.
It has probably unrelated issues due on the raster graphicssystem. Does it displace/drop elements as well (on the native graphicssystem)?

> Lastly, I tried the indirect rendering with KWin.
> This seemed to correct the glitches in the window decoration,
> however, everything overall was pretty janky, so I had reverted.

Does setting the tearing prevention to "full scene repaints" change anything?

> delete the kwin4_* entries in the [Plugins] section of
> ~/.kde/share/config/kwinrc

Thanks - maybe I should put a feature request in for this to be in the GUI, lol.
 
> > The laptop theme was probably more broken that Oxygen.
> It has probably unrelated issues due on the raster graphicssystem. Does it
> displace/drop elements as well (on the native graphicssystem)?

Native had no effect.

> > Lastly, I tried the indirect rendering with KWin.
> > This seemed to correct the glitches in the window decoration,
> > however, everything overall was pretty janky, so I had reverted.
> 
> Does setting the tearing prevention to "full scene repaints" change anything?
I tried this and it didn't do anything (also tried setting Catalyst's tearing prevention on and off, which did nothing)

(In reply to comment #18)
Do you compile KWin yourself (so you could revert patches)?

Atm. i'd say fglrx has issues with the texture atlas commit:
https://git.reviewboard.kde.org/r/110790/
http://commits.kde.org/kde-workspace/15d1bc6b4dbdd397c715a4036f30d58c2760357f

But it's really just a wild guess :-(

I probably could - right now I am on Arch's stable 4.11.0 release.

*** Bug 323806 has been marked as a duplicate of this bug. ***

Hey, sorry, have been rather busy traveling - is there a good tutorial or something for building KWin, and I could give it a shot.

If I knew how to undo the texture atlas commit, I would try compiling kwin without it. As it stands, there are enough other differences in the files between then and now, that I don't think I could manually undo the commit without messing something up. Unfortunately, I don't really know C++.

That being said, if there's a way for me to test this on Kubuntu 12.04 (using KDE 4.11 from Kubuntu PPA), I would be happy to do so.

(In reply to comment #23)
> If I knew how to undo the texture atlas commit, I would try compiling kwin
> without it.

That's no more trivially possible, you'd actually have to bisect to figure the breaking commit.

However, from observations in bug #323792 i wonder whether this is due to the effective ARGB state of the decoration.

You could quickly test whether (globally, Alt+MouseWheel) translucent windows (resp. an aurorae theme) are also affected for you (what would also match Joes observations on Plastik, while Laptop is always opaque)

*** Bug 323792 has been marked as a duplicate of this bug. ***

Hey, I tried the 'alt' + mouse wheel and it doesn't really appear to do anything. And remember, while better, Plastik still had some issues and Laptop was worse...

Created attachment 81856 [details]
my Xorg.0.log and kwin debug output

Well, now I've run into a whole other issue. After reinstalling the fglrx driver (I had been using the open-source driver after encountering this bug), kwin will no longer allow me to enable OpenGL compositing (any version). Looking at the kwin debug output, I get this:
--------
OpenGL vendor string:                   ATI Technologies Inc.
OpenGL renderer string:                 AMD Radeon HD 7660G
OpenGL version string:                  2.1 (4.2.12217 Compatibility Profile Context 12.104)
OpenGL shading language version string: 
Driver:                                 Catalyst
Driver version:                         2.1
GPU class:                              Unknown
OpenGL version:                         2.1
GLSL version:                           0.0
X server version:                       1.12.3
Linux kernel version:                   3.5
Direct rendering:                       no
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
kwin(2742) KWin::GlxBackend::init: Direct rendering: false
kwin(2742) KWin::checkGLError: GL error ( Init ):  "GL_INVALID_ENUM" 
kwin(2742): OpenGL 1 compositing setup failed 
QObject::connect: Cannot connect (null)::resetCompositing() to KWin::Compositor::restart()
kwin(2742): Failed to initialize compositing, compositing disabled 
kwin(2742): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up
--------

Kwin reports direct rendering as "no", but running "glxinfo | grep direct" reports this:
--------
direct rendering: Yes
    GL_AMD_draw_buffers_blend, GL_AMD_multi_draw_indirect, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, 
    GL_ARB_map_buffer_range, GL_ARB_multi_draw_indirect, GL_ARB_multisample, 
    GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_direct_state_access, 
    GL_AMD_draw_buffers_blend, GL_AMD_multi_draw_indirect, 
    GL_ARB_draw_indirect, GL_ARB_draw_instanced, 
    GL_ARB_map_buffer_range, GL_ARB_multi_draw_indirect, GL_ARB_multisample, 
    GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_direct_state_access,
--------

...and OpenGL apps and games seem to work fine and at full rendering speed. The attachment contains my Xorg.0.log and full kwin debug output.

Setting the environment variable KWIN_DIRECT_GL=1 allowed me to use OpenGL compositing again. I used the mouse wheel over the titlebar to change the window transparency, but this didn't seem to have any effect on this bug.

I've followed instructions to do a bisect on Wine before. I'd be willing to try for Kwin, but I will just need some good instructions to follow. My only experience compiling KDE components so far is using the Kubuntu source packages.

(In reply to comment #27)

> Well, now I've run into a whole other issue. After reinstalling the fglrx
> driver (I had been using the open-source driver after encountering this
> bug), kwin will no longer allow me to enable OpenGL compositing (any
> version). Looking at the kwin debug output, I get this:

This is bug #323553

Question:
Did fglrx run before with 4.11 or 4.10.5 only?

Reg. bisecting,

git clone git://anongit.kde.org/kde-workspace.git
cd kde-workspace
git checkout KDE/4.11
mkdir build
cd build
ccmake ..
[press "c", adjust installation paths - you can probably just override the present installation, what to build (kwin), build options (don't build the oxygen deco, could lead to trouble with broken ABI, press "c" again, then "g", then "q"]
cd kwin
make && sudo make install

-> if that worked, you are in position to start a bisect.
git assists you with the "git bisect" command:

   git bisect start
   git bisect good origin/KDE/4.10
   git bisect bad origin/KDE/4.11

next you recompile, install, restart kwin and see whether the bug is still there. In that cas you do

   git bisect bad

otherwise

   git bisect good

At some point git bisect will tell you the cuplrit commit (which you may post here)

Afterwards call

   git bisect reset

and you're done =)
It's gonna take some more time though (but it's of course "bisect", because you perform a binary search, ie. you won't test every commit but narrow the good/bad frame)

(In reply to comment #26)
> Hey, I tried the 'alt' + mouse wheel and it doesn't really appear to do
> anything.

The behavior can be configured in "kcmshell4 kwinoptions", "window actions" tab, lower group.

> And remember, while better, Plastik still had some issues
Yes, but as I understood they were not exactly the same type?
(Maybe also try some Aurorae theme, ie. what you get via "Get New Decorations")

> and Laptop was worse...
Laptop is never effectively ARGB (unlike Oxygen, which has rounded corners on non-maximized windows), so this actually stresses the pattern.

(In reply to comment #28)
> compositing again. I used the mouse wheel over the titlebar to change the
> window transparency, but this didn't seem to have any effect on this bug.

Forgot:
this could imply it would really depend on the texture depth and not the render path.
Did you check Aurorae themes or Plastik?

(In reply to comment #29) 
> Question:
> Did fglrx run before with 4.11 or 4.10.5 only?

It ran with both, but the fglrx driver version was different (I think it was 12.103). Upon reinstalling fglrx, a newer version was available (12.104) from the xorg-edgers repository, and I no longer can install 12.103. It also fails with 13.200, which I'm avoiding because it causes hard-freezes on my laptop. So, perhaps the direct rendering test fails with the newer drivers?

I'm compiling kwin right now. Assuming kwin installs and runs correctly, I should hopefully have a bisect report for you shortly.

(In reply to comment #32)
> (In reply to comment #29) 
> > Question:
> > Did fglrx run before with 4.11 or 4.10.5 only?
> 
> So, perhaps the direct rendering test fails with the newer drivers?
Either the newer (legacy?) driver does no longer work on OpenGL 1.2, you missed calling "aticonfig --initial", or AMD changed internal driver version counting (so you had > required version and now no longer)

> I'm compiling kwin right now. Assuming kwin installs and runs correctly, I
> should hopefully have a bisect report for you shortly.

Many thanks - I'll check back tomor... next week ;-)

Just FYI, I'm having to run "git bisect skip" on some of the commits (3 out of 5 so far) due to OpenGL rendering refusing to start up at all. Kwin's output for these commits:

kwin(27367) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(27367): Could not find a framebuffer configuration for depth 32. 
kwin(27367) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering failed:  "Could not initialize the drawable configs" 
kwin(27367): Failed to initialize compositing, compositing disabled

I hope this doesn't interfere too much with the ability to track down the problem commit.

UPDATE: I just had to skip another due to a compile error.

(In reply to comment #34)
> Just FYI, I'm having to run "git bisect skip" on some of the commits (3 out
> of 5 so far) due to OpenGL rendering refusing to start up at all. Kwin's
> output for these commits:
> 
> kwin(27367) KWin::Compositor::slotCompositingOptionsInitialized:
> Initializing OpenGL compositing
> kwin(27367): Could not find a framebuffer configuration for depth 32. 
> kwin(27367) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering
> failed:  "Could not initialize the drawable configs" 
> kwin(27367): Failed to initialize compositing, compositing disabled

You found bug #317972 - if the problematic commit is somewhere in this range, this can be trivially fixed by patching in commit 5edf346ad8a19b6989fad7290e599824dd2414f2

I'll tell you how when this turns out a problem.

Perhaps you should show me how to do the patch. So far in the bisect, I've marked 2 good, 1 bad and 16 skips. At this rate, this process is not likely to end anytime soon.

Nevermind... I figured out how to do it myself. It's only a 1 line code change... not hard to manually edit glxbackend.cpp and then restore the original file before going on to the next bisect test. So, I started over, but I'm actually making progress now :)

(In reply to comment #37)
> Nevermind... I figured out how to do it myself.

Good to hear. Sorry for not replying - "night".
(And I'm no longer 20, so i've to sleep every now and then =)

Here you go:
--------------------------
48496454666715304e2d75c0bc396b57557c530e is the first bad commit
commit 48496454666715304e2d75c0bc396b57557c530e
Author: Fredrik Höglund <fredrik@kde.org>
Date:   Mon Mar 18 19:43:05 2013 +0100

    kwin: Clear the decoration textures after resizing
    
    This fixes artifacts from over-sampling along the edges of the
    decorations when effects such a wobbly windows are active.
    
    The textures are only cleared when framebuffer objects are supported.
    All drivers support FBO's now, so in practice this shouldn't be
    a problem.

:040000 040000 ec74d4a0f7309302422fab97e8dc6154d34c1f05 5366f354c6f50765f77dd38e34640bde66de8ccb M      kwin

I can also confirm that manually removing that commit from the 4.11 source fixes the bug.

(In reply to comment #40)
> I can also confirm that manually removing that commit from the 4.11 source
> fixes the bug.
I was about to ask that ;-)

Many thanks for your efforts!

Don't forget to reset your local changes and ultimately the bisect.

No a random (wild) guess: try injecting "glFinish();" directly after 
either:
  glClearColor(0, 0, 0, 0);
or:
  glClear(GL_COLOR_BUFFER_BIT);

(not both at once)

If either works, also try replacing it by "glFlush();" - if nothing works, try it at the end of the function

-------------
    }

    if (fbo_bound)
        glBindFramebuffer(GL_FRAMEBUFFER, 0);
    glFinish();
}
----------------------

(In reply to comment #41)
> No a random (wild) guess: try injecting "glFinish();" directly after...

None of those options worked, unfortunately.

Well hold on... something's amuck. I just did what I thought was a reverting of the patch again, and now it's not working. Something is either not getting compiled or updated properly... let me investigate.

Nevermind that last comment. When I copied the reverted paintdirector.* files back into the /build/kwin directory, the compiler didn't recognize them as having been updated, and skipped compiling / reinstalling kwin. This didn't affect the glFinish(); etc. tests you wanted me to run.

*** Bug 324338 has been marked as a duplicate of this bug. ***

Created attachment 82097 [details]
Preserve pot. previous FBO and yell a warning if we had it overridden

(In reply to comment #44)
> didn't affect the glFinish(); etc. tests you wanted me to run.

Ok, coming back to this: either the issue is introduced by clearing the framebuffer or by the clamp_to_edge call.

We should better rule out that this is due to the latter which you can just comment out

// m_textures[i]->setWrapMode(GL_CLAMP_TO_EDGE);

If that's not the case, i wonder whether we might override a currently bound framebuffer - see attached patch. (Does it yell a warning and/or fix the issue?)

(In reply to comment #46)
> We should better rule out that this is due to the latter which you can just
> comment out
> 
> // m_textures[i]->setWrapMode(GL_CLAMP_TO_EDGE);

This did not fix the issue.

> If that's not the case, i wonder whether we might override a currently bound
> framebuffer - see attached patch. (Does it yell a warning and/or fix the
> issue?)

This didn't fix the issue either, and your "OUCH!" warning doesn't show up in the debug output.

Try clearing the texture with glTexImage2D().

Hi,
I want to report that I have this problem as well (although I've only experienced the missing corner bug). 

Running up-to-date Arch Linux (kernel 3.10.10)
Catalyst 13.8 beta 2
KDE 4.11

(In reply to comment #48)
> Try clearing the texture with glTexImage2D().

Sorry, I don't really know C++ well enough to know how to do this. I tried replacing the line that begins:
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, ... (etc)

with this:
glTexImage2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, ... (etc)

But that line caused a compile error (too few arguments to function), so I'm going to wait for more specific instructions before mangling the code any further. Also, do you want me to make the change on top of your patched version or on top of the original code?

Created attachment 82147 [details]
clear the texture the legacy way

=)

Fredrik probably meant to say:
"Hey Thomas, get your ass up and write the kindly testing user a legacy fallback since our assumption that fbo is supported everywhere might not hold for stupid fglrx"  ;-)

The patch is for vanilla 4.11 - forget about the filename, re-used other file.

It forcefully uses a legacy way to clear the texture and in addition yells a warning if generating the framebuffer actually failed. (It will actually be many warnings in case, you want to try from konsole and when figured whether s_fbo exists remove the debug out:
        if (!s_fbo)
            qDebug() << "MEGAFAIL: no framebuffer object support!";
before continue to use the patch.

(In reply to comment #51)
> Fredrik probably meant to say: ...
Whoops... I didn't realize that was Fredrik and not you.

Anyway, this patch works! The window side borders are no longer missing, and the "MEGAFAIL" error never shows either.

I also added additional qDebug() output to verify the method that was being used to clear the textures, and I can confirm that the new code (after "else") is indeed being used on my system.

Created attachment 82163 [details]
slightly modified variant

(In reply to comment #52)
> Whoops... I didn't realize that was Fredrik and not you.
nevermind.
 
> Anyway, this patch works! [...]

Can you give the replacement a quick check as well?

(In reply to comment #53)
> I can confirm that the new code (after "else") is indeed being used on my system.
Yes, "if (false)" is a pretty safe way ;-)

Clearing the texture with glTexSubImage2D() might actually be faster than using glClear(),
because the glTexSubImage2D() call in updatePixmaps() will (should) stall on the GPU until the clear command has been executed.

Your latest patch throws the following compile errors:
paintredirector.cpp: In constructor ‘KWin::OpenGLPaintRedirector::OpenGLPaintRedirector(KWin::Client*, QWidget*)’:
paintredirector.cpp:326:10: error: ‘GLPlatform’ has not been declared
paintredirector.cpp:326:46: error: ‘Driver_Catalyst’ was not declared in this scope

(In reply to comment #56)
> Your latest patch throws the following compile errors:
> paintredirector.cpp: In constructor
> ‘KWin::OpenGLPaintRedirector::OpenGLPaintRedirector(KWin::Client*,
> QWidget*)’:
> paintredirector.cpp:326:10: error: ‘GLPlatform’ has not been declared
> paintredirector.cpp:326:46: error: ‘Driver_Catalyst’ was not declared in
> this scope

forgot to include a header, sorry.
i'll upload a compiling (and more optimized, given it might be preferred anyway) patch later this day.

Created attachment 82181 [details]
alternative approach, NOT USABLE AS FINAL PATCH

Please see updated patch here:
https://git.reviewboard.kde.org/r/112526/

Also, I attached a completely different test (but related) which you'd have to try WITHOUT applying the patch we know to resolve the issue (I'd just like the check whether this is related)

Many thanks for all your hard testing efforts.

(In reply to comment #58)
> Also, I attached a completely different test (but related) which you'd have
> to try WITHOUT applying the patch we know to resolve the issue (I'd just
> like the check whether this is related)

I'm not sure what to be testing for here. I don't see any difference with the left/right window border (still broken), if that's what you're looking for.

(In reply to comment #58)
> Many thanks for all your hard testing efforts.

My pleasure. I'm just glad I can contribute something, not being a programmer myself. I love the KDE project. Thank you for all the hard work you put into it!

(In reply to comment #59)

> I'm not sure what to be testing for here.
Whether it would fix anything.

> I don't see any difference with the left/right window border (still broken)
Ok, nevermind - was just a wild guess.

Thanks for ruling that out.

(In reply to comment #58)
> Please see updated patch here:
> https://git.reviewboard.kde.org/r/112526/

I can confirm that the updated patch works.

Created attachment 82245 [details]
kwin segfault opening Skype

I got this kwin segfault today when opening Skype (see attachment). It looks like it might be related to the latest changes (I'm using kwin compiled with your patch here: https://git.reviewboard.kde.org/r/112526/). I don't have the debug symbols installed, but I didn't know if I should try installing them alongside the custom-compiled kwin, so I didn't. Hopefully the output will give you enough information as-is.

(In reply to comment #63)

> like it might be related to the latest changes (I'm using kwin compiled with
> your patch here: https://git.reviewboard.kde.org/r/112526/)
Which version of it?
(It got major updates and the first version was .... errrr ... product of too much stress, coffee and no sleep - don't ask ;-)

Aah... it was an earlier version. I just now compiled with the latest version. I'll let you know if I run into any issues.

Will this patch include in any KDE 4.11.x ??

(In reply to comment #66)
> Will this patch include in any KDE 4.11.x ??

It currently points 4.11.2 but i'll wait and see whether Christian just found "Thomas was too tired to write sane C code" or there's another issue with fglrx & glTexSubImage2D() at this point.

Fr 27. Sep 01:59:00 CEST 2013    :  KDE SC 4.11.2 tagging

*** Bug 324755 has been marked as a duplicate of this bug. ***

(In reply to comment #67)
> It currently points 4.11.2 but i'll wait and see whether Christian just
> found "Thomas was too tired to write sane C code" or there's another issue
> with fglrx & glTexSubImage2D() at this point.

I've been using my laptop for a few hours today without any crashes. I'll have it running all day for the next two days as well while I teach lessons. I'll let you know if I run into any more problems, but I'm guessing the segfaults were a result of "Thomas was too tired to write sane C code" ;)

Just to confirm, no more crashes after two full days of use, so the latest patch indeed seems to be stable.

the effects dont work without using xrender. I use a silding panel and it is flat with no transparency effects and just appears and doesnt glide out. I am using the lastest beta catalyst

Also i spat my drink out when hearing the KDE devs probably dont use Catalyst ?! Not sure whether to laugh or cry here. The 3D performance dumps on the opensource (yes that is changing at a resonable pace) and the big pull for users is being able to play games and rich media using their AMD cards, the majority of people will be wanting the very best driver possible which is closed source and theres nothing wrong with that if it works good which it does!

thanks

(In reply to comment #71)
> the effects dont work without using xrender.
Likely bug #323527

> Also i spat my drink out when hearing the KDE devs probably dont use
> Catalyst ?!

Remember that in order to use fglrx, one needs to be willing to purchase the resp. HW in the first place.

Also not "KDE Devs" but "KWin Devs".
This means 3-4 ppl. with also a pretty good oversight on driver issues.

Now get another cup of coffee, boot your brain and think about it but personally i'm not avoiding fglrx for FLOSS concerns (eg. using the nvidia blob on 3 machines)

good to hear it

might not matter too much for gaming in a day or so if valve release their Linux Steam box will use whatever that requires and normal linux desktop for work and internet.

thanks

Git commit da78b49a3698a3a11ea1c68e3b5af3cecd5c00d5 by Thomas Lübking.
Committed on 05/09/2013 at 19:10.
Pushed by luebking into branch 'KDE/4.11'.

introduce GLTexture::clear and use it from paintredirector

also work around broken fbo texture clearing on fglrx

so far supports FBO/glClear and resorts to glTexSubImage2D

if the fbo cannot be created or is (in case of fglrx)
known to break, resort to glTexImage2D loading of an
argb array of zeros
FIXED-IN: 4.11.2
REVIEW: 112526

M  +49   -23   kwin/libkwineffects/kwingltexture.cpp
M  +5    -0    kwin/libkwineffects/kwingltexture.h
M  +3    -1    kwin/libkwineffects/kwingltexture_p.h
M  +2    -32   kwin/paintredirector.cpp
M  +0    -3    kwin/paintredirector.h

http://commits.kde.org/kde-workspace/da78b49a3698a3a11ea1c68e3b5af3cecd5c00d5

Seems to work fine now (KDE 4.11.2 and Catalyst 3.10-beta2), thanks. :-)