Bug 274369

do you have kglobalaccel running on both heads?

how can i find out? 
ps aux says that only one instance is running

what means "unlikely" ;-)
kill it and run
kglobalaccel --display :0.0
kglobalaccel --display :0.1

in case that doesn't work with multihead (it's a kuniqueapplication), try adding "--nofork"

i doesnt work - when i start them with --nofork, i get for the second one

unnamed app(8026): KUniqueApplication: Can't setup D-Bus service. Probably already running.

Err... naming confusion?! (:0.0 :0.1 ./. "dualhead")

You're just using two screens and ... maybe xinerama?

no xinerama - here is xorg.conf

Section "ServerLayout"
	Identifier "standard"
	Screen 0 "Screen0" 0 0
#	Screen 1 "Screen1" LeftOf "Screen0"
#	Option "CoolBits" "1"
EndSection

Section "ServerLayout"
	Identifier "tv"
	Screen 0 "Screen0" 0 0
	Screen 1 "Screen1" LeftOf "Screen0"
#	Option "CoolBits" "1"
EndSection

Section "Files"
	ModulePath "/usr/lib64/xorg/modules"
	ModulePath "/usr/lib64/opengl/xorg-x11/extensions/" 
#	RgbPath         "/usr/lib64/X11/rgb"
EndSection

Section "Module"
#	Load "dbe"
#	Load "extmod"
#	Load "type1"
#	Load "freetype"
#	Disable "dri"
#	Disable "dri2"
	Load "glx"
EndSection

Section "ServerFlags"
	Option "DefaultServerLayout"  "standard"
EndSection

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
	Identifier "Monitor0"
	VendorName "LG"
	ModelName "LG L227W"
	HorizSync 30.0 - 83.0
	VertRefresh 56.0 - 75.0
#	Option        "DPMS"
EndSection

Section "Monitor"
#HorizSync source: xconfig, VertRefresh source: xconfig
	Identifier "Monitor1"
    	VendorName "Unknown"
	ModelName "TV-0"
	HorizSync 30.0 - 50.0
	VertRefresh 60.0
#	Option         "DPMS"
EndSection

Section "Device"
	Identifier "Videocard0"
	Driver "nvidia"
	VendorName "NVIDIA Corporation"
	BoardName "GeForce 8500 GT"
	BusID "PCI:3:0:0"
	Screen 0
	Option "NoLogo" "1"
	Option "RenderAccel" "true"
	Option "HWCursor" "true"
	Option "UseEdidDpi"   "false"
	Option "Dpi"          "95 x 95"
#	Option  "CoolBits" "1"
	Option "OnDemandVBlankInterrupts" "true"
EndSection

Section "Device"
	Identifier "Videocard1"
	Driver "nvidia"
	VendorName "NVIDIA Corporation"
	BoardName "GeForce 8500 GT"
	BusID "PCI:3:0:0"
	Screen 1
	Option "TVStandard" "PAL-B"
	Option "NoLogo" "1"
	Option "RenderAccel" "true"
	Option "HWCursor" "true"
	Option "ConnectedMonitor" "TV" 
	Option "TVOutFormat" "SVIDEO"
	Option "OnDemandVBlankInterrupts" "true"
#	Option "CoolBits" "1"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device "Videocard0"
	Monitor "Monitor0"
	DefaultDepth 24
#	Option "TwinView" "1"
	Option "metamodes" "DFP: nvidia-auto-select +0+0"
	SubSection "Display"
        	Depth 24
	EndSubSection
	Option "AllowGLXWithComposite" "True"
	Option "AddARGBGLXVisuals" "True"
EndSection

Section "Screen"
	Identifier "Screen1"
	Device "Videocard1"
	Monitor "Monitor1"
	DefaultDepth 24
#	Option "TwinView" "1"
	Option "metamodes" "TV: 640x480 +0+0"
#	Option "metamodes" "TV: 800x600 +0+0"
	SubSection "Display"
        	Depth 24
	EndSubSection
	Option "AllowGLXWithComposite" "True" 
	Option "AddARGBGLXVisuals" "True"
EndSection

Section "Extensions"
	Option "Composite" "Enable"
	Option "RENDER" "true"
	Option "DAMAGE" "true"
EndSection

Section "InputClass"
	Identifier "keyboard-all"
	Driver "evdev"
	Option "xkbmodel" "evdev" 
	Option "XkbLayout" "de"
	Option "XkbVariant" "nodeadkeys"
	Option "XkbOptions" "compose:rwin,terminate:ctrl_alt_bksp"
#grp:alt_shift_toggle,grp:switch,

	MatchIsKeyboard "on"
EndSection

Section "InputClass"
	Identifier "mouse-all"
	Driver "evdev"
	MatchIsPointer "on"
EndSection

I have also had this problem for a while now, probably since kde 4.4 or 4.5. 
I can confirm that it also still occurs on my system, which has the following specifications, in addition to a similar xorg.conf file as posted before (two separate Screen sections):
Version: KDE 4.7.4
OS: Debian Unstable
kernel 3.2.0-2-amd64
GPU: Nvidia 8400GS

