Bug 340527

KWin didn't have any changes recently. So my gut feeling is that KWin is innocent :-) But we need to figure that one out: when did the problem occur? If it was recently, please try going back to an older kwin revision to rule out that it's kwin.

I noticed it yesterday after logging in; I didn't restart all the things after rebuilds and I haven't rebuilt in couple days. So somewhere during that time.

I'll try rebuilding kwin from couple days back and post back.

Just looked through the log, it doesn't look like anything which could have touched the rendering code.

two things to try: disable blur effect and background contrast.

Ok so disabling both at once sort of kind of fixes it (there are still rendering issues but different and not as bad). Leaving either one on shows the bug again.

Interesting bit: I have (had) a two screens setup, if I boot with one screen unplugged, this is what I get, if I connect the second screen again and change kscreen setup, this glitch is gone. So I /think/ it may be related...

Oh and yes, this is with kwin from master with the recent multi-screen changes.

Please check the output of xrandr if the problem happens. I noticed glitches when xrandr reported wrong size information. Especially the first line which looks like:
Screen 0: minimum 320 x 200, current 3200 x 1080, maximum 8192 x 8192

was wrong for me.

Oh yes:

Screen 0: minimum 8 x 8, current 3360 x 1200, maximum 16384 x 16384
DVI-I-0 disconnected
DVI-I-1 connected primary 1920x1200+1440+0

"Current" is definitely wrong as you can see.

Do I read this correctly that your *left* screen is disconnected?

one more thing: please check with
qdbus org.kde.KWin /KWin supportInformation

whether KWin internally reports the correct screen information.

Created attachment 89790 [details]
qdbus org.kde.KWin /KWin supportInformation

That is correct.

As for supportInfo (attached is whole output):

Screens
=======
Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 1
Screen 0 Geometry: 1440,0,1920x1200

good, I have an idea. I might not be able to reproduce the problem (I tested such a setup last week and it worked for me), so expect a few patches thrown at you ;-)

Happy to test :)

no idea what will happen: http://paste.kde.org/p28xcya3t

be warned: this change has the potential of completely breaking KWin. So have a quick way prepared to remove the change, compile and restart KWin without having a useable X session.

@Dan: could kscreen detect if there is something wrong like in comment #8 and fix the setup?

Nope, no change with that patch. No breakage either afact.

Also as a sidenote, this situation is completely breaking Chrome, it's crashing like crazy.

> Also as a sidenote, this situation is completely breaking Chrome, it's
> crashing like crazy.

based on that I'm stopping to investigate on it. Fixing the cosmetics doesn't 
make much sense when the X setup is messed up. We need to fix that and then 
the blur effect will be right, too.

Uhm...I tried turning off compositing, that actually makes Chrome work properly. Switching compositing back on makes it go haywire. I'm not exactly sure how is one affecting the other though (Chrome does use GPU compositing to render pages...or something).

(In reply to Martin Klapetek from comment #17)
> I'm not exactly sure how is one affecting the other though
Driver bug (while this would be pretty new on the nvidia blob) - you may however try fixing the screen setup and see whether the issues remain:

   xrandr --output DVI-I-1 --auto --pos 0x0

Interestingly, I cannot even create a non 0x0 position on a single screen setup.

I tried xrandr --auto last night and what happened was that kwin actually shrunk the whole virtual screen to the single one, so basically half of my screen was just black and everything had about half the width it should. But it wasn't repainting - I moved a window and the painted window stayed in the original position but mouse cursor would change where the actual window would be.

Switching compositing off and on however makes it correct again.

> I tried xrandr --auto last night and what happened was that kwin actually
> shrunk the whole virtual screen to the single one, so basically half of my
> screen was just black and everything had about half the width it should. But
> it wasn't repainting - I moved a window and the painted window stayed in
> the original position but mouse cursor would change where the actual window
> would be.
> 
> Switching compositing off and on however makes it correct again.

Probably we didn't process the event correctly and didn't trigger the new 
setup of the viewpoint.

@Martin G.
KWin may just have stumbled on the actual "no-change" of this.

@Martin K.
> Switching compositing off and on however makes it correct again.

- Does that include the original bug, ie. are the contrast/blur textures painted at the correct position now?
- What about the chromium situation?
- does "xrandr -q" now announce the single screen to be
            DVI-I-1 connected primary 1920x1200+0+0 ?

> - Does that include the original bug, ie. are the contrast/blur textures painted at the correct position now?

Yes

> - What about the chromium situation?

Works perfectly fine.

> - does "xrandr -q" now announce the single screen to be
            DVI-I-1 connected primary 1920x1200+0+0 ?

Yes.

How does the compositor behave on
     xrandr --output DVI-I-1 --mode 1024x768
from this state? (To check whether it can handle changes between two sane modes, --auto to revert to WUXGA. The remaining bug would then either be in nvidia-settings or kscreen: whatever causes this single-screen junk mode)

>  The remaining bug would then either be in
> nvidia-settings or kscreen: whatever causes this single-screen junk mode)

