Bug 156475

This is a "must have" for me, without it the second screen is going to be unmanageable in my own work setup.

Is this just a case of having to allow two instances, or is there some deeper juju in the code that would need changing to allow them to cooperate?

Could you not just use the MergedFB or the new XRandR support in the free radeon driver, so you get a large single framebuffer, and a single plasma process can manage them both.

Nope. Two separate cards, for one thing.

two cards doesn't mean you can't use the new xrandr or the mergedfb support. In fact thats how you did this stuff in times when one graphics cards couldn't work with more than 1 monitor.

The only thing that could be done is starting plasma with
DISPLAY=:0.1 plasma <appletrc>
as the two X11 screen's are completely unrelated and thus you can't have one plasma instance working on both.

Actually ... two cards *does* mean I can't use "MergedFB" support
since that option is explicitly for combining scanout buffers on a
single head, in the radeon driver. The XRandR stuff is nice, but it
looks as though I still can't use DRI with it; and the current git
Xorg server appears to be unable to POST secondary cards too, so I'm
screwed on two counts.

As for "unrelated and thus you can't ..." ... how come most window
managers manage to work just fine with multiple screens?

Also, why can't the second instance of plasma be started
automatically? It works just fine for kicker, kdesktop etc in kde
3.5.x (I'm using it now; panel on both screens, and so on).

The reason that most WM's (including kwin, which is KDE's window manager) work just fine with two screen's is that both screen's get their own WM. Thats why you can't move windows from one of the screens to the other.

As far as plasma is concerned: I have no idea why it doesn't automatically start up on the second screen. I suspect that the code that does this in kde3 is simply not there yet in plasma. Thats why this bugreport is valid and still open ;)

You can't move the windows because the windows are created attached to
a particular screen (I believe they also have a per-protocol-screen
namespace). So this is actually an X11 limitation, not a WM one.

> As far as plasma is concerned: I have no idea why it doesn't automatically start up on the second screen. I suspect that the code that does this in kde3 is simply not there yet in plasma. Thats why this bugreport is valid and still open ;)


Heh :o)

Yeah, it could probably be done fairly easily. I just had high hopes
that as there "can be only one" etc we'd see plasma manage both
screens. I notice kwin in kde3 is using two processes; surprised, at
that's not in any way required by X.

Anyway, thanks for taking an interest. This is a bit of a show-stopper
for me to upgrade to kde4 at work (as is what appear to be some X
server limitations, so not just kde4 :o)) so I'm pleased to see some
kind of response on this one.

> Nope. Two separate cards, for one thing. 

Then you're stuck with Xinerama. Which you might prefer anyhow. You can move windows back and forth between cards now.

