Bug 624208

Under F13 glxinfo shows:

OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV515 7149) 20090101  TCL DRI2
OpenGL version string: 1.5 Mesa 7.8.1

So this could be caused by mesa, as I know from my nouveau systems that kwin OpenGL Desktop Effects don't work there either.

I guess I would need to install KDE 4.5 test packages for F13 to confirm?

> I guess I would need to install KDE 4.5 test packages for F13 to confirm?

Yes, that's the best way to know what package is the culprit.

by all accounts, looks like a driver issue (wrt opengl support), reassigning.

This belongs to mesa: Gallium R300 driver enabled in 7.9-0.2:

  <http://koji.fedoraproject.org/koji/buildinfo?buildID=177855>

IMHO this decision should be reconsidered if it breaks the F14 upgrade for KDE users with r3xx-r5xx HW.

Is it possible to compile old R300 and new R300G driver? Then one option would be to move R300G to mesa-dri-drivers-experimental package.

If it's really a video driver issue, it's not a KDE 4.5 blocker.

You are correct Kevin, but it is IMHO a F14 blocker.

Retested with a fresh F13 -> F14 preupgrade: problem still exists.

Discussed at today's blocker review meeting. Adding Dave and Jerome to CC. Stefan, can you elaborate a little more on how you expect people would hit this bug? If you simply install F13 with default KDE configuration and then upgrade to F14, do you hit it? If it requires manual configuration at any point to actually have the affected desktop effects setup, then this doesn't really qualify as a blocker.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

OK, I checked with KDE 4.5 on F14 with a new user account: by default KDE *does not* enable composition (AKA Desktop Effects). The KDE SIG can probably confirm this.

But consider these cases for KDE users on r3xx-r5xx HW:

 - F13 -> F14 update case:
   * user has enabled "Desktop Effects" at some point
   * user upgrades to F14
   * user logs in
   -> login process "freezes"

 - F14 new install case: (just tested this one myself)
   * new account is created
   * on the login screen user selects the new account and KDE as default session
   * user selects "System Settings" from KDE menu
   * user selects "Desktop Effects"
   * VARIANT A: user selects "Enable desktop effects" tick mark
   * VARIANT B: user selects "Default" button
   * user selects "OK" button and accepts the new configuration
   -> desktop freezes

Do you think these are desirable behaviours? I certainly don't.

I see three solutions:

  - revert the decision to ship R300G instead of R300.

  - IF POSSIBLE: provide R300 in mesa-dri-drivers and R300G in mesa-dri-drivers-experimental, with a caveat in the Release Note

  - IF POSSIBLE: add R300G to kwin OpenGL blacklist

I believe kwin does have the ability to blacklist individual drivers.

Desirable? No. But they're not release blockers, according to our criteria, and also long-established practice (we have never considered issues with optional desktop bling to be release blocking).

It would be nice for this to be handled in some way, though. I don't know why you immediately leap to workarounds like shipping another driver or blacklisting this driver - why wouldn't we just fix the bug in the driver?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I believe kwin has the ability to blacklist effects for known bad drivers/revisions.  If this continues to be bad in certain cases, we can work to implement that here.

After I started using a 30" 2560x1600 monitor at work, I no longer consider "Composite" as simple "bling". On big screens X is sloooooooowwwww without a compositing window manager.


Please correct me if I'm wrong, but I think Gallium isn't ready for prime time yet. It probably works for compiz, but in my experience that is less demanding than kwin composition.

In case of nouveau you of course have no choice. But those Gallium drivers are missing some features, i.e. kwin automatically rejects OpenGL desktop effects due to OpenGL errors and users don't run into the problem.


Can somebody comment on why the working "old" R300 driver was replaced with the new Gallium R300G driver for F14?


If you think the R300G driver bug (more likely: bugs) can be fixed in time before the F14 release, then please tell me how I can help with some debug output.

I checked the F14 feature list: there is nothing on there mentioning mesa, ati, gallium or r300 driver.

The display "freezes" here randomly, until I minimize/maximize the window, with compiz enabled. If compiz is disabled this problem doesn't show up.

