| Summary: | cannot click on window decorations in first login in kde after reboot | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Jerome Quelin <jquelin> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | hugo.pereira.da.costa, kde, richard.bos |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Mandriva RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jerome Quelin
2010-02-09 19:23:11 UTC
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. |