Since the screenshot was too big, here is a link:
http://www.kluenter.de/desktop.png

Kind regards,
      Christoph

can you spot the problem with the following?

    VGA connected 1280x1024+0+0
    LVDS connected 1024x768+0+0

yep, the driver is saying that both monitors are positioned at (0,0). obviously LVDS should be 1024x768+1280+0 or VGA should be 1280x1024+768+0.

plasma is being lied to by the driver. not much i can do about that, to be honest.

let me guess, you are using an intel chipset with the open source intel driver, right? =)

also: are both screens on and displaying things when this happens?

Hi aseigo just read your blog and therefore got aware of this bug.

I have reported this in the opensuse bugzilla too. And Dirk Mueller fixed it just a few days ago. I was not able to try it since.

Have a look at https://bugzilla.novell.com/show_bug.cgi?id=335530.

@Aaron J. Seigo
As far as I know, the driver is not lying.

What you're currently facing is the so-called "Clone" mode i.e. both screens show the same desktop (I know that you already know what clone mode is ;) ). Therefore both screens are at (0,0)

Clone mode is what you get when you type:
"xrandr --output VGA --auto"

If you want to get independent screens (Xinerama style) you will have to type:
"xrandr --output VGA --auto" (just to turn on the monitor)

"xrandr --output LVDS --right-of VGA" (just make sure the framebuffer is enough to contain both screens, if not you will have to set the virtual resolution in your xorg.conf)

In this way you will get:

LVDS 1024x768+1280+0 and VGA 1280x1024+0+0 (at least in theory).

In the case of Clone mode Plasma should be able to shrink the desktop to the exact resolution of the screen. Each screen show the same desktop with different resolutions. The result is even uglier in GTK (since the bottom and bottom-left parts of the screen are not hooked correctly).

"In the case of Clone mode Plasma should be able to shrink the desktop to the exact resolution of the screen. Each screen show the same desktop with different resolutions."

This can't be done... in the clone configuration or better said:
    VGA connected 1280x1024+0+0
    LVDS connected 1024x768+0+0
you have two physical screens as viewports in the *same* framebuffer.. 

Actually that's how Xrand-1.2 works for any configuration. The desktop is one big framebuffer (in the OP case 1280x1024) with different views at it. The views can overlap partly or even completelly. Or can be put one above other, or besides the other.. etc.

What Plasma needs to do is detect overlaps and handle them in some way.

This should be handled by qt-copy patch #0172 (whatever handled in this case means, xrandr1.2 not caring much about xinerama backwards compatibility certainly sucks bigtime). It is still disabled for some reason though.

"let me guess, you are using an intel chipset with the open source intel driver, right? =) "

@Aaron, I have a dual head setup, no Xinerama, no twinview, just something in the lines of (xorg.conf):

---
Section "ServerLayout"
  Identifier "X.org Configured"
  Screen 0 "Screen0" #0 0
  Screen 1 "Screen1" LeftOf "Screen0" #0 0
  InputDevice "Mouse0" "CorePointer"
  InputDevice "Keyboard0" "CoreKeyboard"
  Option "AIGLX" "false"
EndSection
---

Nice, the big thing is that I have an nvidia card, using the nvidia propietary driver, and I get the same results when launching kde4 dual headed. I don't think it is worth to post another screenshot, the one above could very well be mine... well, except for the fact that the taskbar appears in the smaller desktop (so, it is in the middle of the screen instead of being at the bottom).

Maybe it is not just an intel bug, or maybe there is one more bug besides the intel related one that produces the same results.

I will try to keep an eye on this thread, but feel free to contact me at my mail account anytime if you need more info.

PS: It's been some days since I tried kde4, maybe I should update, just in case something changed.

> The desktop is one big framebuffer (in the OP case 1280x1024)
> with different views at it. The views can overlap partly or 
> even completelly.

yep, which is fine as an implementation detail. why this detail ever got exported out so that end user applications now have to work around it is beyond me. frankly, i don't know many user applications that would care one bit about this implementation decision; they tend to just want to know what screen is where, how big it is to the user, etc. it seems like a case of wrong priorities; if other x.org related tools need this information (probably do) another set of API for that would have been more appropriate, imho, rather than breaking all applications written to the existing API that rely on logical results.

i don't know how much thought went into the use cases of this particular bit of software, but it seems that the most common and obvious ones were either not considered, or not considered to be important enough. i really hope that such internal details can be hidden better in the future.

