While I understand your need, I doubt any kwin developer will work on it. I 
seriously do not have the time for it and I (sorry to say so) do not see the 
need to work on it. Looking on what the other kwin developers are working on I 
don't expect that they will work on it. Our resources are rather bad, we just 
have about three part time developers.

Given the number of bug reports we have on multi screen X, I do not see the 
big need for supporting it. There are more important issues and I could not 
justify to myself to work on it, considering the bugs and demands we have in 
other areas.

So I think it's up to the users who need this feature, to step up and 
implement it.

#1 If it is so easy to implement that a normal user can do it, it should be peace of cake for someone who already know the code and already have the developing tools set up.

And there are always more important issues like familie, friends and a real job. If those thing was not more important I would be busy reading op on all the things needed for fixing bugs in kde :)

*** This bug has been confirmed by popular vote. ***

I'm using two screens with TwinView on a Nvidia GT220 (260.19.12) (1024x768 l and 1280x1024 r) and everything is working almost perfect. Never saw a reason to use separate X-Servers

@icarus6 - just info:
the bug description is wrong, running one kwin on multiple servers is completely impossible. they want to use one server, multiple screens á one display, while you're using one server, one screen spanning 2 displays.

that's actually the advanced solution, (multiscreen has various functional drawbacks) but only matrox and very recent ati chips can serve more than 2 displays at once. so to get tri-screen you need a second GPU and thus multiscreen (or SLI on an nvidia quadro chip, seems geforce is still not supported by twinview)

#4
Have nvidia implemented TwinView in such way that it works with 2 cards?

I am running debian with 195.36.24 driveres with 2 cards. One card powers screen 1 and and one cards powers screeen 1 and 2. As fare as I know I have to use sepereted x servers.

If you have another usefull settup for me that works without that I would gladly use that setup

#5 
maybe running 1 kwin pr server instead would help?

When seperet x (using nvidia term from gui) is that one X server? If it is so that work OK with kwin 3.5

it says "separate X screen" - what is obviously NOT a second *server* but *screen* ;-)

and yes: apparently multiscreen support was lost - this is the point of this bug.
the core problem (afai understood) with multiscreen is that kwin (currently) runs only one compositor - what is simply not enough.

tried the "fake xinerama" attempt?

Thomas Lübking (In reply to comment #5)
> @icarus6 - just info:
> the bug description is wrong, running one kwin on multiple servers is
> completely impossible. they want to use one server, multiple screens á one
> display, while you're using one server, one screen spanning 2 displays.
> 
> that's actually the advanced solution, (multiscreen has various functional
> drawbacks) but only matrox and very recent ati chips can serve more than 2
> displays at once. so to get tri-screen you need a second GPU and thus
> multiscreen (or SLI on an nvidia quadro chip, seems geforce is still not
> supported by twinview)

Yeah, I noticed that. It just seems to be needlessly complicated, I'm using 1 graphic card and 2 screens.

(In reply to comment #4)
> I'm using two screens with TwinView on a Nvidia GT220 (260.19.12) (1024x768 l
> and 1280x1024 r) and everything is working almost perfect. Never saw a reason
> to use separate X-Servers

Even with 2 screens there some use cases where you need a seperate configuration for each screen. One example (my case). To me it is totaly important that when I start an application on one screen it will be opened exactly on this screen and not on the other one (because TV is not everytime on power). Furthermore it's also important that when I would change the virtual deskop on the one, the virtual desktop of the other must not move. You can't get such a behavior with twin-view because on twin-view you only have one desktop which is shared on two screens.

@incarous6 we have been trying for 3 years to draw the developers' attention on this *BUG* and restore lost functionality that was in kde since forever. We are asking for the native true dual-head or actually now multi-head mode to be supported again in linux/KDE. 
Instead you are proposing an inferior, proprietary, vendor specific and yet very well supported by Windows... err I mean "linux" screen mode.
So tell me son
* can you set a different dpi in those monitors of yours?
* can you launch a program and tell it to open it's window on your preferred monitor? 
* can you have a separately configured desktop and taskbar, and widgets?
We had all that, until linux started trying to become a Windows clone.
I suggest you try zaphod mode, if it ever gets fixed. You'll never go back.

(In reply to comment #11)
> @incarous6 we have been trying for 3 years to draw the developers' attention on
> this *BUG* and restore lost functionality that was in kde since forever. We are
> asking for the native true dual-head or actually now multi-head mode to be
> supported again in linux/KDE. 
> Instead you are proposing an inferior, proprietary, vendor specific and yet
> very well supported by Windows... err I mean "linux" screen mode.
> So tell me son
> * can you set a different dpi in those monitors of yours?
> * can you launch a program and tell it to open it's window on your preferred
> monitor? 
> * can you have a separately configured desktop and taskbar, and widgets?
> We had all that, until linux started trying to become a Windows clone.
> I suggest you try zaphod mode, if it ever gets fixed. You'll never go back.

-I'm not sure about that dpi thing, never used that and I wont test ist. That could help: http://http.download.nvidia.com/XFree86/Linux-x86_64/1.0-8762/README/appendix-y.html
-Yes, you can set up in your system-settings under "multiple monitors" in your screen settings which screen you prefer for apps to open in. (Note: you can set up the standard position of a window)
-That's a screenshot of my desktop (the black border is the size difference of both displays): http://img576.imageshack.us/img576/9954/desktop2cf.png

Some people migth be interested in http://nextsprocket.com/tasks/fixing-a-bug-in-kde-with-multiply-xog-runnings 200 dollers so far for the person who fixes this bug

I dived a bit into KWin sources and I have to say I'm a bit confused. All the infrastructure needed for multihead seems already there, see for example the bottom of main.cpp. I also discovered that setting KDE_MULTIHEAD=true makes kwin start automatically on all the screens. Now this env variable is also set automatically (by plasma?), but too late for kwin to recognize it. Maybe setting it in ksmserver should help? About the maximizing issue as far as I've understood kwin uses XGetWMNormalHints and passes qx11info::display() to it. So I wonder where the problem may be. I may try to write a patch, but it would be easier if a dev clarifies these points. Thanks!

*** Bug 182082 has been marked as a duplicate of this bug. ***

#14 
Do you need help for from an end user regarding testing? 

Do you need some hardware for developing?

Did you talk wiht some of the kwin developers regarding those issues?

Are there some progress on fixing this bug?

(In reply to comment #16)
> #14 
> Do you need help for from an end user regarding testing? 
> 
> Do you need some hardware for developing?
> 
> Did you talk wiht some of the kwin developers regarding those issues?
> 
> Are there some progress on fixing this bug?
Hi Jonas!
Before I need testing, I need to actually understand it :-). In these weeks I think I've tracked down the problem to kephal, the library that interfaces with randr and gets the screen resolution. The problem seems to be that it connects to a sort of "server" via dbus, and only one instance of it is started with kde (on screen 0).
I have all the necessary hardware (2 nvidia gtx285), but the real problem is that sources are really not that clear. I haven't received any answers so far from kwin developers, but I understand that (they are doing a really great job with gl es port and so on, I imagine they haven't got much free time). Once I pass my last uni exam next week, I will return working on this more aggressively.

*** Bug 268395 has been marked as a duplicate of this bug. ***

Created attachment 58970 [details]
patch to fix multi head kwin

The attached patch implements basic multiscreen support in kwin:
* It now autostarts on all monitors if a multihead configuration is found
* It sets the correct resolution when maximizing on monitors with different resolutions.
I've tested it with multihead (obviously) and xinerama (to rule out regressions).
(NOTE: I'm the same person behind support.intranet@libero.it, but I've switched to my developer account)

Thanks for the patch. Could you please upload it to git.reviewboard.kde.org so that we can do a 
review (I saw some whitespace changes) and so that it does not get forgotten.

Please note that I won't be able to do a proper review the next week and that I don't have the 
time to merge it. Just to be sure, you might want to add it to the feature plan ;-)

Any changes that it will be included in 4.6.3 since it is a bug fixing or shall we wait for 4.7?

(In reply to comment #20)
> Thanks for the patch. Could you please upload it to git.reviewboard.kde.org so
> that we can do a 
> review (I saw some whitespace changes) and so that it does not get forgotten.

Done. As reviewers I've set "graesslin, luebking". Is it okay?

> 
> Please note that I won't be able to do a proper review the next week and that I
> don't have the 
> time to merge it. 

Ok, no problem ("I don't have the time to merge it" applies to next week or in general?)

>Just to be sure, you might want to add it to the feature plan
> ;-)

Ok, done.

> (In reply to comment #20)
> > Thanks for the patch. Could you please upload it to git.reviewboard.kde.org so
> > that we can do a 
> > review (I saw some whitespace changes) and so that it does not get forgotten.
> 
> Done. As reviewers I've set "graesslin, luebking". Is it okay?
Thanks. Please also add group kwin
> 
> > 
> > Please note that I won't be able to do a proper review the next week and that I
> > don't have the 
> > time to merge it. 
> 
> Ok, no problem ("I don't have the time to merge it" applies to next week or in
> general?)
only for the next week. That's why I want you to add it to the feature plan
> 
> >Just to be sure, you might want to add it to the feature plan
> > ;-)
> 
> Ok, done.
cool