rather kscreen as I'm able to reproduce on Intel

> How does the compositor behave on
>     xrandr --output DVI-I-1 --mode 1024x768
> from this state?

You mean from the original bug state? Or from the xrandr --auto two-screens-in-one state?

From the original bug state (the wrong paintings of applet backgrounds) the above xrandr does not have any effect - the resolution is smaller but the same bug still exists, the offpainted backgrounds are just positioned elsewhere. I wasn't able to reproduce the half-screen-black state afterwards it so I'll try on next reboot.

(In reply to Martin Klapetek from comment #25)

> You mean from the original bug state? Or from the xrandr --auto
> two-screens-in-one state?

I meant from the sane (after "xrandr --auto") state.
The interesting question is whether kwin acts reasonably when changing one sane resolution to another one. Afaics, <width>x<height>+a+b|a,b != 0 should not be possible (and doesn't make any sense) for a single screen.

The result is the same --> boot into the buggy xrandr setup --> do xrandr --auto --> now half of the screen is black and the other half has squished the full screen width (just compositor is wrong, switching off and on makes it ok) --> do xrandr --...x768 --> it's the same as doing it from the original bug state, ie. the backgrounds are still painted off just at different location.

how is it with the new kscreen? Did that improve the situation?

Not quite. In fact, made it even worse. Now on startup, if I have that invalid xrandr data, I get about ~400px wide strip of actual desktop, starting from the left (so I see the left part of the panel for example). The rest of the screen is just the background from login screen, I can move my mouse there, but it's like a window that's always on top. Not sure if that's related to this bug tho.

I'll try to get a screenshot next time.

Created attachment 90363 [details]
The screenshot

$ xrandr -q

DVI-I-1 connected primary 1920x1200+1440+0 (normal left inverted right x axis y axis) 518mm x 324mm

So basically the small strip of my desktop is what's left of 1920-1440, the kde4 background is lightdm background. I'm not sure if this is still related to the original bug though, looks more like kscreen/nvidia/X problem.

Given this state, I'm unable to reproduce the original bug (because I simply cannot see the right part of the panel), so I can't really tell.

the screenshot looks like compositing is disabled, so maybe you just side-passed the problem?

It's on, for sure (kicker has shadows, closing it fades out etc).

The real bug and question is what drives you into +1440+0 for a single screen setup - this should really not be possible.

Did/do you have a 1440x960 (or similar) screen on DVI-I-0?
Does this also happen w/ a new user account (ie. kscreen/krandr picking some junk and terrifying libxrandr until it surrenders to this invalid mode)?

I did have such screen yeah, but not anymore.

I just found out that this might be the driver issue; I'm using a xorg.conf file (for the Driver "nvidia" line, otherwise nouveau gets loaded and things explode) so I looked there and I noticed that there's this:

    Option         "metamodes" "DVI-I-1: nvidia-auto-select +1440+0, DVI-D-0: 1440x900 +0+300"

Looks like it's being hardcoded (this file is generated by the driver install procedure). Sigh.

Ahhhh!

That probably comes from nvidia-settings which can and did  (and probably still does) it's own user based screen setup config - along the root user config (which was written into /etc/X11/xorg.conf)

-> Check /etc/X11/xorg.conf for twinview config setups and if you find nothing there, just re-run nvidia-settings as user and see whether the config is all sane there.
The re-saved settings will (hopefully) fix the nvidia screen config (I forgot where it was, but afair NOT ~/.nvidia-settings-rc)

Oh yeah there used to be some binary settings file or something.

Running nvidia-settings offers me to save xorg.conf with 

    Option         "metamodes" "nvidia-auto-select +0+0"

I just remembered why the original setting (probably) exists there in the first place - with this^ the machine boots with only one screen on when two are connected, switching the mode only after login (kscreen kicks in), breaking ksplash in the process. That annoyed me enough that I set the screen setup in nvidia-settings to have both screens on right after boot. One would really expect nvidia to be more clever these days.

Also, the twinview option/setup is not in xorg.conf anymore since 30x by default. "Works good enough so it's on by default" or something like that I remember.

I've applied that setting, will see if that fixes it.

For completeness, here's the relevant part of the xorg.conf (the second screen is not even there as Monitor (and never was), maybe that was causing problems...no idea):

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "BenQ BL2411"
    HorizSync       30.0 - 83.0
    VertRefresh     50.0 - 76.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 660 Ti"
EndSection

Section "Screen"
# Removed Option "metamodes" "DVI-I-1: nvidia-auto-select +1440+0, DVI-D-0: 1440x900 +0+300"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TripleBuffer" "1"
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "nvidia-auto-select +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Try:
Option "TwinViewOrientation"      "DVI-I-0 LeftOf DVI-I-1"

Martin did `Comment 37` fix the issue for you?

Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "resolved" or "reported" when you respond, thanks.

This is from forever ago, it probably likely isn't really relevant anymore.