Created attachment 223709 [details]
sax log

I'm assuming you'have configured a side-by-side monitor setup by SaX2. Simply
change the order left/right monitor Dualhead Mode configuration dialogue. Let me know, if this helps.

Yes, but that only changes the way around that the monitors are (left or right), but doesn't change the primary one (external still primary). 

Then this seems to be a desktop issue, i.e. trying to use always VGA instead of LVDS. Which desktop are you using?

GNOME, KDE3 and KDE4 all put the panel on the external monitor (which makes me think it might not be a desktop issue; this is a change since 10.3 too), though it's mostly a problem in KDE4 because you cannot easily move the panel and there are some dual-screen bugs with it. Also for example the KDM login screen now appears on the external monitor.

Ok. Reassigning to KDE4.

Why do you reassign it to KDE4? Only because a work-around for the problem is not easily possible there? Can the original problem please be fixed?

The original problem is that the desktops apparently always uses the VGA/external screen as primary screen. And with KDE4 you cannot change this easily due to Dualhead bugs. Therefore I reassigned it to KDE4 component. 

there is no such thing as "primary screen" anymore with xrandr 1.2. it puts the panel on the biggest screen by default. 

implementing primary screen support is a x.org bug (or rather the libxinerama emulation over it).

> there is no such thing as "primary screen" anymore with xrandr 1.2. it puts
> the panel on the biggest screen by default. 

This is exactly the issue here. Please make it at least configurable (including KDM login screen). Thanks.

  ==> Enhancement

I think you misunderstood. We only use the Xinerama* functions from libXinerama (and react on XRANDR events by re-reading). The first screen we get from X is the primary one, the same way this has always been. If you want an option for this, it belongs to X, not to KDE (how about non-KDE apps?).

I'm not really familiar with programming the Xinerama extension. So what I understand is that you still get a display as primary screen although it's disconnected. So there is no way to verify if it's still connected via Xinerama extension. Is this correct?

I would assume that you can check for connected displays with RANDR 1.2 to make sure the primary screen is connected. I think Federico is willing to help here. :-)

AFAIK Xinerama only provides what is there, so disconnecting a display would mean the XineramaQueryScreens() function would return one screen less (and whichever else screen will be the first one becomes the "primary" one). I assume the Xinerama "implementation" these ways works by wrapping RANDR to keep providing the old Xinerama-style information.

So it would even be possible to fix the issue by using the Xinerama extension, making the internal laptop panel the primary screen, when the external monitor has been unplugged. SaX2 only creates a static configuration. For dynamic configuration changes the desktops are responsible. Maybe Federico wants to work on this. Enhancement with low priority.

Your SaX log indicates that you have an Intel 965 card.  The driver for this has a bug where it will report the VGA output *before* the integrated LCD when you list the available outputs (see bug #343858 and bug #310208, for example).  KDE and GNOME assume that the first output in that list is the "primary" one.

Ubuntu supposedly has a patch for this in their Intel driver.

Federico, in case you know where to find this Ubuntu patch, please let me know. Thanks.

Sigh, the way things are looking, it seems that we'll have to make the desktops implement the "primary screen" policy themselves.

I'm leaning towards making GTK+ see if there is a RANDR output called "LVDS"; if so, it should make it the first element in the list of returned monitors in gdk_screen_get_monitor_*().

I've been looking through all the RANDR bugs we have, and pretty much all of the ones similar to "$fooapp thinks the external monitor is the primary one" would be fixed with this scheme.

Alternatively, we could patch the X server to actually return LVDS first in XRRGetScreenInfo().

FWIW, RandR 1.3 will have properties that will tell you exactly the type of the outputs. I'll go into details as soon as it's actually implemented (I'm done with the spec, but implementation need some time, and all drivers have to adopt). When going for the name, please also check for "PANEL", because that's what we use for RadeonHD.

Patching the Xserver is IMHO a no-go, because the order is up to the driver.

(In reply to comment #18 from Matthias Hopf)
> FWIW, RandR 1.3 will have properties that will tell you exactly the type of the
> outputs. I'll go into details as soon as it's actually implemented (I'm done
> with the spec, but implementation need some time, and all drivers have to
> adopt). When going for the name, please also check for "PANEL", because that's
> what we use for RadeonHD.

Could RadeonHD use "LVDS" just like the other drivers?  If the logic to check the output names indeed has to live in the clients, I'd rather have a standard naming scheme rather than having to adjust to differences in drivers.

[Otherwise someone will write another driver for another chipset and call the built-in display "foobar" - then the software will fail :) ]

> Patching the Xserver is IMHO a no-go, because the order is up to the driver.

Actually, what if we let the driver return whatever it wants, but then have the hardware-independent part reorder the list of outputs?  Each output/CRTC/etc. would still keep its ID, so the XRR* functions would still work as expected.

(In reply to comment #19 from Federico Mena Quintero)
> Could RadeonHD use "LVDS" just like the other drivers?  If the logic to check

No.
The term LVDS is a technical term and people cannot be forced to use them, IMHO it has been a bad decision by the radeon developers in the first place. Also, it's bad to use a de-facto standard for something that is (apparently) not standardized. That's exactly what the properties should be for.

We recently had a poll for changing output names (for different issues). Result was that if at all they should be changed only slightly. Everybody agreed that PANEL is superior to LVDS.

> the output names indeed has to live in the clients, I'd rather have a standard
> naming scheme rather than having to adjust to differences in drivers.

There is already none. And you're not guaranteed that there will ever be one.

> [Otherwise someone will write another driver for another chipset and call the
> built-in display "foobar" - then the software will fail :) ]

Exactly.
Never EVER use names for meta-information. Period. That's one of the lessons that should have been learned a long time ago.

That said, using the name as decision maker is probably the best you can do for SLE 11 ATM :-(
Depends on the release schedule whether we would have Xserver 1.6 (which would - hopefully - include standard property support), but ATM I doubt that.

> Actually, what if we let the driver return whatever it wants, but then have the
> hardware-independent part reorder the list of outputs?  Each output/CRTC/etc.
> would still keep its ID, so the XRR* functions would still work as expected.

In that case you're forcing a heuristics-based order upon the order the driver issued, and while the driver might have had a clue about the order, the Xserver will never have. E.g. in the radeonhd driver you can change the order of the outputs if the BIOS isn't telling you the correct order, that would no longer work if the Xserver reorders everything.

SaX2 has been dropped with openSUSE 11.3. I guess the issues in the RANDR >= 1.2 tools in KDE4/Gnome have been fixed. Otherwise please reopen.