> why can't the second instance of plasma be started
> automatically? It works just fine for kicker, kdesktop etc in kde
> 3.5.x (I'm using it now; panel on both screens, and so on). 

starting it is easy; making it not use the same configuration files, etc and end up clobbering each other is not so much fun.

lubos and i discussed this a few weeks back on kde-core-devel; i would prefer not to do what we did in kde3 since it leads to various interesting hacks that just aren't very pretty.

it's on my todo for 4.2/4.3 unless someone beats me to it, in any case.

there were numerous bugs in kicker w/regards to dual head as well, btw. i dunno, xinerama/mergedfb/twinview just seem so much more natural. back in the day when you couldn't do accel video or opengl on some of these setups dual head sort of made sense.

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

Hello again.

I've been doing some trying and thinking since my first request.

Since I wrote the initial bug report/request, I've gotten a new machine with a dual headed Radeon HD3850.

From lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3850

I've managed to set this up in tow different ways:
1. Two different X displays with different resolutions and DISPLAY variables :0.0 and :0.1
2. Big screen. Both monitors behaves as one big screen.

The advantage of 1 is that I can separate content very well. Having two different resolutions is no problem. I can run maximised video on one monitor without disturbing the other monitor. One disadvantage is that it seems some types of acceleration doesn't work properly. For example scrolling the window on firefox is dead slow. (This might of course be the result of improper Xorg.conf setup) Another disadvantage is that windows cannot be moved from one screen to the other. And applications that checks if it is already running cannot be started again on the other monitor.

The advantage of 2 is that all acceleration seems to be working on both monitors. And windows can be freely moved from one screen to the other. The disadvantage is it doesn't work too well with monitors with different resolutions (for example monitor + video projector, here setup one is ideal), maximizing a window makes it cover both monitors, the taskbar covers both monitors, virtual screen changes both monitors at the same time and so forth.

So I have a couple of requests/wishes:
For setup 1:
Different kdm processes for both monitors. For example making it possible to have two different users logged in at the same time. Or maybe one monitor with kdm and the other with a different window manager. I think this would be very useful in some situations, like using a video canon.

I can see the problem here with shared config files if the same user logs in twice. But since this is possbile with XDMCP already, this situation should be handled by KDE anyway.

For setup 2:
I'd like to be able to have separate taskbars and separate virtual desktops for the monitors, so that I can change virtual desktop on one monitor withouth the other changing as well. This also would mean shorter distance to the start button. This should of course be configurable, since many people would probably like to have one common taskbar covering two monitors like today. And maximising a window should only maximize it on the current monitor, with an option to further make it cover both monitors.

Then of course there is Xinerama, which I have to admit I haven't really tried yet. This is because I have limited time to experience with this at work (also I have to reboot every time I change Xorg.xonf, since just simply restarting X  causes my machine to lock up), where I have my dual head HD3850 and the option of two monitors. And from what I read Xinerama is just mimicking setup 2 above, but with some added limitations. 

A dual monitor setup is really usefull, so I hope you hardworking KDE guys will take the time to make this as flexible as possible.

I recently tried out again and a lot of issue are sorted out for me. I can for example add another taskbar on the second screen and this setting is saved as well when logging out and in again. (However often it was not restored 100% correct).


So could you please try this out again using an svn or beta version of 4.2 and tell whats not working?

Hello.

Using 4.1.2 I've recently had decent success. I was able to work with two equal sized monitors, accelleration on both, and different taskbars on both. Great!

I've used monitors with two different resolution, a different Xorg setup and almost the same result. Only difference is I lost acceleration on screen 2. Probably nothing KDE can solve?

At the moment, however, I unfortunately can't do any more testing since after a kernel upgrade (including now using dbus/hal and upgradeing Xorg) KDE doesn't work any more. When plasma is running, I get reports of "kded4: Fatal IO error: client killed" and X is reset as soon as I press for example the menu, or right mouse button. (Happens with both radeonhd driver and fglrx driver, so I suspect dbus/hal or maybe latest Xorg.) So for now I'm using Xfce, which seems fine.

Se also: http://forums.gentoo.org/viewtopic-t-722636.html and 
http://forums.gentoo.org/viewtopic-t-722414.html


http://forums.gentoo.org/viewtopic-t-722636.html

@Atle

Your problems are not related to this bug. However I'll help you at forums :)

I think you'll be happy when kde 4.2 comes out, regarding the dualhead things.

Maybe you can report back if you are able to install a 4.2 version of kde.

Yes, I know. I wasn't trying to hijack this bug report, but it was what was on my mind at the time of writing so it just came out. :)

Things were starting to look good with 4.1.2, and I'm looking forward to test 4.2. I don't have two monitors here, but I will start testing this again in january and as soon as it shows up in portage.

I am running kde4.2.0, and Multihead (separate xsessions) does not work.  Second screen is black.  I can only see mouse pointer move on second screen.  This bug makes KDE 4.2.0 unusable on 2 of my 3 systems.  If there is something I can do to help fix this, I'd be happy to, if there is any kind of documentation I can review to try to understand how this all fits together, but surely there's somebody out there that already has a much greater understanding than myself!

Hi Eric,

It sounds to me your screens are set up so that one screen has adress :0.0 and the other :0.1
Try this from a command line:
export DISPLAY=:0.1
xterm

If I am right, this should open up an xterm on the other screen.

I've tried this sollution before on two different sized screen, and I only had hardware acceleration on one of them.

I'm not sure what will work, but you could also try starting plasma, kicker (from kde 3), another window manager (like twm, for testing) etc.

With this setup, you cannot move a window from one screen to the other. And I suspect you will only have hardware acceleration on one screen at a time.

Another think you can do is look into xinerama. With xinerama you can move windows from one screen to the other, and have plasma with separate taskbars on both screen. It worked quite well on later versions of KDE 4.1 when I was borrowing an extra 24 inch monitor, so that I had to equal sized monitors.

I will, when I have time, test these things more extensively myself and report back here. (I'm using my job computer for all these things, and work unfortunately comes first)

Atle

I have 3 monitors on my computer:
:0.0, :0.1 and :0.2 without xinerama and I can not move windows between my screens.
I have hardware acceleration on all 3 screens.

I have tried both starting more than one plasma (it doesn't want to start more than one instance) and using kicker from kde3.

For me, this is the one thing that makes me unable to use kde4.

I have also tried xinerama but it doesn't work so well for me, no hardware acceleration on all displays for instance.

@Aaron J. Seigo:
You wrote "it's on my todo for 4.2/4.3 unless someone beats me to it, in any case."
How is it going?

> xinerama/mergedfb/twinview just seem so much more natural

In my case I have a monitor and a TV (old-fashioned TV with tv-out -> scart). I tried to use xinerama in the past but then apps would start on the tv when I didn't want them too, Superkaramba themes, yakuake and other things would be very confused and oddly positioned. With the two separate desktops/screens/displays it'd work beautifully the way I wanted in KDE >=3.5.7.

With KDE 4.2 I get a black screen on the tv, with a mouse cursor. If I start apps on the tv with 'DISPLAY=:0.1 kaffeine' they'll appear, but without a window manager.

This xorg setup works fine with GNOME and Xfce, but naturally using either of those desktops is not an option.

I don't really care about being able to have special widgets or configuration files on the second display or other such fancyness, if I could just get a plasma desktop with default configuration and some window management on my TV I'd be more than happy ;-)

IMHO being able to run different instances of plasma on different X sessions is absolutely mandatory until the xinerama stuff works properly.

Admittedly I haven't tried xinerama for some time but my main pet peeves were:

1. windows get openend on the wrong screen (they should open on the screen on which the open command is triggered if there isn't some other behavior defined in kwin)

2. windows get openend on the turned of screen (isn't it somehow possible to autosense if a screen is turned off - e.g. via the new randr stuff?)

3. windows get opened in the middle of the two screens (with 50% of the window on each screen)

4. windows get maximized over both screens (arguably that might be the desired thing for some, so it should be somehow configurable per application)

So, for sure xinerama might be the more natural / preferred thing for most usecases but until stuff like the above is solved I would simply like to run 2 different instances of plasma within 2 seperate X session. Also there are several other usecases, like Martins above, where seperate X sessions would be preferred so it should be supported as well.

Please add that for 4.3 because being unable to use my 2nd screen is not really an option (also the setup works perfectly fine with KDE3) ;D

I am also a believer that dual head should work fine.  I am  a teacher and use my external monitor for my smartboard display.  I send the external signal to a splitter which sends to smartboard and  monitor.  I have tried xinerama (extended desktop) but it fails... My laptop is set to 1900x1280 and my external max is 1280x1024.

I am able to get dual head working if I 'DISPLAY=":0.1" icewm --replace' then my external gets icewm on it.  Not very attractive.

I tried sending kwin to same monitor but it wont work neither will fluxbox.

If I login using fluxbox, dual  head works fine.

If I log in using Gnome, some apps will not open on secondary display.  they crash and render the computer useless until restart.

I really want dual head support so I can have this awesome new KDE on both screens.  I was using it fine with kde 3.5

I am currently using 4.2.1 with an nVidia 9800M GT.

I can confirm this bug in kde 4.2.2

Are there any news on solving this problem?

#10 Aaron J. Seigo: Are it still on yours todo for 4.3 or shall we hope that another developer fix this bug?

I think (not sure) that bug #164242 is related to this

FYI: I filled bug 193390 to ask for Xinerama autodetecting if the 2nd screen is currently turned on and then to accordingly extend the desktop across the 2nd screen or not - obviously it should also get notified if that state changes.

Since that would remove the main blocker for me since my 2nd screen isn't always on and I was told that it would be far less work to implement it's probably more likely to happen so you might want to CC yourself there as well.

This bug have soon 1 1/2 year bithday. Hurra hura

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

Semms like the devs do not care about getting this fixed and therefore I would like to know if there is anything I can help with to selve this problem?

I know the basic java and c++ (with no 3th party library) and I am sitting on a Debian Lenny box with limit access to KDE 4 libs (and I am inteting to stay here to this bug is fixed or I am forced to upgrade to Squeeze). I do not know anything about how to program against X.org or plasma.

@Jonas: "Semms like the devs do not care about getting this fixed"

it's not quite like that.

"and therefore I would like to know if there is anything I can help with to selve this problem?"

sure; you can write a patch that implements dual-head support.

the relevant code is in kdebase/workspace/plasma/shells/desktop/. in a dual head env, there will be two instances of plasma-desktop running, and so we will need two plasma-desktoprc and plasma-desktop-appetsrc files in that case.

the patch will need to:

* detect when it's running in a dual head set up; you can see an example of this here: http://websvn.kde.org/branches/KDE/3.5/kdebase/kicker/kicker/core/main.cpp?view=markup  .. 

* adjust the main KComponentData so that the config file names get generated properly.

the rest should "just work" now that global options are split out into plasmarc in 4.3.

I upgraded to Kubuntu 9.04 and KDE 4.2 and everything seems to be working to my satisfaction using twinview.  I have separate backgrounds on each desktop an separate panels on each with separate task managers and K menu's.  Not sure what fixed it, but I am glad.

#30
I have been looking at http://websvn.kde.org/branches/KDE/3.5/kdebase/kicker/kicker/core/main.cpp?view=markup 
and have some problem understanding som part of it. I start getting a bid confused around fork()
I can guess that fork proberbly is something simelar to:
#include <process.h>
int _beginthread(register void ( *start_address)(void *), void *stack_bottom,   unsigned stack_size,   void *arglist ); 
but I have problems finding info about fork on google (becouse of the name)

You talk about KComponentData but I can not find it under 
http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/shells/desktop/
so I guess that is not there the info about those config file names are generated.

It sounds easy to fix: find out if there is more than one screen (something semelar to the link (but first I have to understand it), start one plasma-desktop, need two plasma-desktoprc and plasma-desktop-appetsrc (need to find the right place in http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/shells/desktop/ . And there is a lot of code.)
Make sure that some config files name is generated proberbly (whitch means exacly???)
Looks like am a bid noobish to "just do it right now)

And the "Semms like the devs do not care about getting this fixed" proberbly sounds harder than I ment it, Sorry for that

where are the problem with KComponentData? In whitch file? And what is "config file names get generated properly."?

My skill within programing is not good enough to write the patch. Anything else I can do?

voting for Dualview/Dualhead too...

the arguments for Dualview/Dualheay instead of xinerama/Twinview are discussed enough above - for me, with my 1920x1200 Notebook-TFT and an separate CRT Monitor for gaming, colorprove - is Dualview HIGHLY important... and a killer argument contra to KDE4 - so i would switch back to KDE 3.5 or moving to Gnome... :-/

#35 I have already made the switch back to kde 3.5. And will stay here to the next version of Debian comes out. If KDE 4 by then have Dualview/Dualheay  I will switch to it. If no one have implemented by then I will have too look for another DE.

this is a bug in a kubuntu patch:

http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/annotate/head%3A/debian/patches/kubuntu_71_default_plasma_layout.diff

if you don't have the folderview plugin (e.g. you haven't installed kdebase-apps) it will crash. this is not in the upstream sources, however. i just talked with Riddel about the issue on irc and gave him some tips on how to improve the patch.

cheers, everyone.

Aaron, please check which bug number you wanted to close. Reopening this one, unless you provide a WebSVN link ;)

whoops, yes, wrong tab in the browser. see my blog from today to see why i was looking at this one. ;)

aseigo now apparently started working on this but is looking for people to test it, which means you have to run trunk & build it yourself.

Please see http://aseigo.blogspot.com/2009/07/multihead.html for details and give him a hand if you are able to do so.

Is there a live CD with trunk so I can test it without scruing my current system?

you can test by installing to a different prefix. this is explained on techbase in the getting started area. you really don't want to be downloading 100s of MBs to retest things and having to wait a day or more between test cycles is not overly helpful.

a from-trunk build of plasma is what is needed. it's the only sane way to be able to test things as they occur.

just got the first testing results back: apparently it works. :) it will be in KDE 4.4; i'm not going to backport it just yet, i don't think, because 4.3.0 is so near at this point and i want to make sure it gets proper testing over the next few months before unleashing it into the wild.

if it appears solid in svn testing, i might backport it for 4.3.2.

in any case ... happy trails :)