This problem is also not limited to alt-tab'ing, but to all global shortcuts. It seems like whenever you close a window, or something similar, the focus is moved to the second screen. If you click anywhere on your first screen again, you can use your shortcuts again. Since the focus also seems to be moved to the second screen after using alt-tab (not always, but most of the time), this means you can't alt-tab to a window and then alt-tab back. Another instance where this occurs is when changing your virtual desktop using shortcut keys (e.g. Ctrl+F1)

Reproduction recipe: 
- set up your system with 2 separate X screens
- open several windows on your first screen 
- either alt-tab through a few windows or close one of them with your mouse
- try to alt-tab (or use any global or custom shortcut key)
You'll notice that it doesn't respond to alt-tab the second time, or more accurately, it performs the alt-tab on the second screen.

Workaround: 
- click on the first screen containing the windows and alt-tab again
Now the alt-tab works again.

The reproduction also seems be possible with other shortcuts, like Ctrl+F1 or simply by using alt-tab after closing a window with the mouse. This is a problem with global (and custom) shortcuts that are simply not being recognized on the second screen, but even if these were recognized (which i assume kglobalaccel is for) there are some screen-specific shortcuts, like alt-tab, that require the focus to remain on the screen (since it would otherwise alt-tab through windows on the second screen)

Note that this does seem to work correctly the first time, meaning the first alt-tab goes ok, then it also performs the second alt-tab correctly, but then after that the focus is moved to the second screen again causing a third alt-tab to fail. Performing the reproduction again makes it fail at the second alt-tab every time (until either enough time has passed or enough other shortcuts have been used, or something like that, to make it think that it's being used for the first time again).

Sorry for making my comment so long, I just hoped that a more detailed description would help resolve this issue more efficiently and more quickly.

it's not really a kwin issue, but kglobalaccel has no bugzilla component ;-)

The reason is that there's only one instance of kglobalaccel (the daemon managing the global shortcuts) as dbus isn't screen aware - since kglobalaccel is a kuniqueapplication (possibly got for shortcut exporting, no idea) it uses dbus to check whether there's an instance an then just quits.

this can possibly be fixed with a controlling kglobalaccel host, but apparently nobody has bothered to do so
this is more or less the "multihead doesn't work" dumpster bug (not your dupe, but worth reading)
https://bugs.kde.org/show_bug.cgi?id=256242

look around here for multihead bugs.
https://bugs.kde.org/buglist.cgi?product=kwin&component=multihead&resolution=---&list_id=14515


out of curiosity: why do you use independent screens (thus 2 kwin instances) instead of xinerama or preferably xrandr/twinview setups?

*** This bug has been marked as a duplicate of bug 237260 ***

The fact that kglobalaccel isn't multihead-aware does seem like a problem, but i don't think it's the main problem for this bug. It might help alleviate some of the symptoms from this bug, so you can still execute your shortcuts on a multihead system, but as I mentioned in my earlier comment, this is only part of the problem. There are still some screen-specific shortcuts, like alt-tab, that I assume would not be handled correctly even if kglobalaccel became multihead-aware. 

The other bug (the one that is duplicated by this) does seem to be about the same problem, but they seem more concerned with calling multihead systems outdated than actually fixing the problem. In the simplest terms I can describe the problem as follows: 
When you perform certain window actions (closing a window, or alt-tab'ing) the focus seems to be moved to the second screen, as if someone clicked on the second screen. This causes certain shortcuts to no longer function, either because they aren't recognized on the second screen or because they are screen-specific (which causes them to function incorrectly, or unexpectedly). 

Even my simple terms are quite long :P

As for my need/preference to use multihead over xinerama/twinview/xrandr, I'll try to explain my choice. First off, xinerama didn't seem like a viable option since everything I read about it seemed to indicate it was considered deprecated and/or problematic. So I initially went with Twinview, simply due to the fact that it seemed the easiest and best supported. However, my second screen is displayed on my tv and is not used in conjunction with my monitor, the first screen. In Twinview mode, this means that I would have a part of my desktop effectively hidden from sight (either because my tv is off or simply because I'm not looking at it). There were also some issues with playing my media on the tv while still being able to work on the monitor and I also prefer to have my screens separated (without my mouse wandering into an unseen space), which is why I started looking into the multihead configuration. And it's working quite well so far aside from this problem, which actually didn't occur when I originally set up my multihead configuration. As I mentioned in my earlier comment, this problem only started after upgrading to 4.4 or 4.5 (I don't remember exactly which, but I would guess 4.5)

Anyway, another lengthy comment, so once again my apologies for that. I hope this does get cleared up and that the other bug doesn't get too fixated on multihead systems being obsolete. They might not be very useful for the standard dual-monitor setup, side-by-side(-by-side :P ), but in certain cases, such as connected tv's and beamers (as mentioned in the other bug), it is the better option.