> Any changes that it will be included in 4.6.3 since it is a bug fixing or shall
> we wait for 4.7?
Given that it is added to the feature plan it is clearly not for 4.6 - sorry

Created attachment 59005 [details]
Patch for ksmserver-4.6.2

Created attachment 59006 [details]
Patch for kwin-4.6.2

Above two patches adapted(removing whitespaces etc.) for kde-4.6.2. For gentoo users just place them to /etc/portage/patches/kde-base/ksmserver/ksmserver-4.6.2-multihead.patch and etc/portage/patches/kde-base/kwin/kwin-4.6.2-multihead2.patch. Then re-emerge kwin and ksmserver.

Thank you Alberto Mattea! You are my hero. Finally I can use kde4.

I had to clean my kde-config to make it work. And it seems I must do "kwin --replace" each time I log in. I can live with that.

(In reply to comment #27)
> Thank you Alberto Mattea! You are my hero. Finally I can use kde4.
> 
> I had to clean my kde-config to make it work. And it seems I must do "kwin
> --replace" each time I log in. I can live with that.

I've just tried with clean kde profile and kwin started at second screen, so no kwin
 --replace is needed.

I have 3 monitors. KWin seems to start correctly on two of them. After "kwin --replace" everything is working perfectly. I can gice a more complete report later when I have used it a while...

Hi ! (sorry for my bad english !)

I have got 2 nvidia video card and 2 screen for each video card on separate x screen.

before kde sc 4.6.2, kwin/plasma don't start in nvidia2/screen2. I was use openbox for that.

since kde sc 4.6.2 kwin/plasma launch fine in nvidia2/screen2. but I have got some issues =>

- keybaord inactive on screen2
- no window decoration
- taskmanager don't see launched applications on screen2.

Hi ! 

how I can test these patchs on my kubunu natty ?

you've got to fetch the sources of kwin (kde-workspace), apply the patches (man patch) and compile them.
you'll need a fully compilation-suited environment for this (development packages of X11, Qt, kdelibs, kdeworkspace as well as of course gcc and glibc)

(In reply to comment #23)
> > (In reply to comment #20)
> > > Thanks for the patch. Could you please upload it to git.reviewboard.kde.org so
> > > that we can do a 
> > > review (I saw some whitespace changes) and so that it does not get forgotten.
> > 
> > Done. As reviewers I've set "graesslin, luebking". Is it okay?
> Thanks. Please also add group kwin
> > 
> > > 
> > > Please note that I won't be able to do a proper review the next week and that I
> > > don't have the 
> > > time to merge it. 
> > 
> > Ok, no problem ("I don't have the time to merge it" applies to next week or in
> > general?)
> only for the next week. That's why I want you to add it to the feature plan
> > 
> > >Just to be sure, you might want to add it to the feature plan
> > > ;-)
> > 
> > Ok, done.
> cool
> 
> > Any changes that it will be included in 4.6.3 since it is a bug fixing or shall
> > we wait for 4.7?
> Given that it is added to the feature plan it is clearly not for 4.6 - sorry

Hi Martin. I've submitted a new version to reviewboard, with whitespace fixes and other simple changes. Any chance you could review it? I'd like to see it in KDE 4.7, and hard feature freeze (May 12th) is approaching. Thanks.

Hi
I just upgraded to kde 4.6.4 on debian sid.
I can confirm that the "autostart of kwin on the other screens" problem has been solved.

I still detect 2 problems:

- broken handling of shortcuts such as alt+f2 is broken if a window is selected on non-0 screen and alt tabbing seems to be broken no mater what.

- stat of program on wrong screen. If I start a program it sometimes start on the wrong screen.
Eks if I try to start Dolpin on screen 0 it sometimes start on screen 1. It seems like it happens only if I already have an instance on of doplhins on screen 1.

Is those issue already fixed in kde 4.7?

If you've a dolphin instance on one screen (whether the window is shown or not doesn't matter) and want to run one on the other screen, you'll have to create a new process (because Qt supports only one screen per process and i've no idea wheter other would be possible at all)

   "dolphin --nofork&"

Also I guess you'll have to run one "kglobalaccel" daemon per screen in order to support global shortcuts on each screen.

(In reply to comment #35)
> Also I guess you'll have to run one "kglobalaccel" daemon per screen in order
> to support global shortcuts on each screen.

I tried to get this working some time ago. I patched the daemon to fork on all the screens, as I did with kwin. The main problem I ran into was that kglobalaccel tried to register a dbus service, so the second instance failed saying that the service was already registered. I don't know dbus very well, is there a way for two processes to share a dbus service?

(In reply to comment #36)
is there a way for two processes to share a dbus service?

No. kglobalaccel would have to register screen aware services the.

The problem here seems that it fixes the service name in order to export shortcuts to dbus, what's actuall a nice feature but breaks things for multiscreen.

As a consequence you would not be able (at least not for additional screens) to use dbus access to kglobalaccel (this might be invoked from some plasmoid or so).

Hi ! (sorry for my bad english !)

"kwin --replace" solved the problem for me too.

but I have got a new problem =>

- resolution, on my LED TV, is ok
- but each window extend beyond on the screen when I maximized them.

(In reply to comment #38)
> Hi ! (sorry for my bad english !)
> 
> "kwin --replace" solved the problem for me too.
> 
> but I have got a new problem =>
> 
> - resolution, on my LED TV, is ok
> - but each window extend beyond on the screen when I maximized them.
What version are you using? The patch is in kde 4.7, not in 4.6.x

I'm using kde sc 4.6.4 on kubuntu 11.04 (32 bits).

I don't use the patch but I wait 4.7 update from kubuntu ppa for test it.

some files understand my problem

Created attachment 61427 [details]
kwinrc

Created attachment 61428 [details]
plasma-desktoprc

Created attachment 61429 [details]
plasma-desktop-screen-1rc

#36
Are you still trying to fix the reminding bug with seperate X-Servers and KDE. If not I should proberbly go and file bug reports about the bugs in #34 to the prober part of kde since those bug are not kwin related as far as I know

(In reply to comment #45)
> #36
> Are you still trying to fix the reminding bug with seperate X-Servers and KDE.
> If not I should proberbly go and file bug reports about the bugs in #34 to the
> prober part of kde since those bug are not kwin related as far as I know

Hi, right now I am on holiday, I am going to try again when I get back home.
It doesn't seem easy though.

#46
Tank you for that you did fix kwin and thank you for trying to fix the other problems with kde 4 and multihead

Thank you for fixing some of the regressions. I've testet it with kde 4.7.1 and the situation is much better than with kde 4.6.
The noticable bugs are the same as in #34 + that if you have the variable 'disableMultihead' at 'true' you have to kill kglobalaccel and have to restart it to get shortcuts working.

Thanks also a lot for trying to fix the bugs which are left. I hope this is doable

I'd found some problem at KDE 4.7.2 (same as in #34). In separated screens mode pressing Alt+Tab or Ctrl+F1 (etc) windows/desktops are trying to switch randomly on 2 monitors, sometimes nowhere, sometimes at any one.

Thank you for fixing.

Hi 
I hope that Alberto Mattea or another person would fix the remaining issue before KDE 4.8 since that will, probably, end up in the next Kubuntu that is an LTS and therefore will be used much.

Is there any news about this bug?

*** Bug 286379 has been marked as a duplicate of this bug. ***

#52
in Bug 286379 suggest that we should use Xrandr or nvidia tvinview. If I should use one of those I would have to stop using 2 graphics cards (and therefore only use 2 screeen instead of 3).
My workaround on this bug was to install win7 (got one copy for free from uni) and run kde on windows. This would not last forever (since MS will stop patching it at some point)

Yes, that is what this bug is all about :-P

What would likely have to be done for kglobalaccel is to

a) register a per screen service (org.kde.kglobalaccel_0,
org.kde.kglobalaccel_1, ...)

b) register a fixed name (org.kde.kglobalaccel) service if there's none

c) if there's one, monitor the session bus and try to take it if it's released

d) if it has the fixed name (and/or is invoked by that) pass calls to unknown components to all other org.kde.kglobalaccel_* services

e) to achieve that, register to the current or rising fixed name service if it's not one self

f) this also likely means to bypass and handcraft kuniqueapplication handling

-> passing to michael for comments ;-)

*** Bug 276658 has been marked as a duplicate of this bug. ***

*** Bug 291643 has been marked as a duplicate of this bug. ***

Is there ane progress? news?

#57
So there is no news about it. Nor any progess. Alberto Mattea are you still trying?

Is there any news or updates on this "bug"?

