please clarify what "multihead" setup means to you. One X Server per screen?

Multihead, as NOT Xinerama but TwinView.

No, one single X server, stretched onto two screens.

"NVIDIA X Server Settings" reports this:

System Information
 Operating System: Linux-x86
 NVIDIA Driver Version: 304.51

X Server Information
 Display Name: Atlantis:0
 Server Version Number: 11.0
 Server Version String: The X.Org Foundation
 Server Vendor Version: 1.13.0 (11300000)
 NV-CONTROL Version: 1.28
 Screens: 1

X Screen Information
 Screen Number: 0
 Display Name: Atlantis:0.0
 Dimensions: 1440x1669 pixels (420x487 millimeters)
 Resolution: 87x87 dots per inch
 Depth: 24
 GPUs: GeForce 8400GS (GPU0)
 Displays: LG Electronics L194WT (DFP-0), Acer P195HQL (CRT-1)
 Recovered GPU Errors: 0
 Stereo Mode: Unknown

this is called "multi screen". So I have to answer: works on my system, though I use XRandR.

The keyword "multihead" is from the list of keywords in the "components" selection for the bug. I've used it to widen the remit of the bug and seek a wider audience.

I'm glad it works for you, although it is totally irrelevant.

It doesn't work on THREE systems here:
- one Intel Centrino laptop using XRandR on 12.04
- a desktop using XRandR and an nVidia card
- another desktop NOT using XRandR and an nVidia card.

The "logout" plugin works, fading and blurring both screens on all three.

Different setups, different KDE versions, different OS distros, different video drivers / versions, different use of XRandR, same result from the plugin. What does this tell us?

Sorry, forgot: Desktop #1 is on Kubuntu 12.04 LTS, desktop #2 is on Kubuntu 12.10.
All them up to date with all repos enabled (up to -proposed).

