[kwin] [Bug 357988] Black screen when reconnecting display

2016-02-17 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #17 from Bernd Steinhauser  ---
FYI, a bug was reported upstream, the issue was found and got fixed:
https://bugs.freedesktop.org/show_bug.cgi?id=93746

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-17 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #16 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #15)
> (In reply to Bernd Steinhauser from comment #14)
> > Around 60 fps, no change there. The left part of glxgears is still updated,
> > the right part is just a static image.
> 
> Well, since it's not kwin specific, we'll have to assume it's in the GL/X11
> driver ;-)
> 
> Since the uncomposited glxgears runs at 60Hz, I assume you've got (flipping
> disabling)
> Option "TearFree" "on"
> set? (Xorg.0.log)
> What about turning that off?
Tried that and if I turn that off and do the above steps, all of my screens go
black which does not seem to be recoverable. I see these messages in my
journal:
Jan 17 15:33:08 orionis kernel: [drm:radeon_dp_link_train] *ERROR* displayport
link status failed
Jan 17 15:33:08 orionis kernel: [drm:radeon_dp_link_train] *ERROR* clock
recovery failed

However that led me to the other option I set for the radeon driver: DRI3.
I switched to DRI2 and this issue is gone. I did see a black screen when
trying, but that was the other Plasma bug. Windows etc. show up on the screen
and can be used.

I'll report a bug upstream.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-17 Thread Thomas Lübking via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

Thomas Lübking  changed:

   What|Removed |Added

 Resolution|--- |UPSTREAM
 Status|UNCONFIRMED |RESOLVED

--- Comment #15 from Thomas Lübking  ---
(In reply to Bernd Steinhauser from comment #14)
> Around 60 fps, no change there. The left part of glxgears is still updated,
> the right part is just a static image.

Well, since it's not kwin specific, we'll have to assume it's in the GL/X11
driver ;-)

Since the uncomposited glxgears runs at 60Hz, I assume you've got (flipping
disabling)
Option "TearFree" "on"
set? (Xorg.0.log)
What about turning that off?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-17 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #14 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #13)
> If you
> - suspend the compositor
> - run glxgears
> - move it to be partially on the left and partially on the (middle) DP
> output and
> - re-attach the DP output:
> a) glxgears should still cross the screens, otherwise move it into such
> position
Yep.

> b) how much of glxgears updates?
Around 60 fps, no change there. The left part of glxgears is still updated, the
right part is just a static image.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-17 Thread Thomas Lübking via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #13 from Thomas Lübking  ---
- not even restarting the compositor (complete rebuild of GL context) "fixes"
it
- switching framebuffers (VT2 and back) fixes it

Ie. the part of the GL frontbuffer that is related to the particular output is
not updated/copied into the scanout buffer until X11 looses and regains the
framebuffer.
The screen in question is in the middle (so the context isn't too small) and a
compositor restart would cause a complete update of the entire scene in a new
GL context unconditionally.

I'm fairly sure that it's not a bug in KWin, sorry.


KWin waits briefly (like 200ms) before moving windows to the remaining
workspace, plasmashell (the desktop) might react instantly, so the static
framebuffer will be taken at a spot where plasmashell already removed the
desktop and kwin has not yet moved the firefox window.

If you
- suspend the compositor
- run glxgears
- move it to be partially on the left and partially on the (middle) DP output
and
- re-attach the DP output:
a) glxgears should still cross the screens, otherwise move it into such
position
b) how much of glxgears updates?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-17 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #12 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #11)
> That would suggest that switching the VT would alter the stack position of
> the plasma window, would it? Unlikely. Also interaction w/ the plasma window
> should work (eg. the wheel to change the virtual desktop?) and at least
> popup menus should still show up on top.
Nope, could only see the background and the mouse pointer.
Context menus don't shop up (those are popups, right?).

> 
> Also you suggested that windows moved to the dead screen are "usable" (ie.
> react to interaction, resp. can be picked with eg. Alt+LMB and dragged back)
Yes, that's possible. And not only that. I can see the pointer shape changes.
I.e. if I have this window on the dead screen and move the pointer where this
text field is supposed to be, I can see the pointer changing to the "I" shape.