(In reply to comment #59)
> Is there any news or updates on this "bug"?
No, and I don't expect that this will happen anytime soon or ever at all. At least from the KWin team I expect nobody will work on it given that the multi-head feature is mostly deprecated in X (replaced by sane modes such as xrandr) and even X is deprecated nowadays (Wayland 1.0 should be released the next days). With Wayland we get proper screen handling from day 1. So from a project perspective it makes more sense to invest the time in Wayland than the deprecated technology.

Thanks for the information.

Even that wayland 1.0 should be released "soon" (are we already counting days) there are still a lot of work that needs to be done. As far as I know (feel free to tell me if I am wrong) wayland support will arrive in QT 5 and GTK has basic support but have major gaps. When that is done then application developers can start porting. And then there is the "problem" with closed source driver that is not ported (as far as I know AMD and NVidia does not have any plands for wayland yet). When those things are done then distroes can begin to pick it up.
My personal guess is that we will have distroes with wayland within 2-4 years, but I hope I am wrong and would see it at Kubuntu 13.04

(In reply to comment #61)
> Even that wayland 1.0 should be released "soon" (are we already counting
> days)
yes, it was supposed to be released last week, but got a delay to next week. So we are in counting days mode :-) Of course for the normal user or developer that actually doesn't matter.

> there are still a lot of work that needs to be done. As far as I know
> (feel free to tell me if I am wrong)
You only looked at the toolkit point of view which is rather irrelevant from a KWin point of view. KWin will be running on top of KMS (libgbm which is part of Mesa 9) and can talk with the XServer through XWayland (planned to hit the next XServer release). Given that it actually doesn't really matter that the applications are still using X11 and not Wayland. Weston (the reference compositor) is already functional on the normal Mesa stack or nested underneath another Wayland compositor or nested underneath an X-Server. And the Qt-Compositor has been ported to the RaspberryPi which has a proprietary drivers, so that seems to not matter either :-)

Can wayland actually spread one display server across several GPUs?
(Sounds tricky if you want the clients to paint into the offscreen buffer, because you'll have to sync the buffer from one GPU/RAM to the other one)

(In reply to comment #63)
> Can wayland actually spread one display server across several GPUs?
> (Sounds tricky if you want the clients to paint into the offscreen buffer,
> because you'll have to sync the buffer from one GPU/RAM to the other one)
I think the buffer and compositor are associated with one screen. So I would assume compositor and window are always on the same GPU. Might be tricky for things like present windows but a solution might be the buffer sharing which got demoed as network transparency replacement at XDC.

I wish there was some sign of hope for this feature.... I'm running kde 4.9.2. Is there anything I can do to hack together a decent multi-head setup? I saw some patches posted above, are those still worth applying; or does the dbus bug still make separate x sessions pretty unusable? I'm on an nVidia card (twinview isn't ideal for me), trying to get separate x sessions on 2 monitors.

Nick, you can try replacing the window manager (default apps in systemsettings) to compiz. That will solve some of the problems and it will introduce others. Let me sum it up for you so you can make a somewhat informed decision.
Advantages:
- the biggest is that alt+tab will be usable. some others too, but only the ones related to the window management. (for example alt+f2 will only work in screen 0)
- focus management is much better, although not perfect
- window management is perfect (maximizing etc, but that's good in kde 4.8 too)
- more, better looking and more configurable eye candy, using ccsm is not a walk in the park, but after you get the hang of it, it is very powerful.
Disadvantages:
-the biggest is that activities will no longer work correctly. compiz is not aware of them, so it will show every window from every activity.
-installation requires some fiddling around, your launcher script has to start compiz on every screen, and also afaik there no longer is a kde-window-decorator for compiz (existed only for kde3). You can use the gtk-window-decorator which is ugly (gtk usually is) or you can compile emerald - which is surprisingly easy for ubuntu (just google it) but I don't know about the rest, solving all the dependecies can be really hard.
- some elements of plasma will not look as good with compiz as they do with kwin. For example the notification with kwin looks like a beautiful piece of glass but with compiz is very greyish.

I would like to add that I am really disappointed that this "bug" had to be reported in the first place. Saying that "do not see the need to work on it" has a very microsoftish aftertaste. Not every people think alike, for example my opinion is that xinerama is a joke, I rather struggle with setting up a dual head.

I know that wayland is officially released and it is important to stay up to date but it will be a looong time before it will actually be used by any distro. At least another year, maybe more. In the meantime people still have to use their computer.

It's really a pity because in every other respect KDE is the coolest DE ever...

ok, to get it right once and for all: Multi-head setups with one X-Server per 
screen is considered a legacy setup which is not provided by all drivers any 
more.

Multi-head setup has rather drastic limitations, like:
* cannot move windows from one screen to another
* needs to be configured through adjusting xorg.conf
* setup changes need restart of X Server

Just the fact that one has to edit xorg.conf can show one what's the state of 
this feature inside X. The config file itself is deprecated, my system doesn't 
have one anymore.

Now what do these limitations mean:
* useless for common users
* difficult to develop on

Supporting multi-screen setups is important and there is work going on to 
improve the primary way to handle multi-screen - that is through XRandR. Since 
even NVIDIA supports the latest XRandR spec, it's supported by *all* vendors.

The fact that it is difficult to develop on is at least for me reason enough 
to not touch it. I log-out a session about once a month, so the fact that I 
need to restart the X-Server is quite a blocker. Also I'm a heavy user of 
moving windows from one screen to another. That is at least for me reason 
enough to not want to work on it. Whether my driver would support it at all is 
completely unknown to me.

Last but not least there is Wayland. Wayland is the future. Spending time on 
legacy is not useful at all. I hope anyone can understand that one does not 
develop code which gets obsoleted in a few months. One normally plans to have 
code being used for several years.

Nevertheless we are happy to accept patches. But don't expect anyone from the 
KDE developers to work on it. I don't think any developer is using a multi-
head setup and for everybody it's not a "scratch your own itch" problem.

If multi-head is important you could consider to ask Qt or other open source 
consultant companies like KDAB, BasysKom, Digia, ICS or Collabora to implement 
that feature for you. It might not be cheap, but that's because it is a lot of 
work and nobody can tell how much work is actually needed to develop it.

Now please don't tell me how important multi-head is for you. I do understand 
that. Unfortunately there are many users and they all have their very 
important feature one should implement.

To be clear. I don't particularly care how a sane multi-head setup is achieved, I was simply noting that I wished it were achievable. Most of your post addressed why this feature is no longer maintained using X.org.. the problem (for me), is that nothing ever arose to take its place. TwinView has a multitude of problems itself, and doesn't integrate well with activities or FAR more importantly, workspaces. I can do all sorts of obnoxious hacks and config edits to get a modicum of the functionality I want out of TwinView, but it's far from ideal (taskbars and sane window associations to name a few more problems). Wayland is a fine pipe dream, but it's not like Wayland has been "just around the corner" since multi-head became legacy. For me personally, Wayland will bring more problems than solutions. Great, so I'll have a decent mult-head setup, I just have to sacrifice gaming, network transparency, and the majority of my applications for a few years (more likely indefinitely) to get it.

Your comment looks like you never try XRandR.

#RunetMember  I have tried XRandR but never manage to get it to work. Back then (if I remember correctly) XRandR is limited to work only with on graphic cards (I have 2 since that is my best option if I want my 3 screens to work). And there was some problem with full screen application. Instead of spanning 1 screen it spanned 3 screen.

#Martin Gräßlin:
you are raisning 3 bad things about Multi-head setup. They may be valid for some people but fir me those are minor problems compared with the problems with other way of using 3 screens.

You also mention that we could find someone that can fix the problem for us. The price proberbly higher than 1 person would pay for it (I would glady put some money behind it but that does not seems to be enough).

I also understand that you/kde community dont want to use the time on it since we have wayland around the corner (wayland 1.0 has been released). But I dont think we are talking about a few months but a few years before it is ready for end users. if we are lucý it might be ready for kubuntu 14.04 and Debian jessie. I would gladly give it a test when I see wayland in those distros and with support from Nvidia

(In reply to comment #67)
> ok, to get it right once and for all: Multi-head setups with one X-Server per 
> screen is considered a legacy setup which is not provided by all drivers any 
> more.
'considered' by you and the rest of KDE devs, that we get. that's why we complain. me, at least.

and i hope you realise that "Multi-head setups with one X-Server per  screen" is not 1 setup, it's 3:
* hard multi-screen with full screen separation (Zaphod-mode)
* soft multi-screen with no screen separation (Xinerama)
* multi-seat on separate cards (and, maybe, on a same card on recent X)
should i explain usefulness of each of them ?

> Multi-head setup has rather drastic limitations, like:
> * cannot move windows from one screen to another
'limitation' for you, a _desired feature_ for me :/

> * needs to be configured through adjusting xorg.conf
> * setup changes need restart of X Server
there are no faculties to assign separate settings for several X and/or X-driver instances in xorg.conf.d scripts, too bad.

> Now what do these limitations mean:
> * useless for common users
but that is a complete bullshit: if you willingly not using them, it doesn't mean it has no usage.
or is "common" stands for 'most' or 'similar to you' ? because 'most' users use Windows with one shitty display, might as well go developing a payed screensaver or something for that target audience.

> * difficult to develop on
everything is difficult, when you don't have interest for it.

> Supporting multi-screen setups is important and there is work going on to 
> improve the primary way to handle multi-screen - that is through XRandR.
which doesn't support any of those setups.

> Since even NVIDIA supports the latest XRandR spec, it's supported by *all* vendors.
i think we all get how KDE devs (like Firefox devs) use and target almost exclusively Nvidia graphics, good for you. but it's not a good reason to forget and abandon what FreeDesktop guys did and do.
not from "common user" standpoint, anyway.

> The fact that it is difficult to develop on is at least for me reason enough 
> to not touch it. I log-out a session about once a month, so the fact that I 
> need to restart the X-Server is quite a blocker. Also I'm a heavy user of 
> moving windows from one screen to another. That is at least for me reason 
> enough to not want to work on it. Whether my driver would support it at all
> is 
> completely unknown to me.
that's a good point.
point for you and any other unwilling not to work on it, but not to classify these setups and features as 'deprecated', 'obsolete' and 'useless' for the rest of us.

you _don't want_ to do what you don't use. fine. no one forcing you to.
no reason to speculate about it though.

> Last but not least there is Wayland. Wayland is the future. Spending time on 
> legacy is not useful at all. I hope anyone can understand that one does not 
> develop code which gets obsoleted in a few months. One normally plans to
> have 
> code being used for several years.
u-hu, "few month"... riiiight.
i pretty sure for a bet that even entire KDE will not be fully supporting Wayland until Nvidia would care to release binary for it. not to mention distributions's transition on it, which isn't happening any time soon.
those are far-fetched plans, where we, users, don't have compelling support for either current ("deprecated") technology nor a maturity of the future one (or to put it simply: screwd).

> Now please don't tell me how important multi-head is for you. I do
> understand 
> that. Unfortunately there are many users and they all have their very 
> important feature one should implement.
yeah, and then you, please, don't tell me how unimportant it is for you, while trying to pass it of as some kind of objective, universal point.
when maybe then we will be fine, each in our corner being dissatisfied silently.

"yeah, and then you, please, don't tell me how unimportant it is for you, while trying to pass it of as some kind of objective, universal point.
when maybe then we will be fine, each in our corner being dissatisfied silently."

I prefere that the team/Martin Gräßlin  says that the dont wonna fix it and give a good reason for it instead of being silently. I do disagree with some of his point why it is not needed but at least I can understand the underlying argumentation for him not to invest time in fixing our problem

a) The predominant GPU are the intel IGPs - afaik Martin does not even have an nvidia GPU in use.

> but it's not a good reason to forget and abandon what FreeDesktop guys did and do
http://www.freedesktop.org/wiki/Software/dbus

you can btw. point any complaints about the head agnostic dbus design *there* - aiaik nvidia had no part in it.

b) The *common* user does not use >1 screens at all.

c) Multiseat is not affected at all, the problem is around several applications and daemons being designed as single instances below the X11 layer what then breaks on the X11 layer.

d) If you desperately wish support for it, I suggest you start looking around what all needs to be done for reasonable multihead support (for convention, we don't tag xinerama nor multiseat like that), on a modular desktop environment (compiz handles global shortcuts like alt+tab itself while KDE uses a daemon so that all applications can register such) starting by dbus, ending with rather minor things (eg. the sanity flag set by kwin on startup "breaking" compositing on the second head could easily be fixed in a minute - if that was it to make you happy, i'd immediately do. but it's not. I'd also check for false handling of events on different heads (focus issue), but we'd still not nearly be at a usable point)
If you then have at least a *slight* idea what needs to be done and still desperately want it, start acting. Better call for helping hands and then write patches. There's no "not gonna happen and if hell freezes over" attitude here around, but the estimation that the gain is not nearly worth the efforts and a complete lack of interest among as it seems each and every developer (not only kwin related) around.

MS btw.has 94000 paid full-time employees (just fyi, reg. the microsoftish notion)

PS: afaics, it's probably not that FF does only care about nvidia, but from various bugs running in here over the past years the simple sad truth is that the nvidia blob has still the most reliable and robust opengl implementation (FOSS drivers are improving, though)

Thomas, MS may have 94000 employers, but it still manages to create an unconfigurable piece of sh*t that they call an "operating system". The lack of passion (of the programmers) is the main reason that kills a software.
With ms windows you are forced to use a xinerama-like system and I hate it. When I must work with windows I curse all day - fortunately that's only about 10-20 days a year.

To Martin:
> * cannot move windows from one screen to another
This indeed is a limitation. In fact it is the ONLY limitation. But I think every multihead user learned to live with it (I certainly did), others may even desire it (like Sergey).
> * needs to be configured through adjusting xorg.conf
So what? Who cares. I'm currently an ATI user, and amdcccle has the ability to create this file for me. And if I recall correctly nvidia-settings can also do it.
> * setup changes need restart of X Server
Again, I don't think this is a big problem for a user. You don't even have to restart the computer, just log in and out and lot of applications (like firefox) save their state + there is a session manager in almost every DE.

> * useless for common users
Well yeah, for a user that doesn't care, there is no need to develop anything extra. I myself would like to be able to make my computer behave the way I want.
> * difficult to develop on
Now this one I believe.
If global shortcuts were fixed, I would be satisfied with the current state of KDE but I have no idea how hard that would be to implement.

And finally to Nick: I don't get you, you asked: "Is there anything I can do to hack together a decent multi-head setup?", then I tell you to try compiz, then you reply "To be clear. I don't particularly care how a sane multi-head setup is achieved, I was simply noting that I wished it were achievable." So then what exactly do you want?
Anyway, I was just trying to help.

I am reading this discussion with great interest.
In general, it is not interesting why someone needs that.
This functionality worked perfect in KDE-3.x and it was far superior to what guys from MS had at the time. Interesting is why KDE people forgot it in the early specifications for 4.x version. Why should we loose the edge?
Any ways, the latest versions of KDE (kwin, plasma-desktop) works fine on my quad screen desktop, using 2 NVidia cards.
xorg.conf settings is straight forwards and consequent. I have shown these settings couple of years ago on this log.
The only problem that I have is lack of 'multi-head' task bar.
When I minimize a window on the 'not first' screen, than the window is visually gone. I can pop it only using some tricks with xlsclients and xwit, but it is very annoying.
I am willing to write a patch to it, either set the icons from other screens to the KDE's task bar 'default panel', which is available only on the screen 0, or add a possibility to create a panel with the functionality of 'taskbar' on all screens.
Is that the option? Or kwin people would have some problem with that?

Hm interesting... are you sure you are using a multihead setup? I have KDE 4.8.5 and I can create on the secondary screen (:0.1) a new empty panel by right clicking on the desktop and then put on it a task manager widget and that's it. Or are we not talking about the same thing?

I am sure. Four screens: :0.0, :0.1, :0.2, :0.3. Full screen is 'fullscreen' on a screen, no windows moving from one screen to another.
Check on your screen :0.1 if you can create new default panel. And if you start: konsole --display :0.1 and minimize it - what happen?

oh, right, that's a known bug: http://community.kde.org/Plasma/Multihead
you can't create a default panel, but you can create an empty one, and populate it yourself.
that's actually not a severe bug, we don't have to create panels 10 times a day...

Of course not. As soon as I can find my iconized konsole icon. It doen't apper in 'new panel'. Niether  in the taskbar panel.

I'm still not sure we are talking about the same thing :) Anyway, did you add a task manager to your new panel? Unlock your widgets if necessary, then click on the panel toolbox (on the corner of the panel, it looks like a splash in a half circle) then click on Add widgets, find the one named "Task Manager", double click on it and you are done.

You are right. Thank you. So I am all set. No complains any more aboud KDE. My multihead KDE 4.9.3 (on gentoo) works fine. Any one needs the setings of my xorg.conf - let me know ...

I want to thank you in general for your comments. I'm sorry that I won't answer them individually - given that this is a linear discussion it does not make any sense.

Some of the comments seem to try to convince me of the importance of adding this feature. I'm sorry you missed the point. I am totally aware of the situations where one needs a multi-head setup and I'm also totally aware that neither XRandR, Xinerama or TwinView can replace some of the features of a multi-head setup. I also acknowledge and totally understand that some of the features are essential for you or that some of the limitations are features from your point of view.

That has not been the point of comment #67 and I asked you to not start discussing about it. Further discussions won't help you because I do know all about it. The intention of comment #67 was to explain why nobody from the KDE developer group has worked on it and why it is unlikely that in future somebody will work on it. Please understand that we have to prioritize and proper multi-head support is at least on my priority list not present due to the issues I have pointed out. When putting items on my priority list I do take all arguments pro and contra into account. Of course I cannot comment on the priority list of other developers but given the state it has been in for the last few years I doubt that it has been on the radar of any developer and I doubt it will come on the radar due to other high priority issues (QML, Qt 5, Frameworks 5, Wayland to name a few).

Now a personal comment: if you try to convince me of the importance don't try to be "smart" with your comments. Trying to invalidate my points about difficult to develop by saying it's all difficult or stating that we only care about NVIDIA (which is kind of funny given that for a long time NVIDIA had been the only working multi-head setup) or trying to show us the un-importance of Wayland due to NVIDIA not supporting it or calling my argument bullshit or bringing the "but in KDE 3.5" argument does not help you at all, if at all it puts your requests even further down the priority list. That's a style of discussion I dislike and I don't think it's fruitful at all. Especially the KDE 3.5 argument doesn't help you given that my first commit went into 4.1.

Now before commenting again please consider that no matter what you write you will be able to change my mind and it's unlikely that you can put into this report any more information which is not yet already known.

(In reply to comment #74)
> And finally to Nick: I don't get you, you asked: "Is there anything I can do
> to hack together a decent multi-head setup?", then I tell you to try compiz,
> then you reply "To be clear. I don't particularly care how a sane multi-head
> setup is achieved, I was simply noting that I wished it were achievable." So
> then what exactly do you want?
> Anyway, I was just trying to help.
Hi Soos Gergely, 
Sorry.. That comment was more in reply to Martin than it was to you. I should've been more clear. I appreciate your suggestion, and I'll probably check it out sometime soon. I didn't reply to you directly because I haven't yet tried it.

Created attachment 75230 [details]
Catch glIsUnsafe conflict and avoid tabbox invocation from wrong screen

Attached is a patch that covers to problems.
Afaics the alt+tab leaking focus issue should be resolved, but IT IS ABSOLUTELY NECESSARY THAT SOMEONE ACTUALLY USING MULTIHEAD TESTS THIS - otherwise i won't even consider a review request.

Thomas,
I have just implemeted (compiled and installed) the patch on my gentoo box. And it looks like Alt+Tab works fine on all screens (4 in my case).
Any log files, or configuration files that you would like to view?
Thank you for your work.
Stan Jesmanowicz

(In reply to comment #85)
> And it looks like Alt+Tab works fine on all screens (4 in my case).
Does that mean you run 4 instaces of kglobalacceld (just to make this absolutely sure: we all understood that this is for the zaphod mode, ie display 0.1, 0.2, 0.3 ... not xinerama or xrandr "multiscreen")

> Any log files, or configuration files that you would like to view?
No, actually if you can confirm that this improves the situation on an otherwise more or less reliably occurring issue, that's enough.
So to make that very clear as well: sth. improved, yes?
This was *not* supposed to be a regression test.

FYI:
the patch needs to be tested for regressions against xinerama, since i don't know at hand whether it creates different X screens like the zaphod mode.

I am absolutely sure about: :0.0 :0.1, :0.2, :0.3 ... not xinerama or xrandr "multiscreen" nor twinview.
But I see only one: kdeinit4: kglobalaccel [kdeinit] - not sure what it does ...
I do run 4 instaces of kwin.
Am I missing something?

First of all thanks for Thomas for taking the time to work on our problem.

Second of all I was puzzled too by Thomas' question too. I thought we were talking about multihead, not multiseat! I always thought zaphod mode is the multiseat mode, where you have 2 monitors but also 2 keyboards/mouses. I have never tried the multiseat mode myself but AFAICS from the xorg's point of view there is not much difference but there is a big difference from KDE's point of view so we need to be clear about this.

My "multihead" setup has two monitors on two screens (2 monitor, device and screen sections in xorg.conf). When KDE fires up almost every daemon forks itself (kwin,plasma-desktop) so I have two of them in the process list. Unfortunately kglobalaccel does not, that's another thing that needs to be fixed (note to sjesman: because of this, for example Alt+F2 does not work on :0.1).

Can someone please clarify?

(In reply to comment #82)
> Some of the comments seem to try to convince me of the importance of adding
> this feature. I'm sorry you missed the point. 
and so did you, apparently.
my point is mostly was about you to stop abusing words like "deprecated", "obsolete" and "useless", just on the grounds of you being not interested, and majority of users being unaware of X's multihead options. maybe it's your subjective opinion, but don't try to pull of it as an objective one, especially for actual users of those.
because facts are: it long-time supported by X, it works in recent X, it useful for those who cares about it, and there is no major distro that planned to replace X with pure Wayland anytime soon (you're lucky if you can get its working setup from repos at all).

that way going around and writing, that those features are useless and deprecated (unless, of course, you deliberately would make them unusable on KDE update) is delusional, at best, and misleading, at worst.

don't like word "bullshit" ? ok, let's call it a "disinformation" then.
> Further discussions won't help you because I do know all about it
especially, after you admited yourself, that you were aware about its usefulness and working state while writing about 
> The intention of comment #67 was to explain why nobody from the KDE developer group has worked on it and why it is unlikely that in future somebody will work on it.
a fair point. but it most likely makes KDE more deprecated than X, since various multihead support in X isn't leaving anywhere anytime soon, and neither is X (even when Wayland finally comes, X won't disappear for a looong time. hell, systemd isn't universal default yet, and that's an init system: much easier to replace !).

so, try some modesty and replace "_it's_ deprecated !" with "_we won't_ support it" then any further.

(In reply to comment #87)
> But I see only one: kdeinit4: kglobalaccel [kdeinit] - not sure what it does
> ...
> I do run 4 instaces of kwin.
> Am I missing something?
indeed. it's the same for me with my Zaphod-mode now, only with 2 screens and kwins.
and there is no such thing as 'kglobalaccel_d_'


(In reply to comment #88)
> First of all thanks for Thomas for taking the time to work on our problem.
yep, kudos !
> Can someone please clarify?
sounds like you have Zaphod-mode alright. multiseat is just multiseat: pretty similar but supports several _sessions_ simultaneously, which means several login screens on start-up and manual input device assingment for each session together with screens (and video devices, but i heard that some work was going for quite a while to allow this on the same device).

This is *only* about "multihead".
We define "multiehead" as separated X screens  (0.1, 0.2) for one user session (notably one session bus) without usage of xinerama.

Notable signs:
- only one user is logged in *once*
- there are more than one Hardware display panels
- you can  *not* move windows between (some of) those pyhiscal panels
- you're running n instances of kwin, plasma-desktop, eventually krunner, ideally kglobalacceld, where "n" corresponds to the amount of such independent  screens and can be equal to the amount of physica screens.

I wondered about
(In reply to comment #85)
> And it looks like Alt+Tab works fine on all screens (4 in my case).

Because that would mean there're 4 kglobalaccel instances or some fixing patches to globalaccel, because actually this should not be possible.

Alt+Tab is supposed to work on one (the main) screen.
The patch attempts to fix the loss of the input focus with alt + tab (so that subsequent alt+tab invocations will fail and cause "regular" input of some UTF char on any other screen.

This is what I want confirmed as a reliable improvement.

PS:
can we please stop *all* social junk and pointless discussions about whether this is a sane feature (i personally hated the setup while trying) or sulky attitudes on words and focus on this being a bugtracker, ie. "on topic"?

I have really no intention to read through this no-info crap.
If you want to discuss some unrelated nonsense, do that somewehere else - forum, IRC, blog about it - i don't care.

Facts:
-------
- everyone involved in development considers the zaphod mode uninteresting (that includes myself)
- a bunch of users has a different perception
- this is a bipolar situation that will not converge, no matter what kind of insults anyone attempts.
- there's no fundamental opposition against improving the situation (that includes "no regressions" for the more regular setups) in kwin - just a lack of interest. *Anyone* can provide improving patches, though.

Regarding global shortcuts not working, this is bug 284424.

In case that isn't clear:
I do yet *not* consider the patch confirmed to cause any improvement due to the uncertain statement regarding "alt + tab works on all heads"

It missed Beta1 and w/o confirmation will miss Beta2 and i'm not sure whether it can be added to RC1 - so if you want it to show up in 4.10, better clarify the alt+tab situation before with and without the patch.

I applied Thomas' patch to KDE 4.9.4 (Arch Linux).  Window switching with Alt+Tab works perfectly on the first screen (:0.0).  As long as a window on :0.0 has focus, alt+tab works repeatedly without losing focus.  If a window on :0.0 has focus and I move the mouse onto :0.1, alt+tab still works correctly on :0.0.  If I focus a window on :0.1 and press alt+tab, nothing happens on either screen.  I have one instance of kglobalaccel running.

My setup is three monitors on two GPUs.  Screen :0.0 is a single monitor running on one GPU.  Screen :0.1 is two monitors in twinview.  I have full acceleration on all three monitors.  Twinview doesn't work across two GPUs, and Xinerama has no acceleration and terrible performance.  So multihead with two separate X screens is my best option.  I have come to enjoy the multihead setup.  Keeping the primary monitor as a separate screen makes fullscreen apps behave better, plus I can leave the other two monitors off when I don't need them and use it like a single monitor without worrying about windows opening on the other screens.

Anyway, thanks for the patch.  Alt+tab was basically useless before, and now at least it works on the primary screen, which is where I would use it most anyway.  My two extra screens are mostly used for having documentation or a browser open while I work on the primary screen.  So this is perfect for my use case.

Many thanks for the confirmation.
The perceived behavior is unfortunately expected, since with one global accel daemon, you will not be able to trigger any global shortcut on the other desktop (and two kglobalacceld instances do so far not work)

So i'll try to get the patch into rc2.

I can confirm that Thomas' patch seems to at least fix the alt-tab issue half way for my dual head setup.
2 X screens - :0.0 and :0.1
2 displays / screen (1920x1080, with nVidia TwinView;  proprietary drivers, 313.18)
Arch Linux x64, KDE 4.9.5

Alt-tab now works consistently on primary X screen; no action on secondary screen - this is much better compared to intermittent alt-tab functioning for the primary screen.

*** Bug 314790 has been marked as a duplicate of this bug. ***

*** Bug 314790 has been marked as a duplicate of this bug. ***

Git commit 53294ef164c3af5a08f20ff1f0de1de9bff5e5bd by Thomas Lübking.
Committed on 13/02/2013 at 00:40.
Pushed by luebking into branch 'master'.

improve multihead situation

prevents the focus being passed to the other head
manages OpenGLIsUnsafe setting per head
Related: bug 282677
REVIEW: 107853
FIXED-IN: 4.11

M  +7    -4    kwin/composite.cpp
M  +6    -37   kwin/tabbox/tabbox.cpp
M  +28   -0    kwin/workspace.cpp
M  +1    -0    kwin/workspace.h
M  +15   -0    kwin/xcbutils.h

http://commits.kde.org/kde-workspace/53294ef164c3af5a08f20ff1f0de1de9bff5e5bd

Thomas, thanks for getting a commit merged into master!

I'm running KDE / kwin 4.11.0, so I guess your commit has been applied. Is there any documentation on how KDE can be configured in a multi-head setup?

The Plasma/Multihead page on the community wiki was last updated in May, 2011, so must be out-of-date with respect to your patches (http://community.kde.org/Plasma/Multihead). Other docs I've found are only on distro wikis, blogs or forums, and are mostly dated.

I'm just wondering how and where I should configure KDE to start multiple instances of kwin and kglobalaccel. Should anything else be started on login? My xorg.conf.d files seems to be okay now, so really it's just a matter of getting KDE up & running on all configured X11 Screens.

Is setting `KDE_MULTIHEAD=true` enough? I'm going to try putting that in `~/.xinitrc` now, having just seen the setting mentioned above. I hope it's an env. var., rather than a preprocessor definition..

(In reply to comment #100)
> I'm running KDE / kwin 4.11.0, so I guess your commit has been applied. 
Yes.

> Is there any documentation on how KDE can be configured in a multi-head setup?

As I recently figured:

~/.kde/share/config/kcmdisplayrc
[X11]
disableMultihead=false

This holds when using KDM (while the settings seems to be false by default)

There's also this thread on forum.kde.org about Zaphod mode in general.
http://forum.kde.org/viewtopic.php?f=66&t=12180

> The Plasma/Multihead page on the community wiki was last updated in May,
> 2011, so must be out-of-date with respect to your patches
That patch is absolutely unrelated to setting up a zaphod mode. It only deals with focus passing (esp. the tabbox) and prevents from false positive "compositing is broken" detection when there're two kwin instances.

There's no relation to any user interaction, the patches just hopefully improve the situation when running several kwin instances at once.

> I'm just wondering how and where I should configure KDE to start multiple
> instances of kwin and kglobalaccel.
It's (afaik) still not possible to run two useful kglobalaccel instances (due to the singleton dbus interface requirement)
This implies certain limitations (eg. alt+tab can only be started on one screen)

> Is setting `KDE_MULTIHEAD=true` enough? I'm going to try putting that in
> `~/.xinitrc` now, having just seen the setting mentioned above.
KDE session variables are interpreted from ~/.kde[4]/env - i can't say at hand whether kdm/startkde implicitly invokes ~/.xinitrc (iirc that's a startX thing) or ~/.xprofile

However, if you login via KDM, the preferred way should be the above.

> an env. var., rather than a preprocessor definition..
Yes =)

(In reply to comment #101)
> (In reply to comment #100)
> > Is there any documentation on how KDE can be configured in a multi-head setup?
> 
> As I recently figured:
> 
> ~/.kde/share/config/kcmdisplayrc
> [X11]
> disableMultihead=false
> 
> This holds when using KDM (while the settings seems to be false by default)
> 
> There's also this thread on forum.kde.org about Zaphod mode in general.
> http://forum.kde.org/viewtopic.php?f=66&t=12180

Thanks for the tips! I applied the setting you recommend, skimmed through that thread and with a little help from grep, had a look through some of the kde-workspace sources. But tbh, I haven't noticed any difference in the desktop environment, with or without the disableMultihead setting. In kcminit/main.cpp, it appears that disableMultihead overrides KDE_MULTIHEAD, so thank you for sharing that tip! Still, I've no idea what difference it makes..
 
> > I'm just wondering how and where I should configure KDE to start multiple
> > instances of kwin and kglobalaccel.
>
> It's (afaik) still not possible to run two useful kglobalaccel instances
> (due to the singleton dbus interface requirement)
> This implies certain limitations (eg. alt+tab can only be started on one
> screen)

Fair enough. Well, multiple kwin instances on startup would be good. As mentioned above, `kwin --replace` is a valid workaround, though..
 
> KDE session variables are interpreted from ~/.kde[4]/env - i can't say at
> hand whether kdm/startkde implicitly invokes ~/.xinitrc (iirc that's a
> startX thing) or ~/.xprofile

Yes, sorry. my ~/.xinitrc was left over from when I tried out openbox or something. It contained only the line:

   exec /usr/bin/startkde

I switched over to kdm ages ago now, so the file seems redundant, as removing it makes no difference to kde's startup procedure.

Wish I could help, but I've no experience with any of the related APIs, or the time to hack atm. Thanks again for the swift reply, though!

(In reply to comment #102)
> so thank you for sharing that tip! Still, I've no idea what difference it
> makes..

It's actually supposed to ensure you get plasma-desktop and kwin on each head.

> Fair enough. Well, multiple kwin instances on startup would be good. As
> mentioned above, `kwin --replace` is a valid workaround, though..
I think this is a bug (don't ask me who to blame though)

The environment is set by kcminit (so it will be there for the session) but kwin is (initially) started by ksmserver from /usr/bin/startkde, ie. will never see that variable and despite the default for the config says "use multiscreen" the absence of the enviroment var is interpreted as "false" by KGlobalSettings ...

if you (as workaround) put
export KDE_MULTIHEAD=true

somewhere at the beginning of /usr/bin/startkde, you should get a kwin client on each screen on startup - yes?

https://git.reviewboard.kde.org/r/112579/

It would be cool if you (or anyone with a multihead setup) could try that patch. Thanks.

On 09/07/2013 05:55 PM, Thomas Lübking wrote:
> https://bugs.kde.org/show_bug.cgi?id=256242
>
> --- Comment #104 from Thomas Lübking <thomas.luebking@gmail.com> ---
> https://git.reviewboard.kde.org/r/112579/
>
> It would be cool if you (or anyone with a multihead setup) could try that
> patch. Thanks.
>

With last KDE releases I was adding a line to /usr/bin/startkde like:

  #!/bin/sh
  #
  #  DEFAULT KDE STARTUP SCRIPT ( 4.11.1 )
  #
  export KDE_MULTIHEAD=true

But after learning about from you about directory: ~/kde4/env
I have added executable file multi.sh containing:
  #!/bin/sh
  export KDE_MULTIHEAD=true

And that make the trick cleaner for me.

I would be even better if there was a 'env' directory for all users ...

Regards,
Stan

(In reply to comment #103)
> if you (as workaround) put
> export KDE_MULTIHEAD=true
> 
> somewhere at the beginning of /usr/bin/startkde, you should get a kwin
> client on each screen on startup - yes?

Yes, that works! Thanks!

I tried a couple of things - mutually exclusively - with different results:-

Add `export KDE_MULTIHEAD=true` to the top of /usr/bin/startkde

   - ksplashx works properly.
   - kwin runs on both screens.

Add `disableMultihead=false` to ~/.kde4/share/config/kcmdisplayrc

  - ksplashx doesn't work on 2nd screen. It stops after the first icon appears.
  - kwin doesn't run on 2nd screen. (confirmed by running `DISPLAY=:0.1 dolphin`)

I did also add `export KDE_MULTIHEAD=true` to an executable shell script in ~/.kde4/env/ last night, but unlike Stan, it didn't seem to make a difference. I considered adding it to /etc/environment, which would be global, but figured this should be configurable within KDE's settings, rather than a Linux-specific global file...

I'll try your patch out now; shouldn't take long. I'll report back soon.

KR,
Alex

(In reply to comment #104)
> https://git.reviewboard.kde.org/r/112579/
> 
> It would be cool if you (or anyone with a multihead setup) could try that
> patch. Thanks.

Yea, your patch seems to do the trick! :)

I've reset all config files to their previous states (i.e. deleted disableMultihead=false and startkde is as distributed), and kwin is indeed running on both monitors. However, kglobalaccel doesn't seem to be working; Alt+tab doesn't work at all.

I've noticed a couple things from within konsole, on DISPLAY :0.0

$ env | grep -i multihead
KDE_MULTIHEAD=true

I believe this is now set by your patch, as it's definitely not set in any of my config files..

I've also been inspecting `pstree -a` output, within sessions too. When kwin is running properly in multihead, it is lacking an argument: `-display :0.0`. That's about the only difference I've noticed, but with your patch, I think kglobalaccel might be missing some arguments...

For reference (before I revert the patched build, log out and back in etc.), below are relevant launch commands, from `pstree -a`. 

systemd
  |-kded4
  |   `-3*[{kded4}]
  |-kdeinit4
  |   |-klauncher
  |   |-konqueror
  |   |-ksmserver
  |   |   |-kwin -session XXXX_XXX_XX
  |   |   |   |-kwin -session XXXX_XXX_XX
  |   |   |   |   `-2*[{kwin}]
  |   |   |   `-2*[{kwin}]
  |   |   `-{ksmserver}
  |-kdm -nodaemon
  |   |-X :0 vt7 -nolisten tcp -auth /var/run/xauth/A:0-WkwHSb
  |   `-kdm
  |       `-startkde /usr/bin/startkde
  |           `-kwrapper4 ksmserver
  |-kglobalaccel
  |-plasma-desktop
  |   `-2*[{plasma-desktop}]
  |-plasma-desktop
  |-start_kdeinit +kcminit_startup

(In reply to comment #105)
> I would be even better if there was a 'env' directory for all users ...
try /etc/kde/env

(In reply to comment #106)
> I did also add `export KDE_MULTIHEAD=true` to an executable shell script in
> ~/.kde4/env/ last night

might be ~/.kde4/env/

(In reply to comment #107)
> Yea, your patch seems to do the trick! :)
good.
 
> However, kglobalaccel doesn't seem to be working;
> Alt+tab doesn't work at all.
kdeglobal as for now cannot usably run twice. One instance should however come up as usual and trigger alt+tab on _one_ screen (and do nothing on the other - tabbing there would work, but you won't get into it because of the global shortcut not being interpreted due to lacking kglobalaccel instance)

> $ env | grep -i multihead
> KDE_MULTIHEAD=true
> 
> I believe this is now set by your patch
No, but as mentioned, this actually should be the default (because disableMultihead defaults to false)

> :0.0`. That's about the only difference I've noticed, but with your patch, I
> think kglobalaccel might be missing some arguments...
Tha patch has not the least effect on kglobalaccel - it's running completely independent and is the major hinder for usable multihead support - see bug #284424 and comment #54 here.

So, I've been playing with these settings and that patch. I was getting messed around with saved session settings in `~/.kde4/share/config/ksmserverrc`, so I've started deleting that file in between sessions before testing the various configurations... 

So the patch is good at setting `KDE_MULTIHEAD=true` globally, but, whether with the patch or without, alt+tab just doesn't work at all when KDE_MULTIHEAD=true, as set either by the patch, in /usr/bin/startkde, or an executable script in ~/.kde4/env/.

The best compromise I've found is to launch kwin on the second screen manually; either with `kwin --replace`, or with `DISPLAY=:0.1 kwin`. This maintains alt+tab behaviour only in the first screen (:0.0), but that's much better than not being able to switch applications at all. I guess this has nothing to do with kglobalaccel, as other shortcuts do work, such as launching krunner... Strange, but I'll have to live with it; I've spent far too much time playing with this second display already.

Thanks for all the help, Thomas!

Created attachment 82209 [details]
Debug out when comparing heads

(In reply to comment #110)
> with the patch or without, alt+tab just doesn't work at all when
> KDE_MULTIHEAD=true

That sounds as if the "isOnCurrentHead" check would contantly fail - the attached patch will tell why.

> maintains alt+tab behaviour only in the first screen (:0.0), but that's much
> better than not being able to switch applications at all. I guess this has
> nothing to do with kglobalaccel, as other shortcuts do work, such as

Works on only one desktop -> known kglobalaccel limitation
Works not at all -> unknown reason, but probably in kwin, yes.

Created attachment 82218 [details]
Patch for kwin/xcb_util.h

Okay, I just did some digging and debugging, and found a fix for Alt+tab not working at all when in multiscreen mode. The problem seems to stem from the default constructor of the Wrapper template, in kwin/xcb_utils.h. It forced the local cookie's sequence value to 0, and may not have been properly constructed (I'm not that experienced with template syntax, or any of the APIs in use here, really).

I found a patch, which may have introduced this issue, at: https://git.reviewboard.kde.org/r/107853/diff/2-3/?expand=1

Note that in the linked diff (107853), the original code only had one constructor, where its `window` argument was optional:

    explicit Wrapper(Window window = None) {
        m_cookie = requestFunc(connection(), window);

The attached patch ensures that this is still run, and leaves `m_cookie.sequence` alone.

Thanks for your last patch btw, Thomas! Without it, I never would have been able to trace this.. Briefly, when in multihead mode, I always got the "HEAD CHECK: NO WINDOW ACTIVE" message in ~/.xsession-errors.

(In reply to comment #112)

> I found a patch, which may have introduced this issue, at:
> https://git.reviewboard.kde.org/r/107853/diff/2-3/?expand=1
> 

Sorry, this patch didn't introduce the issue, but helped me fix it nonetheless.. Don't want to give blame where it's not due!

Comment on attachment 82218 [details]
Patch for kwin/xcb_util.h

It probably makes sense to remove the default constructor, and give the explicit one a default argument of XCB_WINDOW_NONE. Reduces the size of a debug build by 0.01MB, too! Woop!

>diff -u ./kwin/xcbutils.h{.orig,}
--- ./kwin/xcbutils.h.orig      2013-09-08 12:31:44.219920756 +0100
+++ ./kwin/xcbutils.h   2013-09-08 13:06:01.685478991 +0100
@@ -49,14 +49,7 @@
 class Wrapper
 {
 public:
-    Wrapper()
-        : m_retrieved(false)
-        , m_window(XCB_WINDOW_NONE)
-        , m_reply(NULL)
-        {
-            m_cookie.sequence = 0;
-        }
-    explicit Wrapper(WindowId window)
+    explicit Wrapper(WindowId window = XCB_WINDOW_NONE)
         : m_retrieved(false)
         , m_cookie(requestFunc(connection(), window))
         , m_window(window)

Nice catch, the bug is however in commit 53294ef1 (which i introduced later than commit dbdb9f2f, introducing the different constructor)

Given the patch history on reviewboard this is just an unfortunate conflict resolution - i added and tested the CurrentInput class, then Martin changed the constructor, i fixed the merge conflicts but proably didn't retest multihead et voilá.

The patch is however "wrong", the default constructor should not trigger a request.

Please try instead:

diff --git a/kwin/xcbutils.h b/kwin/xcbutils.h
index 1a4befd..fca15f8 100644
--- a/kwin/xcbutils.h
+++ b/kwin/xcbutils.h
@@ -197,7 +197,7 @@ inline xcb_get_input_focus_cookie_t get_input_focus(xcb_connection_t *c, xcb_win
 class CurrentInput : public Wrapper<xcb_get_input_focus_reply_t, xcb_get_input_focus_cookie_t, &xcb_get_input_focus_reply, &get_input_focus>
 {
 public:
-    CurrentInput() : Wrapper<xcb_get_input_focus_reply_t, xcb_get_input_focus_cookie_t, &xcb_get_input_focus_reply, &get_input_focus>() {}
+    CurrentInput() : Wrapper<xcb_get_input_focus_reply_t, xcb_get_input_focus_cookie_t, &xcb_get_input_focus_reply, &get_input_focus>(XCB_WINDOW_NONE) {}
 
     inline xcb_window_t window() {
         if (isNull())

(In reply to comment #115)

> Please try instead:
> 
> ...

Sorry about the slow reply; I was trying to figure out why focus always swaps to the second screen after closing a window, but no luck. The patch is good, however. Alt+tab works fine on the first screen now.

Cheers,
Alex

(In reply to comment #116)

> Sorry about the slow reply; I was trying to figure out why focus always
> swaps to the second screen after closing a window, but no luck.
Focus policy? (click, follows mouse, etc.)

I assume there're other activatable windows on the first head?

if you want to look it up: activation.cpp / ::activateNextClient() is likely the cause here.

If you reach this block:

    if (get_focus == NULL)   // last chance: focus the desktop
        get_focus = findDesktop(true, desktop);

    if (get_focus != NULL)
        requestFocus(get_focus);
    else
        focusToNull();

I'd say there's a good chance for failure (KWin finds the "wrong" desktop window)

> The patch is good, however.
Thanks for the update.

(In reply to comment #117)
> I assume there're other activatable windows on the first head?

Yes. Focus shifts to the second screen regardless of which was the last activated window. If there's no window on the second screen, focus still shifts over to it. I've got the "Search & Launch" desktop style on it, and the cursor focuses on to the desktop's icons if there's no window active, otherwise it focuses on the top window.

> 
> if you want to look it up: activation.cpp / ::activateNextClient() is likely
> the cause here.
> 
> If you reach this block:
> 
>     if (get_focus == NULL)   // last chance: focus the desktop
>         get_focus = findDesktop(true, desktop);
> 
>     if (get_focus != NULL)
>         requestFocus(get_focus);
>     else
>         focusToNull();
> 
> I'd say there's a good chance for failure (KWin finds the "wrong" desktop
> window)

I added a few printf / `kDebug` statements just before that block, and that block is indeed reached each time I close a window. The value for `get_focus`, which is not NULL, is retrieved from the block:

        } else {
            // nope, ask the focus chain for the next candidate
            get_focus = FocusChain::self()->nextForDesktop(c, desktop);

Immediately after that line, I added:

            printf("get_focus (%p) got from nextForDesktop(). c = %p, desktop = %i \n", get_focus, c, desktop);

with the result:

get_focus (0x15e3d70) got from nextForDesktop(). c = 0x12a2ec0, desktop = 1

(In reply to comment #118)

> I added a few printf / `kDebug` statements just before that block, and that
> block is indeed reached each time I close a window. The value for
> `get_focus`, which is not NULL, is retrieved from the block:

Err, ok - sorry. I actually meant "reached with unresolved get_focus", so this (focus wrong desktop) is not it.

Can you check with

qDebug() << "next focus" << c "->" << get_focus;

and check whether this is printed from both kwin instances when you close a window on one (and on screen 2 after screen 1, while that's a minor question) or you get values for "c" or "get_focus" that actually belong to the other screen  (or even segfaults on qDebug())?

(In reply to comment #119)

> Can you check with
> 
> qDebug() << "next focus" << c "->" << get_focus;
> 
> and check whether this is printed from both kwin instances when you close a
> window on one (and on screen 2 after screen 1, while that's a minor
> question) or you get values for "c" or "get_focus" that actually belong to
> the other screen  (or even segfaults on qDebug())?


On Screen 1:
 - 3 windows opened: web browser, then konsole, then dolphin.
 - screen 2 is empty, with just the search and launch activity, running on kwin
 - close dolphin.
 - output from konsole (where `kwin --replace` had been run) :

next focus 'ID: 56623128 ;WMCLASS: "dolphin" : "dolphin" ;Caption: "albl500 – Dolphin" ' -> 'ID: 8388630 ;WMCLASS: "konsole" : "konsole" ;Caption: "albl500 : bash – Konsole" '

 - The printed result seems to show what should happen, but focus switched to opposite screen.

On screen 2:
 - Open 2 windows: konsole, then dolphin
 - close dolphin.
 - output from shell running `kwin --replace` (on screen 1): 

next focus 'ID: 81788952 ;WMCLASS: "dolphin" : "dolphin" ;Caption: "albl500 – Dolphin" ' -> 'ID: 75497500 ;WMCLASS: "konsole" : "konsole" ;Caption: "albl500 : tail – Konsole" '

 - Again, the result in the console shows the window which should be focused, but the window which is actually raised is on the opposite screen (konsole, which was running on top of any other).

Adding a similar statement to takeActivity shows that it's being callled from a few other places in the code:-

kwin(17356) KWin::Workspace::takeActivity: takeActivity 'ID: 18874392 ;WMCLASS: "dolphin" : "dolphin" ;Caption: "albl500 – Dolphin" ' flags 1
kwin(17357) KWin::Workspace::takeActivity: takeActivity 'ID: 33554537 ;WMCLASS: "plasma" : "plasma" ;Caption: "plasma-desktop" ' flags 3
next focus 'ID: 18874392 ;WMCLASS: "dolphin" : "dolphin" ;Caption: "albl500 – Dolphin" ' -> 'ID: 8388630 ;WMCLASS: "konsole" : "konsole" ;Caption: "kde-workspace-4.11.1 : kwin – Konsole" ' 
kwin(17356) KWin::Workspace::takeActivity: takeActivity 'ID: 8388630 ;WMCLASS: "konsole" : "konsole" ;Caption: "kde-workspace-4.11.1 : kwin – Konsole" ' flags 1


This was generated from closing a dolphin window, and expecting to return to konsole (both on screen 1). Instead focus switches over to the empty plasma-desktop on screen 2.

Git commit 2ac4a7a083dceecccb863bad72a7a4c05d54fd21 by Thomas Lübking.
Committed on 08/09/2013 at 20:56.
Pushed by luebking into branch 'KDE/4.11'.

fix xcb CurrentInput implementation

broke on interim Wrapper() constructor change

The Constructor needs to explicitly pass
XCB_WINDOW_NONE to the inherited Constructor to
trigger a request

Thanks to Alex Leach for finding this
FIXED-IN: 4.11.2
REVIEW: 112595

M  +1    -1    kwin/xcbutils.h

http://commits.kde.org/kde-workspace/2ac4a7a083dceecccb863bad72a7a4c05d54fd21

Git commit 9121fe4948eba6ab3932134b1f64e7ff067d059b by Martin Gräßlin, on behalf of Thomas Lübking.
Committed on 07/09/2013 at 15:38.
Pushed by graesslin into branch 'KDE/4.11'.

Revert "Add ability to disable multihead support"

The variable is set not from config nor anywhere else when kwin is
started through ksmserver by startkde.

In addition the KGlobal implementation is twisted compared to the kcminit
config behavior (the config value defaults to true, not false - ie. if the
variable isn't set (by kcm init) it's reasonable to assume true either.

Therefore and in alignment with PW/2, the environment is read directly and
on absence resolved to "true".

To control the behavior, please export KDE_MULTIHEAD=true/false before starting KWin
(eg. in /usr/bin/startkde)

This reverts commit ab6d5c048a25bcb2f5bdb822ba3eda64019c61bc.

REVIEW: 112579

M  +10   -2    kwin/main.cpp

http://commits.kde.org/kde-workspace/9121fe4948eba6ab3932134b1f64e7ff067d059b

*** Bug 227887 has been marked as a duplicate of this bug. ***

Last dupe rather focussing on plasmashell? (it's really hard to say when users talk to "the KDE")

KWin (kwin_x11) should start upon both screens etc. - otherwise there're mostly remaining issues with kglobalaccel (due to dbus restrictions), ie. global shortcuts only working on one head.

(In reply to Thomas Lübking from comment #125)
> Last dupe rather focussing on plasmashell? 

I have tested _both_ : latest KDE-4 and current PLASMA-5, on Gentoo.

> KWin (kwin_x11) should start upon both screens etc. - otherwise there're
> mostly remaining issues with kglobalaccel (due to dbus restrictions), ie.
> global shortcuts only working on one head.

Sorry:     "and more ..."

I also disdain the flamewars above.

FACT:

After KDE-3,
KDE-4 and onwards including QT-5-based PLASMA-5
do not support any setup 
to reliably deal with a _diverse_ combination of
+ multiple _different_ HW Graphics Adapters, each having connected
+ multiple _different_ HW Monitors (esp. with different screen resolutions)

FACT:

KDE developers state they are not going to resolve this matter
(yet) (and hope for Wayland) 
which is a perfectly justifiable decision.
And I am really grateful for stating this very clearly.

Everybody has the right to freely choose what he wants to work upon.
Nobody has the right to blame anybody else for not working on <XYZ> -
but himself.

FACT:

X window Managers do support this basic need since the "very olden days" :
+ twm, ctwm
+ FVWM
+ Fluxbox
(just to name a few).

Or, examplum gratia, a GTK+-based Alternative:
+ XFCE
(just to name one with more "comfort" and "fancy").

All of them support running (GNOME, ... and) KDE _applications_ .

FACT:

It's not _that_ difficult to adapt 
an extended example of /etc/X11/xorg.conv.d 
(c.f. Attachment below).

_RESUMEE:_

It's up to every individual to make up his _choice_  :-)

Isn't that what Free and Open Source is all about ?     ;-)

Created attachment 94774 [details]
/etc/X11/xorg.conf.d example

Exploiting Intel + nvidia / nouveau Graphics Cards
Layout with One or Multiple different Monitors (up to five)

FACT:
this is about the kwin process while your bug seemed to focus on the plasmashell process

FACT:
KDE version doesn't matter - the desktop is a different process than the windowmanager

FACT:
you've not provided a single bit of information to answer that question or specify your particular problems about *what* doesn't work (either doesn't start or is disfunctional in which way)

RESUME:
choose for yourself.

@Manfred: please calm down, this isn't helpful. Multi-head support is unfortunately a rather uncommon feature which even had been broken on some hardware in the X server for a long time, requiring e.g. multiple GPUs to get it working at all. This is not a setup all developers have (I for example do not have multiple GPUs installed), thus it is just very hard to actually test it.

Like with so many other projects it's a simple question of whether there are resources available for it. Apparently there were no resources available, and that's just fine. It's free software. Anyone can pick it up and develop on it. Anyone can hire devs to work on it. Anyone is free to use other software which supports the rare usecase better.

@Thomas,  @Martin:       I'm simply _aghast_.

My intention was to _calm_ 
by acknowledging KDE's developer's work & decision    and
by providing provenly working alternatives to those in need (--> c.f. my attachment).

I don't care about "components" or "versions", 
only about solutions to a requested legitimate need for some people.

I have choosen a long time ago,
but wanted to give the KDE ecosystem another try on my workstation.

I resist tempts to fight 
and say "bye" to this boiling cauldron. 
All the best.

So, after some on-topic information jam, a sum-up of the status quo for everybody else.
-----------------------------

One doesn't necessarily require two GPUs (really depends on how broken the drivers are ;-), but even with two GPUs one can still have xinerama.

That aside, the limiting factor here is dbus, which is head agnostic - and largely used all over KDE.
So you've to circumvent it in various places (or lack features as with kglobalaccel right now)

That aside as well, the situation in notably kwin should have quite improved with 4.11 and up (compared to earlier 4.x versions)

Please notice:
--------------------
*This* bug is on the window manager kwin.

If you have remaining problems with kwin, please state them.
If we can (see dbus limitation) improve the situation w/o causing regressions for the regular setup, there's a good chance we will (not on top priority, but still)

If not (like "process foo or bar which is not kwin doesn't start on all heads or has limited features"), please state your problems somewhere else - it's pointless here.


On bug reporting in general:
----------------------------
If you 'don't care about "components" or "versions"' you're just wasting your and our time (and likely don't care at all because you're only here to rant around)
Bugs don't fix magically, they don't fix in released versions or other components than you reported them to either.

Should we close this old bug, given that X11 is legacy and unlikely to receive new features? If anything remains to be done, it should be targeted at Wayland.

Feel free to reopen in case someone is actually planning to improve multiscreen support in kwin_x11.