(In reply to comment #4)
> What does this tell us?
Insufficient data input :-P

How many screens are active during the login screen?
(If the screen size is adjusted during the login, that'd be a problem)

Also please attach the output of "qdbus org.kde.KWin /KWin supportInformation"

Created attachment 76394 [details]
qdbus output

As requested

Login screen spans both monitors.

A bit of background:
My dual monitor setup is "vertical", as in: monitors are one on top of the other, primary on bottom, secondary on top.
Primary is a DVI, secondary is a VGA.
Resolution on primary is 1440x900, on secondary is 1366x768.
Secondary screen is at Absolute 37,0 and primary is at Absolute 0,769.
This makes the top screen centred over the bottom.
Primary  output is the DVI monitor at the bottom.

These are the settings from the "Size and Orientation" section of the "Display and Monitor" app on "System Settings". 

Apparently the KDM login screen is in "horizontal" instead, because:
- the login interface appears on the bottom screen;
- the mouse cursor sits at the far right of the bottom screen;
- if I move the mouse cursor on the far right of the bottom screen, it pops up at the far left of the top screen and the login interface moves to the top screen;
- if I move it back to the left on the top screen, it reappears on the far right of the bottom screen and the login interface moves to the bottom screen.

I suppose KDM is assuming that the two monitors are one beside each other, and doesn't read the system settings.

BUT.

The same problem with the login plugin happens even if I set the monitors on the System Settings to be identical to those that KDM erroneously uses, side-by-side / horizontal.
The primary monitor correctly and beautifully fades between the splash screen and the desktop (in my case transitioning through black), the secondary flicks instantly from the splash screen to the desktop (with a brief, almost imperceptible black flick between the two if the "fade to black" is enabled).

I'm using the standard stock KDM login screen and the standard splash screen.

You are focussing on this specific machine setup, but - as I already said - I can see the same behaviour on two other different systems. My closing question was rhetorical, pointing out that the only commonality between the three systems was the "login" desktop effects plugin... o_O

And that's where the bug lies, to the best of my logical analytical skills.

Look, I'm 49. I don't code anymore, but have been coding since I was 15.
I coded in Fortran, Pascal, COBOL, Basic, Visual Basic, C, C++ C#, ASM86, Java, JavaScript, Perl, PHP, Python... better stop there before it get ridiculous.

Focus. How can I help?

I'll try to login without a splash screen, and to log in to a KWin desktop with the same geometry as the kdm login screen, but I suspect it won't make a difference.

However - as I didn't do anything to "break" the system rather than setting up the screens to my requirements, and everything else is as out of the box - changing screen / resolution after login is not an unexpected or uncommon condition, and if this is a problem for the plugin this is a bug that must be addressed.

Happy to help.

(In reply to comment #8)

> I suppose KDM is assuming that the two monitors are one beside each other, and doesn't read the system settings.

Whatever you setup inside the session in krandr is actually part of the session (otherwise you'd have to pass a root password in order to change anything)
You can either control the initial screen layout via xorg.conf or by the init scripts interpreted by KDM, eg. /usr/share/config/kdm/Xsetup

> The same problem with the login plugin happens even if I set the monitors on
> the System Settings to be identical to those that KDM erroneously uses,
> side-by-side / horizontal.
ACK.

> I'm using the standard stock KDM login screen and the standard splash screen.
Does the splash screen cover both screens?

> You are focussing on this specific machine setup
No, i'm focussing on "what is it where you observe this", because that is the relevant aspect.

> I can see the same behaviour on two other different systems.
You didn't say *anything* about the multiscreen setup. Whether the bug happens on kubuntu 12.10 or 12.04 is actually less relevant than that it's ubuntu (which has special xrandr problems anyway, see https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu) and

> - another desktop NOT using XRandR and an nVidia card.
is extra-special because it's either TwinView (equals xrandr since the 300.xxx drivers), Xinerama (kinda unsupported but interesting detail if it happened on xinerama as well as on xrandr multiscreen setups) or an actual dualhead (which would actually open a can of worms, several issues with mutihead setups are known)

> My closing question was
... not providing  any further information.

> And that's where the bug lies, to the best of my logical analytical skills.
- Is any of the three systems *not* ubuntu?
- does the intel system run OpenGL 2 as well?
- is is always the same panels (important mostly if one's actually a Tv)

I tested
- Backends:
   * xrender
   * opengl 1
   * opengl 2
- On an nvidia system, archlinux, kwin is current git master 
- Common Dualscreen on DVI/VGA combo
- regular side-by-side
- centered on top (vga above dvi)

KDM is only on the primary screen, but krandr kicks in before ksplash, so the splash screen already occurs on the adjusted setup, there're no further changes, esp. not after kwin starts.

I can confirm Martins observation that the effect operates exactly as expected on both panels.

Now let's see about your actual logical skills:

a) you lie
b) martin & me both lie
c) it's a local problem
d) it's a local solution

I can scratch second half of (b) (and don't believe in the first at all, but that does no more matter) so if you can scratch (a) we remain with (c) and (d)

Last notable change to the effect has been Thu Jul 12 17:20:17

This should be enough information for you to figure the next test to narrow the problem.
If not, feel free to call back.

> > The same problem with the login plugin happens even if I set the monitors on
> > the System Settings to be identical to those that KDM erroneously uses,
> > side-by-side / horizontal.
> ACK.
Just a dry ACK? What a way to investigate there...

> > I'm using the standard stock KDM login screen and the standard splash screen.
> Does the splash screen cover both screens?
Two independent splash screens on the monitors, going in perfect sync (the motif does not span or stretch, it repeats).

> > You are focussing on this specific machine setup
> No, i'm focussing on "what is it where you observe this", because that is
> the relevant aspect.
No, THE SAME BEHAVIOUR happens on three different machines, with different hardware, different Kubuntu Distro, but similar or identical set-up.
 
> > I can see the same behaviour on two other different systems.
> You didn't say *anything* about the multiscreen setup.
Yes I did. Read again all my posts.
- 1 Desktop PC, nVidia with closed source drivers on Kubuntu 12.10, 1 x DVI + 1 x VGA, top/bottom setup through System Settings - not the NVIDIA Control Panel;
- 1 Desktop PC, Nvidia with closed source drivers on Kubuntu 12.04 LTS, 2x DVI, side-by-side / horizontal setup, no special setup on System Settings, as per stock install / standard detection;
- 1 Laptop PC, Intel with stock drivers on Kubuntu 12.04 LTS, 1 x DVI (inbuilt screen) + 1 x VGA, special handcrafted xrandr call on Xinit to get the two screens working in vertical setup - System settings couldn't do it for the grace of God.

*SAME* behaviour from the plugin - on very different systems and setups.

> > My closing question was
> ... not providing  any further information.
And here you start getting cheeky. Young man, I'm not a kid, show respect.

> > And that's where the bug lies, to the best of my logical analytical skills.
> - Is any of the three systems *not* ubuntu?
No
> - does the intel system run OpenGL 2 as well?
No, the OpenGL2 shaders are broken on Intel GPUs - you should know that.

> - is is always the same panels (important mostly if one's actually a Tv)
Yes, always the secondary, and NO, they're either true VGA or DVI screens.

> I tested
> - Backends:
>    * xrender
>    * opengl 1
>    * opengl 2
> - On an nvidia system, archlinux, kwin is current git master 
> - Common Dualscreen on DVI/VGA combo
> - regular side-by-side
> - centered on top (vga above dvi)
And here is the difference:  your test system is using a marginal minimalistic distro, KDE SC from github, while all three my systems use the massively deployed (k)ubuntu, with latest stable KDE from the -proposed repo.

It really does not matter if your plugin works for you on your system, it must work on all distros to be ready for prime time. If you want Linux to be a system that can be deployed on everybody's desktops you need to change attitude, not calling bug reporters liars or incompetent, get your head out of the sand and test, test, test.

> KDM is only on the primary screen, but krandr kicks in before ksplash, so
> the splash screen already occurs on the adjusted setup, there're no further
> changes, esp. not after kwin starts.
If k/xrandr kicks in before ksplash, why the splash screen is not stretched all along the full X screen (1440x1669), but repeated on both monitors?

> I can confirm Martins observation that the effect operates exactly as
> expected on both panels.
And you accept his report without asking anything about HIS system, but you question mine?
What an attitude, lad.

> Now let's see about your actual logical skills:
> 
> a) you lie
Don't you even dare repeating this. Ever.
> b) martin & me both lie
Not a lie, but a refusal of the inconvenient truth.
> c) it's a local problem
> d) it's a local solution
None of the four, it's POSSIBLY a downstream problem, specific to (k)ubuntu, but being that distro the largest deployed linux distro using KDE, it's the reference point for mass production, and you need to ensure your app works there.