(In reply to comment #15)
> The display "freezes" here randomly, until I minimize/maximize the window, with
> compiz enabled. If compiz is disabled this problem doesn't show up.

So compiz is affected too? Interesting.

No chance in kwin4 though. When you switch desktop effects from XRender/Off to OpenGL inside the KDE session then you can only move the mouse pointer. The windows don't react at all anymore, ie. you couldn't even try this minimize/maximize workaround.

OK, thanks for the good analysis, but I would need more data here. We still don't what's actually wrong with Gallium.

Please add drm.debug=0x04 to the kernel command line, restart computer, and when the problem happens, somehow dig up the following logs (can you switch to console or even ssh to the computer? that could probably help) and add them to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

* 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)

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 446314 [details]
X server log file

I did the following:

  - modified .kde/share/config/kwinrc XRender -> OpenGL
  - rebooted machine with drm.debug=0x04
  - logged into my KDE session (display "freezes" during splash screen)
  - waited for the KDE logon tune
  - switched to console to grab the log files (i.e. keyboard still works)

I'll also attach .xsession-errors as it shows messages from kwin.

Created attachment 446315 [details]
dmesg log file

Created attachment 446316 [details]
/var/log/messages

Created attachment 446319 [details]
.xsession-errors

There is an interesting tidbit in this log file:

kwin(1452) KWin::EffectsHandlerImpl::loadEffect: Trying to load  "kwin4_effect_minimizeanimation"
kwin(1452) KWin::Workspace::updateClientArea: screens:  1 desktops:  4
kwin(1452) KWin::Workspace::updateClientArea: Done.

kwin(1452): OpenGL compositing self-check failed, disabling compositing. 

kwin(1452) KWin::EffectsHandlerImpl::unloadEffect: EffectsHandler::unloadEffect : Unloading Effect :  "kwin4_effect_zoom"

So kwin OpenGL checks *do* fail with R300 Gallium drivers and it disables composition. But it seems that this does not really work, i.e. kwin no longer updates the display. I have seen similar problems when trying to change KDE Desktop Effect settings, i.e. after pressing "OK" the only thing that works on the screen is the mouse.

what you're seeing is opengl being disabled, and xrender being used instead (I think).

Anyway, another complication here is that kwin tries to use direct gl if support is claimed by the driver.  To see if that's it, set
LIBGL_ALWAYS_INDIRECT=1
in your environment.

One way to do that is,
cat > ~/.kde/env/LIBGL_ALWAYS_INDIRECT.sh << EOF
# workaround http://bugs.kde.org/show_bug.cgi?id=241402
LIBGL_ALWAYS_INDIRECT=1
export LIBGL_ALWAYS_INDIRECT
EOF

and logout/login