I tried this but for me it does not work; I see only a single screen being filled; the other one stays black (but is initialized; I can get an xclock running there).

I added some printf()'s in the new code and it does go there (what's with the environment variable though?); I displayed the screen count and it was 2 there. So it looks like the code is running but somehow it does not complete it's work?

I will attach the output of stderr; perhaps that will tell you something? The extra lines "jal: " are mine; these are the added print statements.

And by the way: thanks a million for fixing this!

Created attachment 35219 [details]
stderr log file of starting KDE, where the 2nd screen is seen but does not initialize.

Even it is closed I can still reproduce it in kde 4.3.4. Has the fix been backported?

I installed 4.4beta2 (openSUSE Factory KDE) packages on openSUSE 11.2.

For me the behaviour is exactly the same as in 4.3 and previous KDE4 versions - meaning I get neither a plasma-desktop nor KWin on my second monitor (TV actually).

The X config worked with KDE3 back in the day and If I launch icewm on the second display it works fine too, so I'm quite sure it's not a problem with the X configuration.

Time to reopen? :-(

I would like to know where the bug is fix since it can be reprodice in kde 4.3.4 (debian Sid) and kde 4.4 b2 (open suse). This bug is the last thing that keeps me away from kde 4 so I hope it will be fixed/is fixed in 4.4 since it looks like kde 4.4 is the next version of kde to be in kde stable

#46, #47, #48:
It appears that the fix was not backported to 4.3.4? But I tried with 4.4 beta 1 (from the Ubuntu PPA) and found out the following: you must remove any existing .kde directory before testing this. If the .kde dir has been created when a single screen was present then enabling the 2nd screen does not do anything.
If I first make sure my X server has 2 screens and then delete .kde and let it be recreated I get two screens and appearently two plasma's but on the same (primary) screen (I see two backgrounds overlapping and two status bars overlapping). This seems to be another bug.

Perhaps you can try to delete .kde to see if you get the same?

I was trying to do the fellowing steps on debian sid;
1: Setting op 3 seperated x server on 3 screens using nvidia-settings and nvndia closed source driver version 190.42 and kde 4.3.4
2: Delete .kde in home
3: logout kde, restart xorg and login again

Problem remainds with 2 black screens but I can drag the mause to them

I tried again on my openSUSE 11.2/KDE 4.4b2 system - with a new user this time.

Same behaviour. On the second monitor I get nothing but blackness and an ugly mouse cursor. If I launch apps on the second display they don't have KWin. Which is apparently exactly the same behaviour as always.

almost certainly the "there is no dbus session bus that matches the x.org display and so all dbus calls fail and therefore the unique apps also fail" problem. that's what i've tracked it down to on other systems where this doesn't work at this point, and unfortunately the fix is outside of my immediate domain and requires some work in the hinterworlds that take care of things like how dbus sessions are set up. :)

Is there any not-so-geeky I could help with such as supplying with information about my settup (debian sid) that could speed things up a bid?

Can someone reopen this bug so that is has a chance to be fixed?
It is a shame that the true dual head mode (aka zaphod mode) does not work at all when other proprietary ati and nvidia multihead schemes are fully supported.

@Jonas: thanks for the offer, but not really. :)

@Christos: if this was a bug we could fix in our code, i'd say "sure, re-open it". but it isn't, so let's not waste our time.

Does upstream (xorg and dbus??) know about this problem? Should this bug report link to the upstream bug reports?

Isn't some (ugly) workaround possible? 

Don't want to troll, but how does this work for GNOME then (at least it did when I tried it briefly about 1½ years ago)? 

Worked in Xfce too at that time, don't even know if they use d-bus though.

I have just reveded to kde 3.5 in debian stable and fellowing the same thing I did in #50 and now I got something on all 3 screens. A shame that kde 4, dbus and xorg does not work probably together so I can use kde 4 because it looks nice

Has someone reported  this problem upstream to dbus and xorg?

There are several ways of setting up multiple monitors. At least three.

One way is that each monitor has a separate display. Like :0.0 and :0.1. This does not allow windows to be dragged between monitors. 

Second is using xinerama. This gives one big desktop, as fas as I know over several graphics cars. But does not support DRI.

Third is using built in functionality of driver to set up dual-head. You need to have a graphics card with more than one connection. 

