Bug 624208 - [F14 REGRESSION] KDE desktop effects with OpenGL: no display updates
[F14 REGRESSION] KDE desktop effects with OpenGL: no display updates
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
RejectedBlocker, [cat:modesetting]
: Regression, Triaged
: 643726 (view as bug list)
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2010-08-14 08:42 EDT by Stefan Becker
Modified: 2011-05-16 05:26 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-16 05:26:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
X server log file (74.52 KB, text/plain)
2010-09-09 13:36 EDT, Stefan Becker
no flags Details
dmesg log file (79.79 KB, text/plain)
2010-09-09 13:36 EDT, Stefan Becker
no flags Details
/var/log/messages (151.62 KB, text/plain)
2010-09-09 13:37 EDT, Stefan Becker
no flags Details
.xsession-errors (33.46 KB, text/plain)
2010-09-09 13:41 EDT, Stefan Becker
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 227435 None None None Never

  None (edit)
Description Stefan Becker 2010-08-14 08:42:16 EDT
Description of problem:

I preupgraded a Lenovo T60 from F13 to F14. I'm using OpenGL for KDE desktop effects and after the upgrade the KDE login stopped updating the display toward the end of the splash screen. X, kwin or the KDE session are not hanging, i.e. my session started up completely, but I can't see anything. Pressing CTRL-ALT-DEL and waiting for 30 seconds shut down the KDE session without any hitch.

Desktop effects still work if I switch to XRender. Switching back to OpenGL while the session is running freezes display update again.

Version-Release number of selected component (if applicable):
kdebase-workspace-4.5.0-2.fc14.i686
kernel-2.6.35-3.fc14.i686
libdrm-2.4.21-3.fc14.i686
mesa-libGL-7.9-0.6.fc14.i686
xorg-x11-drv-ati-6.13.1-0.2.20100705git37b348059.fc14.i686
xorg-x11-server-Xorg-1.8.99.906-1.fc14.i686

How reproducible: always

Additional info:

Linux l3f1199 2.6.35-3.fc14.i686 #1 SMP Fri Aug 6 19:48:09 UTC 2010 i686 i686 i386 GNU/Linux

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M52 [Mobility Radeon X1300] [1002:7149]

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV515
OpenGL version string: 2.1 Mesa 7.9-devel

Hmm, could be related to the switch to Gallium driver for OpenGL?
Comment 1 Stefan Becker 2010-08-14 08:59:46 EDT
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?
Comment 2 Kevin Kofler 2010-08-14 12:10:38 EDT
> 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.
Comment 3 Rex Dieter 2010-08-14 17:52:25 EDT
by all accounts, looks like a driver issue (wrt opengl support), reassigning.
Comment 4 Stefan Becker 2010-08-15 01:20:08 EDT
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.
Comment 5 Stefan Becker 2010-08-15 04:20:06 EDT
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.
Comment 6 Kevin Kofler 2010-08-15 11:44:27 EDT
If it's really a video driver issue, it's not a KDE 4.5 blocker.
Comment 7 Stefan Becker 2010-08-25 08:59:01 EDT
You are correct Kevin, but it is IMHO a F14 blocker.

Retested with a fresh F13 -> F14 preupgrade: problem still exists.
Comment 8 Adam Williamson 2010-08-27 12:51:04 EDT
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
Comment 9 Stefan Becker 2010-08-27 14:22:13 EDT
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
Comment 10 Rex Dieter 2010-08-27 14:36:09 EDT
I believe kwin does have the ability to blacklist individual drivers.
Comment 11 Adam Williamson 2010-08-27 14:46:28 EDT
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
Comment 12 Rex Dieter 2010-08-27 15:08:59 EDT
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.
Comment 13 Stefan Becker 2010-08-27 15:17:51 EDT
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.
Comment 14 Stefan Becker 2010-08-27 15:22:02 EDT
I checked the F14 feature list: there is nothing on there mentioning mesa, ati, gallium or r300 driver.
Comment 15 Hicham HAOUARI 2010-09-06 17:30:11 EDT
The display "freezes" here randomly, until I minimize/maximize the window, with compiz enabled. If compiz is disabled this problem doesn't show up.
Comment 16 Stefan Becker 2010-09-07 11:29:48 EDT
(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.
Comment 17 Matěj Cepl 2010-09-07 13:16:33 EDT
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.
Comment 18 Stefan Becker 2010-09-09 13:36:00 EDT
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.
Comment 19 Stefan Becker 2010-09-09 13:36:33 EDT
Created attachment 446315 [details]
dmesg log file
Comment 20 Stefan Becker 2010-09-09 13:37:02 EDT
Created attachment 446316 [details]
/var/log/messages
Comment 21 Stefan Becker 2010-09-09 13:41:43 EDT
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.
Comment 22 Rex Dieter 2010-09-09 13:45:58 EDT
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
Comment 23 Stefan Becker 2010-09-09 14:43:11 EDT
(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...
Comment 24 Rex Dieter 2010-09-09 14:46:11 EDT
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?
Comment 25 Stefan Becker 2010-09-09 15:03:08 EDT
(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...
Comment 27 Kevin Kofler 2010-09-12 11:16:12 EDT
*** Bug 633026 has been marked as a duplicate of this bug. ***
Comment 28 Liang Suilong 2010-09-12 12:42:19 EDT
(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.
Comment 29 Kevin Kofler 2010-09-12 12:54:49 EDT
Oh, so it's not the same bug, I'll reopen yours.
Comment 30 Rex Dieter 2010-10-03 13:20:58 EDT
dropping from kde-4.5 blocker, considering it f14-specific.
Comment 31 Hicham HAOUARI 2010-10-03 13:24:58 EDT
I can't
Comment 32 Hicham HAOUARI 2010-10-03 14:13:58 EDT
Sorry for the previous comment. I was gonna say : I can't reproduce the bug anymore.
Comment 33 Matěj Cepl 2010-10-04 09:05:45 EDT
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
Comment 34 Stefan Becker 2010-10-04 11:27:45 EDT
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)
Comment 35 Ian Pilcher 2010-10-14 18:58:50 EDT
Just ran into this with my ATI X1650 Pro.  Definitely a *BIG* regression from Fedora 13.
Comment 36 Mattia Verga 2010-10-26 14:07:59 EDT
I think bug #643726 can be a duplicate of this.
Comment 37 Matěj Cepl 2010-10-26 19:29:26 EDT
*** Bug 643726 has been marked as a duplicate of this bug. ***
Comment 38 Baif 2010-11-17 10:27:55 EST
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
Comment 39 Baif 2010-11-18 07:53:21 EST
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."
Comment 40 Mattia Verga 2010-11-18 11:30:04 EST
(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).
Comment 41 Stefan Becker 2010-11-18 14:02:05 EST
(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.
Comment 42 Baif 2010-11-19 04:13:34 EST
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."...
Comment 43 Stefan Becker 2011-05-15 03:12:21 EDT
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.
Comment 44 Matěj Cepl 2011-05-16 05:26:32 EDT
Thank you for letting us know.

Note You need to log in before you can comment on or make changes to this bug.