i guess we're now doing that at the toolkit level, as so many other X issues are, which is just a great way to get inconsistencies and cause lots of duplication of effort. i'm not advocating for One True Toolkit in X.org here, just that a bit more care could be applied to what application developers are given to work with by people working on X.org, its extensions and drivers.

> get the same results when launching kde4 dual headed

if by "dual headed" you mean "not xinerama, but two separate x instances" then that is a known, even expected, issue at this point that is not related to this particular bug. dual head support will come probably in kde 4.1 (due to a perennial lack of developer availability for dual head development). i'd also like to find a way to do it that's a bit more elegant (at least from the user's POV) than how we handled it in kde3 (which worked, but had some annoyances with regards to configuration, for instance).

Jesús: are you using a self-compiled qt, e.g. qt-copy from KDE's svn? if so, perhaps we could test and make sure that qt-copy/patches/0172-prefer-xrandr-over-xinerama.diff does indeed fix this?

@Aaron:

>> get the same results when launching kde4 dual headed
>if by "dual headed" you mean "not xinerama, but two separate x instances"

Yes, I meant exactly that.

I am using a self compiled qt, though it's not qt-copy from the kde svn repo. It was trivial to fetch the patch and add it to the ebuild (I use Gentoo), qt4 is now rebuilding with that patch, and when that is finished I will rebuild the kde4 stuff.

As soon as this finishes and I have 5 minutes to sit I will report back whatever.

Thank you for all the pointers, and for all your hard work.

> As soon as this finishes and I have 5 minutes to sit I will report back whatever. 

It just finished the recompilation of kdebase and I tried again. These are the things I've tried:

1.- starting with startkde from .xinitrc, no special stuff
2.- starting with KDE_MULTIHEAD=false/true
3.- starting one kde session with KDE_MULTIHEAD=false DISPLAY=:0.1 and another with KDE_MULTIHEAD=false DISPLAY=:0.0.

In every case, it did not matter how did I set the vars. It just ignored them and both desktops (1600x1200 & 1024x768) started on the primary monitor.

I am sure that the patch was applied correctly and kde4 fully recompiled against the new qt4.

Please do not include unrelated information. This bugreport is about Xinerama and your problem obviously is not. You want bug #152676.

@Lubos, thanks, anf forgive me for tainting the thread. It was all caused by my own ignorance.

Thanks also for the link to the correct bug for my case.

Regards. :)

GNOME is having the same problem have a look at https://bugzilla.novell.com/show_bug.cgi?id=310208 

from comment #26:
Keith Packard says that this is an bug in the Intel driver; initially it
mis-detects that VGA is connected, then goes back to thinking that it isn't. 
That's why it reports a monitor on the VGA output.

Felix, the problem of the OP is that it behaves badly when he *CONNECTS* the secondary monitor. 

BTW xrandr 1.2 is a NEW API, replacing Xinerama. Maybe it's Xinerama emulation doesn't work 100% correctly and this is what's causing the problem. 

BUT all new X drivers are switching to the Xrandr 1.2 API which is more rich than Xinerama and gives MORE information about the state of the screens. It would be nice if KDE supported it the best it can.

So... the Xrandr 1.2 API works as follows*, you have one big desktop with variable size (resolution, 1024x768, 2048x768, 1024x1536 etc) ... and then you have views at it.

The physical screens are views to the common large desktop... the views are defined by their resolution and position. so, the views can be overlapping... for ex. one screen is 1024x768 at position (0,0) - the other can be 800x600 at position (600,300) ... the total desktop will be size 1024 + 800 - 600 x 768 + 600  - 300 =  1224x1068. How will KDE handle this situation??



* I am not an expert, maybe someone more knowledgefull should correct me - but I see the topic here diverging so I thought to drop in.

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

Anyone care to discuss on the issues raised in comment #15??

Works with latest svn version now.
Everything is where it should be and the background is drawn correctly.
I can't find the Revision anymore. But i recompiled after I read something about this problem in the commit-digest.
Only problem is, that the desktop is only repainted under the mouse.
I have to move the mouse over the whole desktop until everything is visible again.

Hi everybody.

I am very sorry to annoy you, but I recompiled everything today and the
funny looking desktop with to connected Displays appears again.
I have made a little video to show the sypmtom. I think can be undestood much better this way. 
If anybody is working on this bug and needs Hardware for testing i could even send a Laptop with intel-graphics (X40) for some time.
Video can be found here: http://www.kluenter.de/bug153581.mpg (23MB)
and http://www.kluenter.de/bug153581-small.mpg (1.9MB)
Output of xrandr is still the same.

I have the same effect (though perhaps a different problem) with nVidia's TwinView.
In my case, there are two screens:

Screen 0: minimum 320 x 240, current 1680 x 1050, maximum 1680 x 1050
default connected 1680x1050+0+0 0mm x 0mm
   1680x1050      50.0*    52.0

Screen 1: minimum 320 x 240, current 1024 x 1280, maximum 1280 x 1024
default connected 1024x1280+0+0 left (normal left inverted right) 0mm x 0mm
   1280x1024      50.0*    51.0

Note that each of these screens is rooted at (0, 0).
Here is the relevant plasma output:

plasma(23600) RootWidget::screenOwnerChanged: was, is, containment: -1 1 Panel(0x8121be0)
plasma(23600) RootWidget::screenOwnerChanged: was, is, containment: -1 0 DefaultDesktop(0x8153258)
plasma(23600) RootWidget::createDesktopView: creating a view for 0 and we have 2 screens
plasma(23600)/libplasma Plasma::View::updateSceneRect: !!!!!!!!!!!!!!!!! setting the scene rect to QRectF(0,0 1680x1050) associated screen is 0
plasma(23600) RootWidget::screenOwnerChanged: was, is, containment: -1 1 DefaultDesktop(0x81b4840)
plasma(23600) RootWidget::createDesktopView: creating a view for 1 and we have 2 screens
plasma(23600)/libplasma Plasma::View::updateSceneRect: !!!!!!!!!!!!!!!!! setting the scene rect to QRectF(2572,0 1280x1024) associated screen is 1
plasma(23600) PlasmaApp::createView: Containment name: "Panel" | type 1 | screen: 1 | geometry: QRectF(0,-62 1280x56) | zValue: 150
plasma(23600)/libplasma Plasma::View::updateSceneRect: !!!!!!!!!!!!!!!!! setting the scene rect to QRectF(0,-62 1280x56) associated screen is 1
plasma(23600) PanelView::updateStruts: screen l/r/b/t offsets are: 0 400 26 0
plasma(23600) PanelView::updateStruts: screen l/r/b/t offsets are: 0 400 26 0
plasma(23600) PanelView::updateStruts: screen l/r/b/t offsets are: 0 400 26 0
plasma(23600) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 0 | geometry: QRectF(0,0 1680x1050) | zValue: 0
plasma(23600) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 1 | geometry: QRectF(2572,0 1280x1024) | zValue: 0

There are two things that I find odd:
1. Why is the scene rectangle for Screen 1 rooted at (2572, 0) rather than (0, 0)?
2. How come it is drawn at (0, 0) on Screen 0?

By the way, this setup works just fine with KDE 3.5.

Created attachment 24292 [details]
Create per-screen root widgets when required

I modified the plasma code to create a separate root widget for each screen. Instead of the RootWidget* member of PlasmaApp, there is now a QList<RootWidget*> member, where RootWidget objects are indexed by the screen number.

There are two scenarios handled:
1. A single virtual desktop, in which a single RootWidget object is created and is set as the "root handler" of each screen in the list
2. Multiple desktops (like my TwinView setup), where a RootWidget object is created per screen.

When the RootWidget objects are created, they are made to be children of the appropriate desktop widget, rather than of 0.

I am attaching a patch for consideration. It should go under KDE/kdebase/workspace/plasma/plasma. It gets rid of the "multiple desktops on one" problem, though it does not yet create the second desktop (I get a white background rather than a wall paper, and the context menu appears on screen 0 even when invoked from screen 1).

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

I compiled revision 816729 (updated the sources on June 3, 2008).
I get a single desktop widget now on my main screen, with the correct resolution (1680x1050).
Unfortunately, the second screen is still not working.

More details:
It seems that plasma fails to detect the number of screens correctly. Debug messages indicate that the number of screens returned by QApplication::desktop()->numScreens() is 1 instead of 2.
I wrote a simple program that only calls QApplication::desktop()->numScreens(), and used that as my .xinitrc command. It returns the correct number (2). Why does calling the same method from plasma yield a different result?

The problem I reported above is probably unrelated. I opened a new bug report for that (164242).
Using a stock Qt 4.4, Plasma detects the two screens. However, I still don't get a desktop on the second one. Instead, on the first login (no ~/.kde4/), a wall paper matching the size of the second screen (1280x1024) appears on the first screen, with the rest of the background drawn using a checkered pattern. On subsequent logins, the wallpaper takes up the entire 1680x1050 size of the first screen.

Here are snippets from two log files, corresponding to an initial and a second login, respectively:

plasma(1239) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: -1 | geometry: QRectF(0,0 22x23) | zValue: 0
plasma(1239) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 0 | geometry: QRectF(0,0 1680x1050) | zValue: 0
plasma(1239) PlasmaApp::createView: creating a view for 0 and we have 2 screens
plasma(1239) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: -1 | geometry: QRectF(1686,0 22x23) | zValue: 0
plasma(1239) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 1 | geometry: QRectF(1686,0 1280x1024) | zValue: 0
plasma(1239) PlasmaApp::createView: creating a view for 1 and we have 2 screens
plasma(1239) PlasmaApp::createView: Containment name: "Panel" | type 1 | screen: -1 | geometry: QRectF(11686,-44 1680x38) | zValue: 150

=====

plasma(1412) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 1 | geometry: QRectF(1686,0 1280x1024) | zValue: 0
plasma(1412) PlasmaApp::createView: creating a view for 1 and we have 2 screens
plasma(1412) PlasmaApp::createView: Containment name: "Panel" | type 1 | screen: 1 | geometry: QRectF(0,-44 1680x38) | zValue: 150
plasma(1412) PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 0 | geometry: QRectF(0,0 1680x1050) | zValue: 0
plasma(1412) PlasmaApp::createView: creating a view for 0 and we have 2 screens

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

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

It confuses me that 152676 was marked a dup of this bug. From what I can tell they are asking different things. Xinerama works in 4.1 (at least for me), as does twinview, but 152676 was asking about seperate X screens (non-xinerama, non-twinview), and that still does not work. Xinerama really isn't an option for me because its performance is abysmal. Twinview isn't either because though its performance is much better than Xinerama, it still has major video tearing issues ... The sooner this is fixed the sooner I can switch to KDE4 :)

I agree. As Aaron pointed out in one of the comments, there is much confusion regarding the different dual-screen options. I got confused myself: my setup has two screens (:0 and :1), not TwinView. I have to use this configuration since my screens are rotated differently, and working at different resolutions.
We need to clean-up these bug reports, as it seems that, while Xinerama and TwinView may already work in KDE4 (modulo some minor bugs), there is no work towards enabling multi-screen (I'm not even sure what the correct term is).
What I find strange, is that Qt has very good support for this option, which I have used in the patch I submitted earlier (a patch that is no longer applicable, by the way).

KDE 4.1.65, running two seperate screens, I get a small desktop with the resolution of the second screen on the primary screen and a black display on the second screen. The monitors are attached to different graphics cards (primary on AGP, secondary on PCI).

This makes the KDE 4 desktop out of the question for me and limits me to using the KDE technology I like (kate, kontact, etc) in Fluxbox.

What is exactly the problem with spanning plasma on all X-displays? Why once stick with one? The patch from Elad isn't very usable anymore because the sources changed drastically over the last year.

What is the current status of this problem, is it fixed in SVN or still pending? And what need to be done? Is it possible to implement on the fly X-display extension in the future? And what about XDM, can i extend my desktop temporary to an another pc without losing the apps running on that one when the connection is lost? (This may require a proxy.)

I'm running 4.2 with Xinerama on an ATI Mobility x1600 and it seems to work, at least to the extent of many of the above comments.

When I first log in it's a cloned desktop, but I think that's X's problem.  I have this in my .kde/Autostart:

  xrandr --output DVI-0 --left-of LVDS --auto --output LVDS --auto

once that runs, I can drag stuff between desktops, assign different pictures/colors, etc.  I have my big panel showing a desktop folder view and the laptop screen with the standard view.   Kicker gets very confused with the resize in this config, but that may be a separate bug.  Kicker does resize nicely in other cases, like running under VirtualBox, so perhaps it is Xinerama related, I'm not sure.

Perhaps there's some way I can wire the xrandr call into KDM to avoid the resize under plasma?

I have installed KDE 4.2.2-1, xserver-xorg-core 1.6.0-1 and NVIDIA Driver 185.19 and while using 2 seperate screens, I can only see a black screen with a non default mouse pointer.

comment #34 is a different problem altogether, and with kephal under us this works in all known-to-me non-dual-head configurations. reporters can correct me if they know otherwise.

All the issues I have had with using two monitors are gone here, too. Great work, and many thanks :D

(In reply to comment #35)
> comment #34 is a different problem altogether, and with kephal under us this
> works in all known-to-me non-dual-head configurations. reporters can correct me
> if they know otherwise.


The bug #152676 is marked as a duplicate of this bugs and the #152676 is about running two X screens, so either remove the duplicate for bug #152676 or mark this bug as unsolved, as the issue still is in KDE4.2.4.