I am at the moment using the dual-head option of the ati drivers. This works well with KDE4 (4.3.3), except I cannot open the Display configuration tool. If I do that, KDE "resets" my monitors to same picture on both monitor, instead of one large desktop.

I wish I could provide more details, but the setup is at my computer at work, and I have not had time to really experiment and take notes.

The issue I see,
   I prefer to use option 1, separate desktops, no need to have ability 
to drag from one to the other, however in this configuration Compositing 
and XDamage are disabled, thus I cannot use VDPAU on either screen.  I 
would really prefer to have ability for VDPAU at least on the primary 
screen.
On 2/9/2010 4:59 PM, Atle wrote:
> https://bugs.kde.org/show_bug.cgi?id=156475
>
>
>
>
>
> --- Comment #60 from Atle<atle pedersen gmail com>   2010-02-09 23:59:12 ---
> There are several ways of setting up multiple monitors. At least three.
>
> One way is that each monitor has a separate display. Like :0.0 and :0.1. This
> does not allow windows to be dragged between monitors.
>
> Second is using xinerama. This gives one big desktop, as fas as I know over
> several graphics cars. But does not support DRI.
>
> Third is using built in functionality of driver to set up dual-head. You need
> to have a graphics card with more than one connection.
>
> I am at the moment using the dual-head option of the ati drivers. This works
> well with KDE4 (4.3.3), except I cannot open the Display configuration tool. If
> I do that, KDE "resets" my monitors to same picture on both monitor, instead of
> one large desktop.
>
> I wish I could provide more details, but the setup is at my computer at work,
> and I have not had time to really experiment and take notes.
>
>

I have just upgrade kde 4.4.1 on my test laptop via http://qt-kde.debian.net/ . I dont know if I did something wrong but I can still reproduce this bug. My external screen is still black and I can take the mouse there bug I cannot do anything.
Is there news about this bug or a nice workaround?

