This problem occurs on two identical machines with the same configuration and has been recurring for at least the last month. After boot or reboot desktop effects are disabled. Alt-shift-F12 is ineffectual. After logout and login desktop effects are enabled and the Alt_Shift_F12 sequence is operable in disabling or restoring composite effects. Composite Type: OpenGL I am using the Akmod Catalyst drivers. lspci|grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc Device 675d This problem has persisted through at least the last five kernel updates (I have been too busy to deal with it prior to this). /etc/xorg.conf : Section "Device" BusID "PCI:1:0:0" Identifier "Videocard0" Driver "fglrx" EndSection This in kdm.log: X.Org X Server 1.12.3 Release Date: 2012-07-09 X Protocol Version 11, Revision 0 Build Operating System: 2.6.32-220.17.1.el6.x86_64 Current Operating System: Linux dragon 3.6.1-1.fc17.x86_64 #1 SMP Wed Oct 10 12:13:05 UTC 2012 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.6.1-1.fc17.x86_64 root=/dev/mapper/vg_hanji 1-lv_root ro rd.md=0 rd.dm=0 KEYTABLE=us quiet rd.lvm.lv=vg_hanji1/lv_swap rhgb rd.luk s=0 rd.lvm.lv=vg_hanji1/lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 radeon.mode set=0 Build Date: 20 September 2012 07:51:23AM Build ID: xorg-x11-server 1.12.3-2.fc17 Current version of pixman: 0.24.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 14 14:08:50 2012 (==) Using config file: "/etc/X11/xorg.conf" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (WW) fglrx: No matching Device section for instance (BusID PCI:0@1:0:1) found klauncher(1077) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. kdeinit4: Communication error with launcher. Exiting! kdmgreet(1071)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: "Not connected to D-Bus server" kdmgreet(1071)/kdecore (K*TimeZone*): No time zone information obtained from ktimezone d Reproducible: Always Steps to Reproduce: 1. Boot or reboot 2. login to KDE 3. Desktop effects are disabled and alt-shift-F12 inoperable 4. logout 5. login 6. Desktop effects are enable and alt-shift-F12 is operable in disabling or enabling Desktop Effects Actual Results: Desktop effects are disabled after boot and can only be enabled by logging out and logging in to KDE. Expected Results: Desktop compositing effects should be enabled after boot and login as they were before recent updates.
when compositing is inavailable, is kwin running at all (do windows have a titlebar, can you move them around, pass the focus by clicking into them, alt+tab navigate through them, etc.)
Yes - Kwin is running as are titlebars and normal navigation. 3D effects, shadows, transparency etc effects etc are not enabled.
- does just restarting "kwin --replace &" "fix" it - can you log into a failsafe session (just X11 + xterm) after the re/boot and there attempt to launch "glxgears"?
@Thomas I appear to have resolved this. Not sure how - but here is what I did. 1. I renamed /etc/kde/kdm/kdmrc to kdmrc_hold (as root). 2. Rebooted and logged into KDE 3. Of course, this gives a minimal desktop 4. Opened up a terminal window and renamed kdmrc_hold back to kdmrc 5. Rebooted. 6. Desktop effects are enabled on straight boot and login. Tried it repeatedly - no change. My guess is that booting without a kdmrc and then rebooting with it caused KDE to rewrite the settings in its local home directory config files and this removed an outmoded script or line. Just guessing. I will wait a day or two to see if the problem recurs before marking this as solved. Thanks for your help and input.
Spoke too soon - kde effects are not working again. Here is the output from: kwin --replace & [1] 2431 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: AMD Radeon HD 7500 Series OpenGL version string: 2.1 (4.2.11762 Compatibility Profile Context) Driver: Catalyst Driver version: 2.1 GPU class: Unknown OpenGL version: 2.1 Linux kernel version: 3.6.1 Direct rendering: no Requires strict binding: yes GLSL shaders: no Texture NPOT support: yes NO VSYNC! glXGetVideoSync, glXSwapInterval, glXIsDirect false true 0 kwin(2431): Shaders are not supported ^C
running glxgears in a kde failsafe session brings up the graphic with the following output in the terminal: glxgears 301 frames in 5.0 seconds = 60.087 FPS 300 frames in 5.0 seconds = 59.945 FPS 300 frames in 5.0 seconds = 59.986 FPS 300 frames in 5.0 seconds = 59.997 FPS 301 frames in 5.0 seconds = 60.001 FPS 300 frames in 5.0 seconds = 59.999 FPS
not a kde failsafe session, it must be a naked x11 server, w/o desktop environment or WM and esp. anything linking libGL (ie. also Qt) - you can have a running xterm or launch glxgears from vt1
@Thomas - Loading basic X11 and running glxgears from vt terminal produces a similar result as above. The animation opens in a corner window and the frames per second reading is more or less the same (could not paste from the vt terminal).
Ok, doesn't sound like the GPU is somehow not inited on first invocation. -> Does it work to start KDE with disfuntional compositing and then to later on simply run "kwin --replace&" (restarting the WM, this could point that the GPU is not initialized time driven, the driver may require some setup during the session start and KWin starts very early)
I have to apologize for misreporting here - there is something either I did not notice before or things have changed since i first filed this. I have been so busy looking at the panel that I failed to notice that desktop effects for windows were enabled/disabled by both kwin --replace& and the alt-shif-F12 sequence. The problem is that neither of these restores the panel and taskbar to its normal plasma transparency. Only logging out and in again (not rebooting) restores this. The panel has a dark bronze background. New panels have a grey non-transparent background.
falls into categories of bug #179042 then, could also have relation to creating the session bus. marking as dupe for now, please monitor https://git.reviewboard.kde.org/r/106844/ as well and what's the setting of "enable compositor on start" setting in the first tab of "kcmshell4 kwincompositing"? *** This bug has been marked as a duplicate of bug 179042 ***
> and what's the setting of "enable compositor on start" setting in the first tab of "kcmshell4 kwincompositing"? It is enabled
Any guess why logging out and in again restores the transparency of the panel (rather than a reboot - which invariably does not)? It would seem that some scripts are not loading on a straight boot and login to kde but they are on logging out and then in again\?
(In reply to comment #13) > Any guess why logging out and in again restores the transparency of the > panel (rather than a reboot - which invariably does not)? Plasma-desktop doesn't notice that a compositor is running, because a) it does not (eg. kwin crashes eg. for a GL error in the cold system, then restarts) b) the selectionowner has not been updated (plasma-desktop starts up too early, doesn't wait for the server to be synced) That's hard to say being absent from the system, you'd have to try on the plasma-desktop sources (log debug infor about the system when it checks for the compositing state, like whether there's already a kwin process, whether bypassing the KWindowSystem routine and asking XGetSelectionOwner( QX11Info::display(), net_wm_cm ); directly works, whether injecting an XSync(False) helps etc.
Thanks, Thomas.
Latest Kernel update x3.7.3-101.fc17.x86_64 does not update akmod-catalyst package and therefore the appropriate kmod-catalyst package is not updated thus causing desktop effects with opengl to be disabled. The solution is to manually update the kmod-catalyst package for the recent kernel. No akmod-catalyst package is yet available for the recent kernel update. An oversight?
sorry we are not responsible for kernel updates or driver updates.