Good, I will push it to git.

It seems to be OK. Tested at two machines with Arch Linux.

I prefer to add the masking to stripStateModifiers(), but thanks again for finding the fix, Idares.

Please test the attached patch for any regressions.

Only by tracing output from xev.

Thank you for handing in a patch. May ask where you find out about KbdLayoutMask{1,2}?

I made a patch that should fix this. Tested on Arch Linux, X.Org X Server 1.6.3

diff --git a/src/ActionHandler.cc b/src/ActionHandler.cc
index 10cea3c..d044bd1 100644
--- a/src/ActionHandler.cc
+++ b/src/ActionHandler.cc
@@ -520,6 +520,7 @@ ActionHandler::findMouseAction(uint button, uint state, MouseEventType type, std
 
     state &= ~PScreen::instance()->getNumLock() & ~PScreen::instance()->getScrollLock() & ~LockMask;
     state &= ~Button1Mask & ~Button2Mask & ~Button3Mask & ~Button4Mask & ~Button5Mask;
+    state = PScreen::instance()->stripKbdLayoutModifiers(state);
 
     list<ActionEvent>::iterator it(actions->begin());
     for (; it != actions->end(); ++it) {
diff --git a/src/KeyGrabber.cc b/src/KeyGrabber.cc
index 57bb724..d157d16 100644
--- a/src/KeyGrabber.cc
+++ b/src/KeyGrabber.cc
@@ -336,6 +336,7 @@ KeyGrabber::findAction(XKeyEvent *ev, KeyGrabber::Chain *chain)
         return 0;
     }
     ev->state &= ~_num_lock & ~_scroll_lock & ~LockMask;
+    ev->state = PScreen::instance()->stripKbdLayoutModifiers(ev->state);
 
     ActionEvent *action = 0;
     KeyGrabber::Chain *sub_chain = _global_chain.findChain(ev);
@@ -347,6 +348,7 @@ KeyGrabber::findAction(XKeyEvent *ev, KeyGrabber::Chain *chain)
         while (! exit) {
             XMaskEvent(_scr->getDpy(), KeyPressMask, &c_ev);
             c_ev.xkey.state &= ~_num_lock & ~_scroll_lock & ~LockMask;
+            c_ev.xkey.state = PScreen::instance()->stripKbdLayoutModifiers(c_ev.xkey.state);
 
             if (IsModifierKey(XKeycodeToKeysym(_scr->getDpy(),
                                                c_ev.xkey.keycode, 0))) {
diff --git a/src/PDecor.cc b/src/PDecor.cc
index 46c0ffe..3bc532c 100644
--- a/src/PDecor.cc
+++ b/src/PDecor.cc
@@ -620,6 +620,7 @@ PDecor::handleButtonRelease(XButtonEvent *ev)
     // Remove state modifiers from event
     ev->state = PScreen::instance()->stripStateModifiers(ev->state);
     ev->state = PScreen::instance()->stripButtonModifiers(ev->state);
+    ev->state = PScreen::instance()->stripKbdLayoutModifiers(ev->state);
 
     // handle titlebar buttons
     if (_button) {
diff --git a/src/PScreen.hh b/src/PScreen.hh
index 33f6644..793ef8f 100644
--- a/src/PScreen.hh
+++ b/src/PScreen.hh
@@ -37,6 +37,9 @@ extern unsigned int xerrors_count; /**< Number of X errors occured. */
 #include <list>
 #include <map>
 
+#define KbdLayoutMask1 (1<<13)
+#define KbdLayoutMask2 (1<<14)
+
 /**
  * Class holding information about screen edge allocation.
  */
@@ -148,6 +151,11 @@ public:
         return state;
     }
 
+    unsigned int stripKbdLayoutModifiers(unsigned int state) const {
+        state &= ~KbdLayoutMask1 & ~KbdLayoutMask2;
+        return state;
+    }
+
     void setLockKeys(void);
     inline uint getNumLock(void) const { return _num_lock; }
     inline uint getScrollLock(void) const { return _scroll_lock; }

It seems keyboard is affected too - keychains are not working.

I have the same problem: with secondary keyboard layout pekwm does not responding to mouse buttons (keyboard still works). After switching back to primary it is OK again. No difference if layouts are configured in xorg.conf, hal or by setxkbmap

setxkbmap -layout "us,cz" -option "grp:shifts_toggle"

On machine at work : X -version X.Org X Server 1.6.2

Section "InputDevice"

    Identifier     "Keyboard0"
    Driver         "kbd"
    Option		"XkbRules"	"xorg"
    Option		"XkbLayout"	"us,cz(qwerty),de"
    Option		"XkbOptions"	"compose:ralt,grp:shifts_toggle,grp_led:scroll"

EndSection

second, that is configured via hal will I post later.

I couldn't reproduce this (using evdev+hal though). Please post your xorg.conf. What version of the X server do you use?

yes, setxkbmap does not cause this. However "standard" X keyboard switching does. No matter if configured via Xorg.conf or via hal.

try usign command in launcher setxkbmap

confirming. happens too at my machine. (also Arch).