(In reply to comment #62)
> I have just upgrade kde 4.4.1 on my test laptop via http://qt-kde.debian.net/ .
> I dont know if I did something wrong but I can still reproduce this bug. My
> external screen is still black and I can take the mouse there bug I cannot do
> anything.
> Is there news about this bug or a nice workaround?

1. Disable xdm
2. Make in your home directory file .xinityrc containing:
 #!/bin/sh
 export KDE_MULTIHEAD=true
 /usr/bin/kwin &
 /usr/bin/plasma-desktop --display :0.1 &
 /usr/bin/startkde
3. Start X running: xinit
4. Stop X ( crtr+alr+bsp )
5. Start X again running: xinit

Works for me fine ...

I just tried kde 4.4.4 and this bug is still present.

Then I tried the work around mention in #63.
This workaround does not work for me. When I start X both times with the xinit command I end op with a little console instead of kde.

PS under point 4 I was rebooting instead of pressing ctrl+alt+backspace since that combo has been removed (dont know why)

On 06/13/10 14:23, Jonas Vejlin wrote:
> https://bugs.kde.org/show_bug.cgi?id=156475
> 
> 
> 
> 
> 
> --- Comment #64 from Jonas Vejlin <jonas vejlin gmail com>  2010-06-13 14:23:10 ---
> I just tried kde 4.4.4 and this bug is still present.
> 
> Then I tried the work around mention in #63.
> This workaround does not work for me. When I start X both times with the xinit
> command I end op with a little console instead of kde.
> 
> PS under point 4 I was rebooting instead of pressing ctrl+alt+backspace since
> that combo has been removed (dont know why)
> 

It still works fine with me ... Also with kde 4.4.4
Couple of things, that I do:
1. I have enabled ctr alt backspace in X11 by setting in /etc/X11/xorg.conf:
  1.1
   Section "ServerFlags"
    ...
    Option         "DontZap" "false"
    ...
   EndSectioEndSectionn

 1.2
  Section "InputDevice"Se
    Identifier     "Keyboard0"
    Driver         "kbd"
    Option         "XkbOptions" "terminate:ctrl_alt_bksp"
    ...
  EndSectioEndSectionn

2. Disable xdm

3. Create .xinitrc file in my home directory containing:
  #!/bin/sh#!/bin/sh
  export KDE_MULTIHEAD=true
  /usr/bin/kwin &
  /usr/bin/plasma-desktop --display :0.1 &
  /usr/bin/startkde

4. After login ( as a user ) in console mode:
  4.1 xinit
      wait until kde finish starting akonadi server and other things.
      this time only one screen will have kde desktop
  4.2 stop X server by typing ctr-alt-backspace
      you will end up again in console prompt ( do not reboot )
  4.3 xinit (again)
      this time ( after 10 seconds or so ) two screens will have kde
desktops

I works on my gentoo x86_64 box

Success ...

after I have messed around the the xorg.conf after #65 I got kde on running on my 2 screen.
To rune kde on my 3. screen I tried to add this 
/usr/bin/kwin &
  /usr/bin/plasma-desktop --display :0.2 &
  /usr/bin/startkde

to the .xinitrc file (I have change :0.1 to :0.2)

So fare looks OK unto this dbus/xorg/kde problem has been solved (ofc if I can get the last screen up

Since this bug is hard to fix broperbly I have set up a bounty to enybody who would like to fix it:
http://nextsprocket.com/tasks/fixing-a-bug-in-kde-with-multiply-xog-runnings
The price is 150 doller.

I can see that another person has join in for paying to get this bug solved. The price is now 200 doller

I have been talking with Aaron J. Seigo at Akademy 2010 and he promised me that he would look into this problem "soon". I just hope he can fix it within the 4.6 branche.

I have been talking with Aaron J. Seigo at Akademy 2010 and he promised me that he would look into this problem "soon". I just hope he can fix it within the 4.6 branche.

ups sorry for trible posting

I have played around with Plasma Sources, and i think i have a solution.
with the following patch plasma starts on the second monitor without xinitrc workarround.

I test it with plasma from KDE 4.5.1 on Gentoo

Created attachment 51886 [details]
my patch for separate X screen config, please test

I have just tested Oliver's patch. There are two problems though.
Plasma workspaces are created now on both displays. However on both displays I have two desktops on top of each other with the dimensions of the each separate display. On display "A" I have a desktop with the dimensions of display "B" on top of another desktop with the dimensions of display "A." The same is true for display "B" also. If I click somewhere on the correct desktop, the other goes to the back but it is still there. Without the patch two desktops were created only on the first display and the second remained black.
The second problem is that there is no window manager on the second display.
I also tried the xinit workaround. The difference was that there was a window manager on both displays but I still had two overlapping desktops per display.

I have the problem found.
but I have no solution at this time.
my patch lets plasma starts on second screen automatically, the overlapping desktops is a problem between fork() in main.cpp an the Kephal::ScreenUtils::numScreens fuction used in plasma.
I think.
My theory is the fork() creates two processes and every process played around with two X displays in his own process on his own X server.

i need time to understand the plasma sources

The status of this is inappropriate, this bug is not "RESOLVED" or "FIXED". It is reproducible in KDE 4.5.1 and has been since the absolute earliest 4.0 build. I wouldn't consider 'wishlist' appropriate either, as this is a clear regression from KDE 3.5.x.

It sounds like 'Oliver' above who wrote a patch does not have the hardware to test his own patches. Is there any way to facilitate getting him or another developer the required hardware? Anywhere I've seen this bug listed the reasons it isn't resolved boil down to "the required developer(s) do not have hardware to test this with". 

Please reopen this bug so that we can at least hope it will get fixed. There's no reason this shouldn't have been reopened earlier other than to avoid it getting (probably back) into the top slot of the 'most hated' bugs view. This is the only thing keeping many 3.5.x users on the fence.

"It is reproducible in KDE 4.5.1 and has been since the absolute earliest 4.0
build."

actually, no, it isn't. up until 4.4 there was precisely zero support for dual head in the code. from that point forward, there is support for it, but evidently it has issues that remain. opening a report that says "it doesn't work" doesn't really help one bit. if there is someone who can and will do the work to track down what precisely isn't working, we can open a _new_ report that doesn't have all the now-irrelevant bits in it. just as we don't have one big "it crashes for some reason" or "it leaks memory for some reason" bug report that we re-use every time a certain class of bug appears.

"I wouldn't consider 'wishlist' appropriate either, as this is a clear
regression from KDE 3.5.x."

being in 3.x and not in 4.x does not make it a bug. it also doesn't make it not a bug. the two are unrelated things -> each issue must be assessed on its own merit.

"Is there any way to facilitate getting him or another developer the required hardware?"

centrally, e.g. via KDE e.V.? not formally, but it could be worked out if there was hardware and a willing dev.

"There's no reason this shouldn't have been reopened earlier other than to avoid it getting (probably back) into the top slot of the 'most hated' bugs view."

than you for assuming the worst of us; it isn't why it has remain closed.

"This is the only thing keeping many 3.5.x users on the fence."

in absolute #s, i'm sure there are some. in relative terms, very few.

in any case, i've taken Oliver's patch and seen what it fixes. i've applied a slightly more direction solution. commit coming in a moment.

SVN commit 1182542 by aseigo:

conver the number first to a string, otherwise it doesn't appen anything. noticed by Oliver oin the BR
CCBUG:156475


 M  +1 -1      main.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1182542

SVN commit 1182543 by aseigo:

convert the number first to a string, otherwise it doesn't append anything. noticed by Oliver oin the BR
CCBUG:156475


 M  +1 -1      main.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1182543

"actually, no, it isn't. up until 4.4 there was precisely zero support for dual
head in the code. from that point forward, there is support for it, but
evidently it has issues that remain." 
Thank you for clarifying.

"opening a report that says \"it doesn't work\" doesn't really help one bit. if there is someone who can and will do the work to track down what precisely isn't working, we can open a _new_ report that doesn't have all the now-irrelevant bits in it."
OK- I will go ahead and try to assist with this process. Can 4.5.1 be used? What version should I submit new bugs on?

"just as we don't have one big \"it crashes for some reason\" or \"it leaks memory for some reason\" bug report that we re-use every time a certain class of bug appears."
Understandable.

"being in 3.x and not in 4.x does not make it a bug. it also doesn't make it not
a bug. the two are unrelated things -> each issue must be assessed on its own
merit." 
Does it make it a regression? I know 4.x is a rewrite from the ground up, however, how do you make the 'regression' distinction? Are no missing features from 3.5 in 4.0 considered a regression? It may be appropriate to have a "not yet reimplemented" or "will not reimplement" status instead.

"centrally, e.g. via KDE e.V.? not formally, but it could be worked out if there
was hardware and a willing dev."
THIS is what I was waiting for. I would be willing to donate hardware for troubleshooting this issue. I am fully aware that donating X hardware to Y developer does not guarantee Y bug will be fixed, however I'm very willing to take a bet on this particular issue.

"than you for assuming the worst of us; it isn't why it has remain closed."
Out of frustration. My apologies.

"in absolute #s, i'm sure there are some. in relative terms, very few."
This -viewpoint- is hard to agree with, and is frustrating as an affected user, but understandable.

"in any case, i've taken Oliver's patch and seen what it fixes. i've applied a
slightly more direction solution. commit coming in a moment." 
Let me know what if anything you would like me to test specifically, and I can post screenshots / video / logs / test cases / behavioral observations at your request. I will also file bugs if deemed appropriate.

"I will go ahead and try to assist with this process."

thanks :)

"Can 4.5.1 be used?"

well, i just committed a fix based on Oliver's patch. that will only be in 4.5.3, though, sadly. which is set to be released in 1 month (4.5.2 was just recently tagged and will be released in the coming week or so). unfortunate timing for this. :/

"What version should I submit new bugs on?"

4.5.3 or newer would be best.

if you feel very adventurous, you could build kdebase-workspace from sources from the 4.5 branch in KDE's svn. (the rest of your KDE software would remain as-is, all the fixes are in just a couple of localized spots in kdebase-worspace). the best thing about that is you could then also test any fixes in the branch as they are made, which would be quite valuable. if you're interested in doing this, contact me by email and i can get your on your way if needed.

note that i'm traveling starting tomorrow so i'll be in and out of contact over the next couple of weeks.

as for what to test, screenshots and screencasts are the best, coupled with output from terminal (starting plasma-desktop from a konsole window is great for these things, as it spits out a lot of debug output related to geometry)

On 10/05/2010 02:37 AM, Aaron J. Seigo wrote:
> https://bugs.kde.org/show_bug.cgi?id=156475
> 
> 
> 
> 
> 
> --- Comment #81 from Aaron J. Seigo <aseigo kde org>  2010-10-05 02:37:31 ---
> "I will go ahead and try to assist with this process."
> 
> thanks :)
> 
> "Can 4.5.1 be used?"
> 
> well, i just committed a fix based on Oliver's patch. that will only be in
> 4.5.3, though, sadly. which is set to be released in 1 month (4.5.2 was just
> recently tagged and will be released in the coming week or so). unfortunate
> timing for this. :/
> 
> "What version should I submit new bugs on?"
> 
> 4.5.3 or newer would be best.
> 
> if you feel very adventurous, you could build kdebase-workspace from sources
> from the 4.5 branch in KDE's svn. (the rest of your KDE software would remain
> as-is, all the fixes are in just a couple of localized spots in
> kdebase-worspace). the best thing about that is you could then also test any
> fixes in the branch as they are made, which would be quite valuable. if you're
> interested in doing this, contact me by email and i can get your on your way if
> needed.
> 
> note that i'm traveling starting tomorrow so i'll be in and out of contact over
> the next couple of weeks.
> 
> as for what to test, screenshots and screencasts are the best, coupled with
> output from terminal (starting plasma-desktop from a konsole window is great
> for these things, as it spits out a lot of debug output related to geometry)
> 

Thank you guys.
Now my .xintrc file reduces to:

#!/bin/sh
plasma-desktop
kwin

and I have 2 plasmas on my dual head system

There was one glitch though ... The task plug-in was not launched on the
second screen.
I have fixed this like that:


1. In console mode ( tty )
rm -rf ~/.kde4
2. xinit ( .kde4 directory is set to a default set-up )
3. stop X by <ctrl><alt><back>
4. cp ~/.kde4/share/config/plasma-desktop-appletsrc \
   ~/.kde4/share/config/plasma-desktop-screen-1-appletsrc
5. xinit

Now I have 2 task bars as well.

By the way: now I don't need to execute xinit twice to make it work.

Once again, thank you for this patch.
This initial .kde4 set-up should be changed as well somewhere. Where ?

Greeting,
Stan

Is someone aware of any distro that already include this patch for testing purpose (it does not need to be stable)?

After around 3 house of tweaking Xorg.conf and some help from debian-kde team I can now run KDE 4 on my primary mashine using sid (kde 4.4.5 wich some more paches applied). In 8-9 days those pached would go to testing, and be part of squeeze. So after waiting around 2 years I can finaly begin to use kde 4

After upgrading to KDE 4.5.3 I am now able to use plasma on the second x session. There is non need for me to put plasma-desktop & in .xinitrc, as the shell is properly started automatically on both screens.
HOWEVER, there are some serious caveats that need to be resolved:
- On the second screen there is no panel by default. Adding one manually puts it on top of the screen, and it is not possible to but it on the bottom unless you edit plasma-desktop-screen1-appletsrc manually.
- The plasma shell on the second screen is in english, even if all the language settings are set to Italian.
- Kwin is not started automatically on the second screen, it has to be put in a startup script.
- Activities are really messed up. After every login a have about 30 activities hanging there, and if I delete them they are recreated after the next login.
- Maximizing a window on the second screen makes it of the size of the first screen, which is bigger and thus cuts part of the window.

Nevertheless, we're getting there :-)

Sorry for asking n00bish but where and what to put in this so called "startup script"?

There are also some problem with where programs starts. Eks if I starts Dolphins on screen 1(it will start there) but then move to screen 0 and start dolphin again it will only start on screen 1 and not on screen 0 as it should (should in the sense that it does in kde 3.5, gnome and other DE).

(In reply to comment #86)
> Sorry for asking n00bish but where and what to put in this so called "startup
> script"?
> 
> There are also some problem with where programs starts. Eks if I starts
> Dolphins on screen 1(it will start there) but then move to screen 0 and start
> dolphin again it will only start on screen 1 and not on screen 0 as it should
> (should in the sense that it does in kde 3.5, gnome and other DE).

I have put in ~/.kde/Autostart/kwin.sh the following:
#!/bin/bash
DISPLAY=":0.1" kwin &

Then chmod 0755 ~/.kde/Autostart/kwin.sh to make it executable and it should work.

#87 
Whan applied those lines can you then use "alt+tab"(for tab between windows)?

After I applied those lines kwin starts on all 3 screens as it should. But now tab is 1/3 broken.

around 1/3 time (when a windows is marked on screen 0) I can tab,else I get a window up on screen 1 or 2 that say *** No windows *** even if there is a lot of open windows on those screen. If I have a windows mark on screen 1 or 2 and try to tab nothing happens.

The problem I described in #86 is only for kde programs and not for gtk programs.

Does anyone else have those experience ?

(In reply to comment #88)

I've submitted this bug some months ago. Look at https://bugs.kde.org/show_bug.cgi?id=237260

"- On the second screen there is no panel by default."

yes, that's not by accident. it only puts a panel on the first screen. whether
or not that makes sense is discussable, but at least for
multi-screen-single-x-server systems it's the usual expectation, and i'd really
prefer not to add a multi-x-server exception in there if at all possible.

"Adding one manually puts
it on top of the screen, and it is not possible to but it on the bottom unless
you edit plasma-desktop-screen1-appletsrc manually."

this would be a bug, however :) someone with a multi-screen system probably
needs to spend some time with the panel controller code to see what's happening
there. by "not possible" i assume you mean that clicking on the "Screen Edge"
button and moving the mouse does nothing on the second screen.

"- The plasma shell on the second screen is in english, even if all the
language
settings are set to Italian."

do other KDE applications get the right language, or are all KDE apps started
on the second screen in english?

"- Kwin is not started automatically on the second screen, it has to be put in
a
startup script."

kwin issue, please open a new report for kwin.

"- Activities are really messed up. After every login a have about 30
activities
hanging there, and if I delete them they are recreated after the next login."

quite possibly this is fixed in trunk but not in branch. sounds identical to a
problem that was being seen on even single screen systems, though the fixes for
that have not been tested in a multi-head set up. they should work even in
those cases, however; testing would confirm. will probably require waiting for
4.6.0.

"- Maximizing a window on the second screen makes it of the size of the first
screen, which is bigger and thus cuts part of the window."

kwin issue

On 11/06/2010 12:03 AM, Aaron J.Seigo wrote:
> https://bugs.kde.org/show_bug.cgi?id=156475
> 
> 
> 
> 
> 
> --- Comment #90 from Aaron J. Seigo <aseigo kde org>  2010-11-06 00:03:18 ---
> "- On the second screen there is no panel by default."
> 
> yes, that's not by accident. it only puts a panel on the first screen. whether
> or not that makes sense is discussable, but at least for
> multi-screen-single-x-server systems it's the usual expectation, and i'd really
> prefer not to add a multi-x-server exception in there if at all possible.
> 
> "Adding one manually puts
> it on top of the screen, and it is not possible to but it on the bottom unless
> you edit plasma-desktop-screen1-appletsrc manually."
> 
> this would be a bug, however :) someone with a multi-screen system probably
> needs to spend some time with the panel controller code to see what's happening
> there. by "not possible" i assume you mean that clicking on the "Screen Edge"
> button and moving the mouse does nothing on the second screen.

It works. You can set the empty panel on the bottom of the screen manually.
But this is not an issue. I could miss panels on my other screens.
The problem is that applications ( like konsole, Firefox, etc )
disappear after minimizing them.
I need at least some 'icons fetch panel'. Like the task panel on the
first screen
> 
> "- The plasma shell on the second screen is in english, even if all the
> language
> settings are set to Italian."
> 
> do other KDE applications get the right language, or are all KDE apps started
> on the second screen in english?
> 
> "- Kwin is not started automatically on the second screen, it has to be put in
> a
> startup script."
> 
> kwin issue, please open a new report for kwin.
If you restart kwin manually, then you have window manager on all ( 4 in
my case ) screens. So it is not really kwin problem but ( I think )
startkde or related it shell scripts.
> 
> "- Activities are really messed up. After every login a have about 30
> activities
> hanging there, and if I delete them they are recreated after the next login."
> 
> quite possibly this is fixed in trunk but not in branch. sounds identical to a
> problem that was being seen on even single screen systems, though the fixes for
> that have not been tested in a multi-head set up. they should work even in
> those cases, however; testing would confirm. will probably require waiting for
> 4.6.0.
> 
> "- Maximizing a window on the second screen makes it of the size of the first
> screen, which is bigger and thus cuts part of the window."
> 
> kwin issue
>