(In reply to Thomas Lübking from comment #11)
> Since this is not related to the compositor, it's more likely a static
> scanout buffer on that screen, sometimes before and sometimes after a plasma
> window was moved/created there.
I just tried another thing, maybe that helps to analyze this. The test was
motivated by the popup comment above. I wanted to open a popup menu on that
screen, namely the "About" dialog of Firefox.
So I moved Firefox half way to that screen (to check if the dialog opens there
and not on the other screen) and switched off the screen. (And back on again.)
The interesting thing here was, that I could see a screenshot of where the
window was (it obviously moved after the disconnect because kwin moves windows
around if you disconnect the output they are shown on). The rest of the screen
was black.
However, this is only the case if the window at the time has focus. If I move
it there, switch to a different window and then turn the screen off and on
again, the screen is completely black.

I might be wrong, but that to me seems like a confirmation that this is a bug
in kwin and not the driver?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-16 Thread Thomas Lübking via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #11 from Thomas Lübking  ---
(In reply to Bernd Steinhauser from comment #10)

> somehow. And it seems like it creates that view with the wallpaper or the
> black screen that overlays the windows. Is that possible?

That would suggest that switching the VT would alter the stack position of the
plasma window, would it? Unlikely. Also interaction w/ the plasma window should
work (eg. the wheel to change the virtual desktop?) and at least popup menus
should still show up on top.

Also you suggested that windows moved to the dead screen are "usable" (ie.
react to interaction, resp. can be picked with eg. Alt+LMB and dragged back)

Since this is not related to the compositor, it's more likely a static scanout
buffer on that screen, sometimes before and sometimes after a plasma window was
moved/created there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-16 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #10 from Bernd Steinhauser  ---
Two more things that might be worth mentioning:
1. I switched to Console with the screen disconnected and back to see if it
occurs at well. After Reconnecting the screen, I saw screen corruption.
However, using Ctrl+Alt+F2 still fixed it.
2. Once Plasma went wild on me and hung up. Then when reconnecting the screen,
I saw the wallpaper instead of a black screen. The rest behaved as described.
Pointer was visible, could move windows there, but they don't become visible.
(Still fixable with Ctrl+Alt+F2.) This leads to the conclusion, that the
"black" part of the bug is introduced by Plasma somehow. And it seems like it
creates that view with the wallpaper or the black screen that overlays the
windows. Is that possible?

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #9 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #8)
> - What's the state when just suspending the compositor - is the screen black
> as well?
No, that works fine.
> - What if you even "kwin_x11 --replace &"
Fine.
> - Does this affect all screens or only the displayport one?
Seems like it's only that screen (an Eizo).
Neither the HDMI one nor the DVI one show that behaviour.

I think the Eizo Monitor uses DP 1.2, it's giving me a headache from time to
time anyway (i.e. the DP Connection is cut off when switching off the screen,
which is why I'm seeing this even when just leaving for 20mins). Don't know if
that is the reason, but I will try with the Dell screen which I would have to
switch from HDMI to Displayport, though. For that one I can switch DP 1.2 on
and off.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Thomas Lübking via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #8 from Thomas Lübking  ---
Sum up:
- kwin has a proper idea of the screen geometries
- not even restarting the compositor (complete rebuild of GL context) "fixes"
it
- switching framebuffers (VT2 and back) works

Smells a lot like an X11 driver issue (which only paints the cursor into the
framebuffer, but not actual X11)

- What's the state when just suspending the compositor - is the screen black as
well?
- What if you even "kwin_x11 --replace &"
- Does this affect all screens or only the displayport one?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #7 from Bernd Steinhauser  ---
(In reply to Bernd Steinhauser from comment #5)
> During the disconnect, the only difference is the removed screen:
> -Number of Screens: 2
> +Number of Screens: 3
> 
> +Name: DisplayPort-0
> +Geometry: 1920,0,1920x1200
> +Refresh Rate: 59.9502
> +
> +Screen 2:
> +-
Meh, diff in the wrong direction …

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #6 from Bernd Steinhauser  ---
Created attachment 96639
  --> https://bugs.kde.org/attachment.cgi?id=96639&action=edit
glxinfo -l

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #5 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #1)
> please dump "qdbus org.kde.KWin /KWin supportInformation" before and when
> this happens and ideally also when "resolving" the situation.
Wow, you're fast. :D

During the disconnect, the only difference is the removed screen:
-Number of Screens: 2
+Number of Screens: 3

+Name: DisplayPort-0
+Geometry: 1920,0,1920x1200
+Refresh Rate: 59.9502
+
+Screen 2:
+-

After the reconnect, the output is identical to the one before the disconnect.

> Does restarting the compositor (SHIFT+Alt+F12, twice) "fix" it?
Nope.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Martin Gräßlin via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #4 from Martin Gräßlin  ---
can you please also output glxinfo -l

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #2 from Bernd Steinhauser  ---
Created attachment 96637
  --> https://bugs.kde.org/attachment.cgi?id=96637&action=edit
Log output when changing the screen

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Bernd Steinhauser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #3 from Bernd Steinhauser  ---
Created attachment 96638
  --> https://bugs.kde.org/attachment.cgi?id=96638&action=edit
qdbus-qt5 org.kde.KWin /KWin org.kde.KWin.supportInformation

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 357988] Black screen when reconnecting display

2016-01-14 Thread Thomas Lübking via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357988

--- Comment #1 from Thomas Lübking  ---
please dump "qdbus org.kde.KWin /KWin supportInformation" before and when this
happens and ideally also when "resolving" the situation.

Does restarting the compositor (SHIFT+Alt+F12, twice) "fix" it?

-- 
You are receiving this mail because:
You are watching all bug changes.