> I can scratch second half of (b) (and don't believe in the first at all, but
> that does no more matter) so if you can scratch (a) we remain with (c) and
> (d)
Your analytical skills still stop between the boundary of your little walled garden.
"Can't reproduce here, bug does not exist, it's a local problem."
Test on a stock Kubuntu 12.10 and then come back here and say "works as intended".

It's a minor, non-blocking cosmetic bug, and I've lost hours of my very expensive time trying to help you solve it with all the input you requested.

If you still maintain the problem does not exist, it's fine by me. I can live with that.
But don't pretend OSS can be taken seriously.
Mass deployment of an app requires an effort three orders of magnitude larger that those you invested here.

> This should be enough information for you to figure the next test to narrow
> the problem.
Idem for you to fix the problem or to find a workaround.

Close the bug report, I'm not going further.

You know what? I'm disabling the plugin...

Over and out.

(In reply to comment #10)
> It really does not matter if your plugin works for you on your system, it
> must work on all distros to be ready for prime time. If you want Linux to be
> a system that can be deployed on everybody's desktops you need to change
> attitude, not calling bug reporters liars or incompetent, get your head out
> of the sand and test, test, test.
Actually it does matter. If it works on my and Thomas's system we have a hard time investigating the issue and by that a problem with fixing the issue. Also at the current point in time we don't care anymore for what is shipped in the distros. It's outdated from our point of view. There won't be another 4.9 version, so it only matters how the code in master looks like. Btw. attitude on the user's side doesn't help.

@Thomas: I just had a look into the effect and it assumes there is only one login_window. That probably doesn't work if there is more than one login splash window.

@Corrado: which login splash are you using?

ok, with ksplashqml there is one window per screen and that doesn't work.

for testing:
ksplashqml Minimalistic --test

Git commit 118b841835cdc5c60686abc3766a432323440266 by Martin Gräßlin.
Committed on 14/01/2013 at 08:38.
Pushed by graesslin into branch 'master'.

Rewrite of Login effect to JavaScript

Main motivation for this rewrite is the fact that the login effect had
been designed under the assumption that there is only one login splash
window. This assumption does no longer hold with the QML based splash,
which creates a window per screen.

By using a JavaScript based effect, the animation effect is implicityly
used which supports animating multiple windows at the same time in a
better and safer way.
FIXED-IN: 4.11
REVIEW: 108403

M  +1    -1    kwin/effects/CMakeLists.txt
M  +0    -2    kwin/effects/configs_builtins.cpp
M  +1    -30   kwin/effects/login/CMakeLists.txt
D  +0    -129  kwin/effects/login/login.cpp
D  +0    -60   kwin/effects/login/login.h
D  +0    -64   kwin/effects/login/login_config.cpp
D  +0    -94   kwin/effects/login/login_config.desktop
D  +0    -55   kwin/effects/login/login_config.h
D  +0    -5    kwin/effects/login/loginconfig.kcfgc
A  +6    -0    kwin/effects/login/package/CMakeLists.txt
A  +94   -0    kwin/effects/login/package/contents/code/main.js
R  +2    -2    kwin/effects/login/package/contents/config/main.xml [from: kwin/effects/login/login.kcfg - 086% similarity]
R  +0    -0    kwin/effects/login/package/contents/ui/config.ui [from: kwin/effects/login/login_config.ui - 100% similarity]
R  +10   -6    kwin/effects/login/package/metadata.desktop [from: kwin/effects/login/login.desktop - 094% similarity]

http://commits.kde.org/kde-workspace/118b841835cdc5c60686abc3766a432323440266