(In reply to comment #90)

Thanks for taking the time to answer me.

> "- On the second screen there is no panel by default."
> 
> yes, that's not by accident. it only puts a panel on the first screen. whether
> or not that makes sense is discussable, but at least for
> multi-screen-single-x-server systems it's the usual expectation, and i'd really
> prefer not to add a multi-x-server exception in there if at all possible.
> 
> "Adding one manually puts
> it on top of the screen, and it is not possible to but it on the bottom unless
> you edit plasma-desktop-screen1-appletsrc manually."
> 
> this would be a bug, however :) someone with a multi-screen system probably
> needs to spend some time with the panel controller code to see what's happening
> there. by "not possible" i assume you mean that clicking on the "Screen Edge"
> button and moving the mouse does nothing on the second screen.

Yes, that's right. Actually I can move the panel only on the left side.

> 
> "- The plasma shell on the second screen is in english, even if all the
> language
> settings are set to Italian."
> 
> do other KDE applications get the right language, or are all KDE apps started
> on the second screen in english?

Yes, that's only plasma. All other apps are in Italian.

> 
> "- Kwin is not started automatically on the second screen, it has to be put in
> a
> startup script."
> 
> kwin issue, please open a new report for kwin.

Ok.

> 
> "- Activities are really messed up. After every login a have about 30
> activities
> hanging there, and if I delete them they are recreated after the next login."
> 
> quite possibly this is fixed in trunk but not in branch. sounds identical to a
> problem that was being seen on even single screen systems, though the fixes for
> that have not been tested in a multi-head set up. they should work even in
> those cases, however; testing would confirm. will probably require waiting for
> 4.6.0.

Ok.

> 
> "- Maximizing a window on the second screen makes it of the size of the first
> screen, which is bigger and thus cuts part of the window."
> 
> kwin issue

Ok

@sjesman:

"The problem is that applications ( like konsole, Firefox, etc )
disappear after minimizing them."

yes, because they aren't visible in that x-session, and so the panel on the first screen doesn't see them. *ponders* maybe that's a good enough reason to replicate the panel on each screen in that case. which means i'd have to propagate this information into the desktop scripting env (not hard), and then create the panel based on that. hmm... to help me out here, could you:

0. open krunner (alt+f2) and launch: desktop console
1. in the window that appears, enter this code:

for (var i = 0; i < screenCount; ++i) {
    var g = screenGeometry(i)
    print("screen " + i + " geometry is (" + g.x + ", " + g.y + ") x (" + g.width + ", " + g.height + ")")
}

2. press the Execute button (or just press ctrl+E)

3. paste the output here that appears in the text area below the code.



@support.intranet@libero.it:

"Yes, that's right. Actually I can move the panel only on the left side."

quick guess: it's thinking it's on the first screen, which technically it is in its x server, and then getting information about the first logical screen from kephal (screen 1) as a result, making only the left side a recognized target. that's a complete WAG, though, would need to be verified by someone with a multi-head setup.

"Yes, that's only plasma. All other apps are in Italian."

i'll ask the i18n people how the env vars propagate this; could be another kuniqueapplication specific bug. hm... can you try this for me: open konsole on screen 1, then start it on screen 2 and see if if appears translated?

On 11/06/2010 12:44 AM, Aaron J.Seigo wrote:
> https://bugs.kde.org/show_bug.cgi?id=156475
> 
> 
> 
> 
> 
> --- Comment #93 from Aaron J. Seigo <aseigo kde org>  2010-11-06 00:44:42 ---
> @sjesman:
> 
> "The problem is that applications ( like konsole, Firefox, etc )
> disappear after minimizing them."
> 
> yes, because they aren't visible in that x-session, and so the panel on the
> first screen doesn't see them. *ponders* maybe that's a good enough reason to
> replicate the panel on each screen in that case. which means i'd have to
> propagate this information into the desktop scripting env (not hard), and then
> create the panel based on that. hmm... to help me out here, could you:
> 
> 0. open krunner (alt+f2) and launch: desktop console
> 1. in the window that appears, enter this code:
> 
> for (var i = 0; i < screenCount; ++i) {
>     var g = screenGeometry(i)
>     print("screen " + i + " geometry is (" + g.x + ", " + g.y + ") x (" +
> g.width + ", " + g.height + ")")
> }
> 
> 2. press the Execute button (or just press ctrl+E)
> 
> 3. paste the output here that appears in the text area below the code.
> 
Here we go:
screen 0 geometry is (0, 0) x (1920, 1200)
screen 1 geometry is (0, 0) x (1920, 1200)
screen 2 geometry is (0, 0) x (1920, 1200)
screen 3 geometry is (0, 0) x (1920, 1080)

Runtime: 41ms
Greetings,
Stan
> 
> 
> @support.intranet@libero.it:
> 
> "Yes, that's right. Actually I can move the panel only on the left side."
> 
> quick guess: it's thinking it's on the first screen, which technically it is in
> its x server, and then getting information about the first logical screen from
> kephal (screen 1) as a result, making only the left side a recognized target.
> that's a complete WAG, though, would need to be verified by someone with a
> multi-head setup.
> 
> "Yes, that's only plasma. All other apps are in Italian."
> 
> i'll ask the i18n people how the env vars propagate this; could be another
> kuniqueapplication specific bug. hm... can you try this for me: open konsole on
> screen 1, then start it on screen 2 and see if if appears translated?
>

@Stan: thanks, that certainly explains it. now to think about the least-inelegant solution to this for 4.6. (there is no pretty fix that i can think of yet.)

There is another bug which belongs to plasma-desktop-appletsrc. After each start of plasma-desktop there will be two ressources generated (setup with two screens). One for screen 1 and one for screen 2. This happens also in plasma-desktop-screen-1-appletsrc.

--snip--
[Containments][1]
activity=Unbenannt
activityId=049b5180-b5f5-422c-a197-b8cb1d44f105
desktop=-1
formfactor=0
geometry=0,0,1280,1024
immutability=1
lastDesktop=-1
lastScreen=0
location=0
plugin=desktop
screen=0
wallpaperplugin=image
wallpaperpluginmode=SingleImage
zvalue=0

[Containments][1][Wallpaper][image]
slideTimer=10
slidepaths=/usr/share/wallpapers/
userswallpapers=
wallpaper=/usr/share/wallpapers/openSUSE111-1600x1200.png
wallpapercolor=0,0,0
wallpaperposition=0

[Containments][2]
activity=Unbenannt
activityId=049b5180-b5f5-422c-a197-b8cb1d44f105
desktop=-1
formfactor=0
geometry=1286,0,1280,720
immutability=1
lastDesktop=-1

[Containments][2][Wallpaper][image]
slideTimer=10
slidepaths=/usr/share/wallpapers/
userswallpapers=
wallpaper=/usr/share/wallpapers/Hillside.jpg
wallpapercolor=0,0,0
wallpaperposition=0
lastScreen=1
location=0
plugin=desktop
screen=1
wallpaperplugin=image
wallpaperpluginmode=SingleImage
zvalue=0
--snip--

The same happens with desktop-screen-1-appletsrc. So the second (smaller) screen gets the geometry of the first screen.

