Version: 3.2.1 (using KDE Devel) Installed from: Compiled sources Compiler: gcc-3.3.3 OS: Linux After upgrade to Xfree86-4.4.0 and KDE-3.2.1 from Xfree86-4.3.0 and KDE-3.2.0 I have got troubles with mouse events in kwin. Focusing of window by clicking into it does not work. I used double click on window title to maximize/unmaximize: now unmaximize does not work. I used window lowering by right mouse button - now it does not work. My system: linux-2.4.25, glibc-2.3.2, Xfree86-4.4.0, kde-3.2.1, qt-3.3.1 (qt-3.3.0 also tried). I use optical Logitech mouse 2buttons+wheel mouse with config: Identifier "Mouse1" Driver "mouse" # Option "Protocol" "ExplorerPS/2" Option "Protocol" "Auto" Option "Device" "/dev/mouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" It seems other application works correctly with mouse under Xfree86-4.4.0, I use fwvm-2.5 instead of kwin in KDE.
I have similar problems in the very same situation: upgraded from KDE 3.2.0/XFree86 4.3 to KDE 3.2.1/XFree86 4.4 (in my case, using Slackware-current packages). The mouse problems are so bad, the resulting environment is so unusable for my family and even for me that I'm going back to XFree86 4.3 (and KDE 3.2.0 if need be). Here is an attempt at describing the main symptom. In a lot of cases, the mouse pointer enters move/resize mode: when left-clicking, it turns into a cross arrow (four arrows pointing in the cardinal direction) and the targeted window can be moved around, when right-clicking it turns into a resize arrow which depends on where relative to the target window the cursor is, and the window can be resized this way. In these (lots of) cases, the user click is not passed to the target window, and the window is not selected and/or brought forward as the user expects. When the problem occurs, it is not easy (and even hard, for unexperienced users) to find a way to cancel the more/resize mode and keep working. Here are some ways to suffer from this problem: * Have a tooltip. Works everytime: when a tooltip is displayed, you cannot pass a click to underlying windows, you have to dismiss the tooltip first. Considering that KDE is a tooltip-rich environment, and Mozilla generous with them too, this is a major source of pain. * Have a child window. Oftentimes, applications that bring up pop-up windows of some sort suffer from this problem. You have to dismiss the child before you can work again with the application. * This just in. I just alt-tabbed to an xterm, and this Mozilla window won't receive any click. Alt-tabbing back to Mozilla saves the day. * Be weird, be dead. Applications that have several, same-level windows (say, XMMS) are almost unusable: you have to alt-tab between the windows of the application. For example, once you click in the playlist, you cannot click on the play and stop buttons. * More to come. There very well may be other ways to reach this dreaded move/resize mode, of course. Some workarounds: * Alt-tab is your friend. * Escape is good too, especially when you've accidentally started moving or resizing a window. Don't release the click: press Escape, then release. This works for resizing windows, too, since they tend to go move-mode when you left-click on a border to resize the window. Here are some technical details. Since I'm not fond of immediately dumping all the contents of /proc and such, and since it seems to be somewhat a generic problem, I'm voluntarily short on details here. I will provide more info when requested. Platform: your basic old PC with well supported hardware, everything has been working fine under Linux for quite some time. Software: Slackware Linux, -current version (up to the 2004-03-26 update), with among others gcc 3.3.3 and glibc 2.3.2. User: experienced, advanced, whatever. Willing to help. Since I am reverting to XFree86 4.3 *now*, I will not be able to test much, unless such a big pile of questions, proposed workarounds or tentative solutions comes up that it is worthwhile to temporarily switch to 4.4, test, and revert. I may be installing XFree86 4.4 and KDE 3.2.1 on another, less critical machine, but this may take several days.
I think I found the root cause of the problem. Discussion with other people with almost identical hardware and software configurations, people which had no such problem with the mouse, led me to believe this was a configuration problem. I looked around, tweaked some settings on an existing account and on a brand-new account, and found the following. The mouse behaves normally under KDE 3.2.1 and XFree86 4.4.0, with default settings. Things break as described above when one changes the settings of the Window Behavior (under Desktop in the KDE Control Center). Specifically, in the Actions tab, when switching the Modifier key for "Inner Window, Titlebar & Frame" from the default of Alt to the excellent (but now broken) Meta. It seems that something changed in XFree86 4.4.0 so that KDE believes the Meta key is always activated when the user clicks on a window that is not the topmost window. Andrey V. Panov, can you confirm my findings?
I confirm last message, the problem arises when Meta is used as Modifier key instead of Alt.
It seems that kwin does not recognize "Left Win" key, pressing on it calls K-menu. I use "pc105" keyboard.
Please provide output of 'xmodmap'. Does the problem depend on whether you have NumLock turned on or off? Also, try if the attached patch for /etc/X11/xkb helps (X needs to be restarted).
Created attachment 5740 [details] /etc/X11/xkb patch
Here is the output of xmodmap: adrien@darkstar$ xmodmap xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) The problem does not depend on the state of NumLock. The attached patch does indeed solve the problem. I'm curious: does it revert some change made between XFree86 4.3 and 4.4, or do you actually master xkb? ;)
I can confirm the patch fixes this bug.
I also confirm that the patch fixes this bug. Should this bug be addressed to XFree86?
No, I don't master xkb, I wonder if anybody does. The patch is from our SUSE X11 people (so I guess they'll report it themselves), and it fixes mapping of the fourth modifier key to actually work. Still KWin should handle more gracefully the case when the modifier is not configured properly.
Should be fixed.
*** Bug 81682 has been marked as a duplicate of this bug. ***
*** Bug 82912 has been marked as a duplicate of this bug. ***
I checked the page for bug 78467, and downloaded the patch. It appears the patch is supposed to be applied to a file, /etc/X11/xkb On my system, this is a directory, whose contents are: compat geometry.dir keymap.dir rules types compat.dir keycodes README semantics types.dir compiled keycodes.dir README.config symbols xkbcomp geometry keymap README.enhancing symbols.dir Which of these files would this patch apply to, if any?
cd /etc/X11/xkb patch -p0 < xkb.patch
For those who don't have superuser privileges on my workstation and cannot change /etc/X11/xkb directory, there a solution involving 'xmodmap'. You need to do the following: xmodmap -e "clear mod4" xmodmap -e "keycode 127 = " xmodmap -e "keycode 128 = " xmodmap -e "keycode 115 = Super_L" xmodmap -e "keycode 116 = Super_R" xmodmap -e "add mod4 = Super_L Super_R"
Or, put the following in the ~/.Xmodmap: keycode 115 = Super_L keycode 116 = Super_R keycode 127 = keycode 128 = clear Mod4 add Mod4 = Super_L Super_R