Version: (using KDE 4.4.0) OS: Linux Installed from: Mandriva RPMs when i reboot, i have automatic login in kde4 for my user. the kde session opens correctly, plasma is running and works, but clicking on the window title, or other decorations (such as tabs in other apps, or checkboxes, etc) is ignored - even in non kde apps such as firefox. for example, i can click on logout plasma widget, but then cannot click on the "logout" button that appears. i am forced to kill session with alt+sysrq+k to kill all processes from current tty. then i'm back at kdm, so i enter my login / password, log in again, and this time everything is working fine. i tried to remove autologin (ie, log in manually with login / password just after boot) but got the same problem. i tried to kill plasma and restart it, but that does not solve the problem. i tried to kill kwin and restart it, but that does not solve the problem. using alt+tab works, so it does not seem to be related to windows switching. no windows effects enabled (thus no compositing). bug originally reported on mandriva bugtracking: https://qa.mandriva.com/show_bug.cgi?id=52231 neoclust asked me to report it upstream.
Which window decoration are you using ? Did you try with others ?
i tried the following themes: - iaora-qt & iaora-kde (mandriva specific theme) - oxygen (which i'm using now) the problem was always present, whatever the theme.
note also that i tried removing my ~/.kde4, bug was still present.
to sum up: you boot your computer, login via kdm and cannot activate windows by clicking them (neither on the titlebar, nor into the window) then you kill X and all GUI procs (tried zapping? i.e. ctrl+alt+backspace), kdm reshows and from now on you can log in and out and everything works fine. so much correct? can you use the mouse in kdm before the first login? how do you usually open windows? (e.g. clicking icons on the desktop, using the plasma launcher or lancelot, from a terminal like konsole) can you "alt + f2", "xterm" and activate the upcoming window and type into that terminal?
thomas: correct. i did not try zapping since it's not enabled. i can use the mouse in kdm before login. i'm usually opening windows with alt+f2. however, the previous session is restored, so my windows are already there when logging in. i'll try to reboot to do your xterm test.
so i can alt+f2, xterm. the xterm window opens and gets the focus. i can type in it. i do have a video if you want (warning: 7.2 mb).
err... sorry, i meant like "activate it by clickig it with the mouse" (right after the first start - i wanted to know whether the mouse might get grabbed when you e.g. press the menu button in a panel or so) As you usually start apps this way anyway and apparently also have restored apps and (due to the ~/.kde4 removal) w/o restored apps, that's probably not the case ...
no, i cannot click the xterm window with the mouse if it doesn't have the focus. neither in the xterm, nor in the title bar.
I encounter the same problem. It started I think 3 days ago. Before this I have used the login for a long time, since kde-4.1.0 I think. I'm not aware of making any modifications to the KDE window manager theme, etc (not necessary is the setup is just fine). This is openSUSE_11.2 kde4.3.5 I use <alt><F1> to open the menu and the arrow buttons to move the logout button. When that is reached the logout window pops up. I've to wait on the time out (30 secs) as I'm not able to use the buttons on the logout window (I can't get it activated). I have to login manually (autologin disabled). Other users on the system, do not have this problem. I saved a list of files in the ~/.kde4 that changed recently. I needed I can provide it.
humm, can you pass the focus to another window (using alt+tab, look at the titlebar or the shadows) and use the mouse there? in case you use compositing, are the windows still there if you suspend it (alt+shift+f12)? offending setings might be related to either kwin or plasma. before you login (for the first time after boot) please try to move (eg. from VT1, ctrl+alt+f1) ~/.kde4/share/config/kwinrc and ~/.kde4/share/config/plasma-desktoprc out of the way (i.e. rename them to *.bak, don't delete them), then login and see whether the problem remains (we need a tool to figure the mouse grabbing process :)
Hello Thomas, I spent a lot of time this morning to try to pinpoint the problem. I started off with investigating your questions. But it does not seem to be user specific! The problem exist for the user that logs in first to the system. That first user has the problem. After logging out and logging into the same or another login the problem does not exist! It looks to me a problem of kdm or Xorg. When comparing the PID of kdm and Xorg after logging out and logging in again, the only one that differs is one of Xorg. I therefor restart Xorg before an initial logging, but this not help (behaviour is a litlle different). One still has to log out and log in again. To answer your question: - <alt><tab> works as expected - disabling compositing does not help - (re)moving kwinrc and plasma-desktoprc does not help Those rpms: kwin-4.3.5-0.3.1 do 15 apr 2010 09:33:31 CEST kdm-4.3.5-0.3.1 do 15 apr 2010 09:33:26 CEST kdebase4-workspace-4.3.5-0.3.1 do 15 apr 2010 09:33:18 CEST kde4-kgreeter-plugins-4.3.5-0.3.1 do 15 apr 2010 09:32:19 CEST kdebase4-workspace-ksysguardd-4.3.5-0.3.1 do 15 apr 2010 09:32:17 CEST have been updated recently. It looks like the problem is therefor introduced by one of those rpms....
Sorry for the long delay. There was an issue with custom plasma containers which were invalidly treated as desktop but actually tagged as dock, thus got upmost in the stack. This issue should have meanwhile be resolved, therefore: do you still experience this bug? Also see bug #259704 and feel free to scan bugzilla for some more ;-)
I don't have this problem anymore
Many thanks for the update.