About the kwin that does not start I have already open a new bug report a few days ago:
https://bugs.kde.org/show_bug.cgi?id=255906
but have been marked as would not fix since the developer did not want to re-introduce  the needed code

(In reply to comment #97)
Did they tell you why they don't want to re-introduce the needed code. 
In my oppinion a multi-screen-setup with 2 or more seperate screens is not such a unusual configuration. E.g. it's the best solution if you want to connenct a LCD-TV next to your normal Monitor. Welcome to 2010.
I can understand that the developers can't do it alone because of the missing hardware, but they should be at least interested do solve this with the help of the community. At this point thanks to Aaron.

My understanding of what I was tolled on the IRC channel was the one x pr screen was not used by anyone and therefore they would not support it.

If it is the lag of cards or screens I could support the developer with it myself so they can get this thing fixed

(In reply to comment #93)
> @support.intranet@libero.it:
> 
> "Yes, that's right. Actually I can move the panel only on the left side."
> 
> quick guess: it's thinking it's on the first screen, which technically it is in
> its x server, and then getting information about the first logical screen from
> kephal (screen 1) as a result, making only the left side a recognized target.
> that's a complete WAG, though, would need to be verified by someone with a
> multi-head setup.
> 
> "Yes, that's only plasma. All other apps are in Italian."
> 
> i'll ask the i18n people how the env vars propagate this; could be another
> kuniqueapplication specific bug. hm... can you try this for me: open konsole on
> screen 1, then start it on screen 2 and see if if appears translated?

Do you mean, from konsole on screen 1 run 
DISPLAY=":0.1" konsole &
?
If so, yes, it is translated also on screen 2.

(In reply to comment #93)
> @support.intranet@libero.it:
> 
> "Yes, that's right. Actually I can move the panel only on the left side."
> 
> quick guess: it's thinking it's on the first screen, which technically it is in
> its x server, and then getting information about the first logical screen from
> kephal (screen 1) as a result, making only the left side a recognized target.
> that's a complete WAG, though, would need to be verified by someone with a
> multi-head setup.
> 
> "Yes, that's only plasma. All other apps are in Italian."
> 
> i'll ask the i18n people how the env vars propagate this; could be another
> kuniqueapplication specific bug. hm... can you try this for me: open konsole on
> screen 1, then start it on screen 2 and see if if appears translated?

Do you mean, from konsole on screen 1 run 
DISPLAY=":0.1" konsole &
?
If so, yes, it is translated also on screen 2.

(In reply to comment #99)
> My understanding of what I was tolled on the IRC channel was the one x pr
> screen was not used by anyone and therefore they would not support it.

This bug is about just that kind of setup and has 290 votes. In my opinion it is used!
It is a pity the kwin developers are making that assumption. And for me it is exactly the same as for you, Jonas. Without this kind of setup I am forced to use Xinerama without acceleration.

I hope we can convince the kwin team to accept this as a used configuration.

(In reply to comment #102)
> (In reply to comment #99)
> > My understanding of what I was tolled on the IRC channel was the one x pr
> > screen was not used by anyone and therefore they would not support it.
> 
> This bug is about just that kind of setup and has 290 votes. In my opinion it
> is used!
I know there are already various bug reports for kwin multiscreen support. I have opened another one which should  conclude the existing situation for kwin.
Feel free to add vote for (to show the importance of this topic)

https://bugs.kde.org/show_bug.cgi?id=256242

Looks like mr nice person (Aaron Seigo) have made a new patch for plasma
http://aseigo.blogspot.com/2010/11/multihead-plasma-desktop-needs-you.html

About the kwin issue it sounds like none on the kwin-team would try to make it work (see #1 at https://bugs.kde.org/show_bug.cgi?id=256242 ) so we are still left in the dark ages with kde on more than one screen

I am beginning to use kde 4 at work (since I only have one screen there) and I dont have any issues with kde 4 expect that it does not work with my home settup (3 screens on 2 nvidia cards)

Aaron Seigo have made further improvements on plasma multihead. They are now in trunk an needed to be test. Please look at http://aseigo.blogspot.com/2010/11/multihead-saga-continues.html and help with testing to get multihead working as expected.

I just upgraded to 4.6rc2 on openSUSE 11.3 using Nvidia blob.

I now get a plasma desktop on my second X-display - which is my tv. This is great. But...

There are a number of problems for me still:
* I get no panel on the second display by default (but I _can_ add one manually, so it's a minor issue)
* The plasma-desktop on the second display is not localized - it's in English while the one on the first display is in Danish.
* If I right click desktop -> run command on the second display, KRunner appears on the first display.
* I get no window manager (kwin) on the second display
* If I manually start kwin on the second display from the commandline, it sort of works, but it's unable to correctly understand the size of the monitor, so e.g. watching a video in Kaffeine in fullscreen the bottom and right of the video will be "out of bounds".

But it's great to see progress, and at least now I can have a plasma-desktop, but unfortunately it seems I'll have to run keep running icewm as the window manager for now ;-)

(In reply to comment #106)
> I just upgraded to 4.6rc2 on openSUSE 11.3 using Nvidia blob.
> 
> I now get a plasma desktop on my second X-display - which is my tv. This is
> great. But...
> 
> There are a number of problems for me still:
> * I get no panel on the second display by default (but I _can_ add one
> manually, so it's a minor issue)
> * The plasma-desktop on the second display is not localized - it's in English
> while the one on the first display is in Danish.
Same here for Italian
> * If I right click desktop -> run command on the second display, KRunner
> appears on the first display.
Same here
> * I get no window manager (kwin) on the second display
You can make kwin autostart on all displays by putting "export KDE_MULTIHEAD=true" on top of /usr/bin/startkde
> * If I manually start kwin on the second display from the commandline, it sort
> of works, but it's unable to correctly understand the size of the monitor, so
> e.g. watching a video in Kaffeine in fullscreen the bottom and right of the
> video will be "out of bounds".
I'm currently trying to understand this issue (which is the most annoying for me)
> 
> But it's great to see progress, and at least now I can have a plasma-desktop,
> but unfortunately it seems I'll have to run keep running icewm as the window
> manager for now ;-)

Created attachment 59011 [details]
Patch to fix locale problems

This small patch fixes locale problems with plasma

The situation is actually worse than reported in #106 is some respect.
* A program launched from an application launcher in a panel in :0.1 always starts in :0.0. Furthermore if you install an application icon in the panel and click it, the app starts again in the first screen. There seems to be no quick way to start an app in the second screen.
* Using keyboard shortcuts to launch applications has no effect when the second screen is active. Default keyboard shortcuts (such as Alt+F4 to close a window) do not work either.

Hi !

same problem for (thread on forum => http://forum.kde.org/viewtopic.php?f=67&t=94614&p=193875&hilit=%22separate+x+screen%22#p193875)

no window decoration, no keybaord, no taskmanager... active in screen2.

I try edit /usr/bin/startkde...

but thid bug is really solved ? for 4.6.3 maybe ?

#109, #110:
See bug 256242 for Kwin problems and proposed patch.
As for the plasma problems, in my experience apps started from the second screen will open there unless there is another instance of them running on the first screen.