(In reply to comment #22)
> Anyway, another complication here is that kwin tries to use direct gl if
> support is claimed by the driver.  To see if that's it, set
> LIBGL_ALWAYS_INDIRECT=1
> in your environment.

Yep, that's it. Now OpenGL works like a charm again...

OK, please do confirm that xrender continues to hang/regress however, 

systemsettings->desktop effects->(advanced tab)
Compositing Type: Xrender

does that work, or fail/hang as before?

(In reply to comment #24)
> OK, please do confirm that xrender continues to hang/regress however, 

XRender works fine too now, i.e. I can switch back-and-forth between OpenGL and XRender, and I can change Desktop Effects settings while XRender is active.

Strange that a broken OpenGL can affect XRender...

OK, odd.  Probably a subtle variant of bug #625894 then, see also,

http://bugs.kde.org/show_bug.cgi?id=241402
http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/

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

(In reply to comment #27)
> *** Bug 633026 has been marked as a duplicate of this bug. ***

As you say in https://bugzilla.redhat.com/show_bug.cgi?id=633026 , legacy radeon chips needs r300g driver. But Mine is HD3600, working with r600. Unlike r300g, R600g Gallium-based driver is not avaible now.

Oh, so it's not the same bug, I'll reopen yours.

dropping from kde-4.5 blocker, considering it f14-specific.

I can't

Sorry for the previous comment. I was gonna say : I can't reproduce the bug anymore.

Reporter, do you agree with the comment 32? Are you able to reproduce this bug in the latest updates of Fedora 14, please?

Thank you for your help

Retested with:

kdebase-workspace-4.5.1-3.fc14.i686
kernel-2.6.35.4-28.fc14.i686
libdrm-2.4.21-3.fc14.i686
mesa-libGL-7.9-0.8.fc14.i686
xorg-x11-drv-ati-6.13.1-0.3.20100705git37b348059.fc14.i686
xorg-x11-server-Xorg-1.9.0-9.fc14.i686

Q: Is the *originally* reported regression fixed?
A: Yes, an user with this type of graphics HW who uses KDE OpenGL desktop effects on F13, will no longer end up with a hang in the KDE splash screen after updating to F14.


Q: Is the problem *REALLY* fixed in the eyes of the end user?
A: NO, because KDE simply disables desktop effects temporarily at startup. I.e. although the settings (.kde/share/config/.kwinrc) say "desktop effects using OpenGL and effects X, Y, ...." the end user will end up with a desktop that has no desktop effects enabled (not even using XRender!).

To get working KDE desktop effects the user has two options:

 a) temporary: he enables the desktop effects every time he starts a KDE session. Enabling them *AFTER* the login does seem to work, so it makes you wonder why KDE thinks it has to disable them temporarily???

 b) permanent: he sets LIBGL_ALWAYS_INDIRECT=1 in .kde/env (see comment #22)

Just ran into this with my ATI X1650 Pro.  Definitely a *BIG* regression from Fedora 13.

I think bug #643726 can be a duplicate of this.

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

GOD!!!!  I wish I had read this BUG 2 hours ago...

A very old laptop with ATI Radeon XPRESS 200M, it works like a jet with F13...

Now it doesn't work quit well with F14, 50 Fps with glxgears, and no KDE Desktop Effects at all.

# glxinfo  | egrep -i opengl
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RS480
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20
OpenGL extensions:

# uname
 2.6.35.6-48.fc14.i686

# rpm -qi kdebase

Name        : kdebase                      Relocations: (not relocatable)
Version     : 4.5.2                             Vendor: Fedora Project

This should be a bug of MESA, or the new thing "Gallium", my old laptop with
ATI Radeon XPRESS 200M, it works like a jet with F13... OPENGL works so good
with X200M in F13... 

This should not be confused with KDE. Did anyone who runs into this kind of problem test your display adapter with glxgears/ glxinfo?

I cann't agree with Ian any more, it is "Definitely a *BIG* regression from
Fedora 13."

(In reply to comment #39)
> This should be a bug of MESA, or the new thing "Gallium", my old laptop with
> ATI Radeon XPRESS 200M, it works like a jet with F13... OPENGL works so good
> with X200M in F13... 
> 
I'm not using Gallium (I use an Ati Radeon HD4850) and guys of bug #643726 don't use an ATI card at all (they use Intel).

(In reply to comment #39)
> This should be a bug of MESA, or the new thing "Gallium", my old laptop with
> ATI Radeon XPRESS 200M, it works like a jet with F13... OPENGL works so good
> with X200M in F13... 

Gallium is Mesa, it is the new framework for 3D drivers. The problem is not really OpenGL, because it *does* work.

> This should not be confused with KDE. Did anyone who runs into this kind of
> problem test your display adapter with glxgears/ glxinfo?

The problem is KDE 4.5.2+ trust in what the OpenGL driver says it can do but actually can't. See the links in comment #26 for an explanation.

Have you tried the workaround from comment #22? With that I have now KDE desktop effects with OpenGL working on 1 radeon and 2 nouveau systems.

Thanks for both Mattia #40, Stefan Becker #41.

It seems that for me, the problem is 3D/OPENGL doesn't work like it works on F13 with my laptop, as I mentioned earlier glxgears reports 400~500 FPs, but it runs 40~50 FPs on F14.

I'll report my issue as a new BUG. But still  it is "Definitely a *BIG* regression from Fedora 13."...

This doesn't seem to be an issue anymore with F15Beta. I stopped using the LIBGL_ALWAYS_INDIRECT=1 on the two systems that are upgrade to F15Beta.

I suggest to close this one.

Thank you for letting us know.