[konsole] [Bug 365339] Several seconds delay switching to certain tabs

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365339

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361241

--- Comment #7 from Bernd Steinhauser  ---
At least on my system (5.7.x) I can't reproduce the bug anymore.

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

[kwin] [Bug 361151] (Enhancement) Implement changing the mouse acceleration profile of libinput in Wayland.

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361151

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

[systemsettings] [Bug 350688] Mouse acceleration setting has no effect with libinput

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=350688

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #8 from Bernd Steinhauser  ---
The kcm only supports evdev.

Now that libinput (and xf86-input-libinput) or getting pretty much standard,
sooner or later support for this will be implemented, I guess.
Especially since libinput is now claimed as being complete (for the moment).
See bug 361151 as well.

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

[plasma-pa] [Bug 352042] Plasma Audio Applet Should Include Per App Volume Levels

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352042

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #5 from Bernd Steinhauser  ---
Maybe you could add it to the systray app as well?
I find it very annoying to have to open the applet using right click and
selecting audio volume settings.

It's the one reason why I still use kmix, because it is just easier faster to
readjust the volume of an app.

Also from a UI perspective, I would rather use vertical sliders like kmix does.
This is especially helpful if there are many sliders. Remember, that most
screens are widescreen these days.
Thus, they align better.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #28 from Bernd Steinhauser  ---
Just to give you some numbers, I let this system run for approximately one day.
During this time, plasmashell (in two threads) on average consumed 20% of one
CPU.
It was then on rank 1, right before Xorg with approx. 15%.

The third process would go to kwin, but that was already only at 2%.

I still have no idea what exactly plasmashell is doing. Help to find out would
be appreciated, because I don't think that this would be normal, to me the
numbers appear to be too high.

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #118 from Bernd Steinhauser  ---
Should add: I started with a new plasma config and a single panel, then
connected/disconnected a display multiple times.

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #117 from Bernd Steinhauser  ---
Tested Qt 5.7.0 + Plasma 5.6.95 and still get this.

So maybe part of the fix is in place, but some part is still missing.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #27 from Bernd Steinhauser  ---
Just wanted to note that I still see this with 5.6.95 and it feels like it
actually got worse.
A lot of stuttering due to plasmashell's high CPU load.

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

[KScreen] [Bug 346961] Multi Monitor configuration lost on reboot, must reconfigure after startup

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346961

--- Comment #53 from Bernd Steinhauser  ---
You're going much too far. It's sufficient to remove the writable attribute.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #26 from Bernd Steinhauser  ---
Should note: I don't have any rotated screens.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #25 from Bernd Steinhauser  ---
Hm, bug 362247 gave me an idea.

Normally, I'm using the following driver options for either amdgpu or radeon.
The driver that is used does not matter the behavior is the same:
Option  "TearFree" "On"
Option  "EnablePageFlip" "Off"
Option  "DRI" "3"

Note, that TearFree does imply disabling EnablePageFlip, so I'm kind of
duplicating here.
The man page says about TearFree:
»Enable tearing prevention using the hardware page flipping mechanism. This
option currently doesn't have any effect for CRTCs using transforms other than
rotation or reflection. It requires allocating two separate scanout buffers for
each supported CRTC. Enabling this option currently disables Option
"EnablePageFlip". The default is off.«

So what I now tried is the following setup:
Option  "TearFree" "Off"
Option  "EnablePageFlip" "On"
Option  "DRI" "3"

This does not remove the behavior, but change it. The laggy behavior can only
be observed the panel on the left screen (which is the primary screen, if that
matters) and not on the right screen.
(Might not be perfectly smooth there either but if so it's really a minor
effect.)

The bouncing cursor start effect still causes lag on every screen, but other
things like context menus, opening new tabs in firefox etc. perform normally
now.
It's mainly that one panel and the bouncing cursor where I observe the problem.
(Even if a busy cursor is not selected in the settings.)

Next I'll test with both TearFree and PageFlip disabled.

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

[plasmashell] [Bug 353975] Black screen on second display.

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=353975

--- Comment #22 from Bernd Steinhauser  ---
I have only "external" screens (not everybody's using a laptop :P). And they
have a resolution of 1920x1200.

I'd say: Wait for Plasma 5.7 and see if it's still there, because it was said
that when they can depend on Qt 5.6 (thus the next version) the multiscreen
handling should improve.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #24 from Bernd Steinhauser  ---
For testing purposes, I downgraded Plasma to 5.5.5. I do still see the same
behavior.
I'm pretty sure that I didn't see it previously when I ran 5.5.x, because a
laggy behavior like this I would've noticed.

As I upgraded to Plasma 5.6 together with Qt (to 5.6 as well), I guess this is
a bug that was triggered by a change in Qt, since I'm now running Plasma 5.5 on
top of Qt 5.6.

I'm not sure if I'm going to test that, though, since downgrading Qt on a
source-based distro is really really painful.

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

[plasmashell] [Bug 353975] Black screen on second display.

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=353975

--- Comment #19 from Bernd Steinhauser  ---
You can have the bug with other resolutions as well and also if the screens
have the same resolution.
The resolution doesn't matter as far as I can tell.

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

[konsole] [Bug 358560] Konsole crashes when I unplug a second monitor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358560

--- Comment #6 from Bernd Steinhauser  ---
I have not seen any issues with konsole crashing or disappearing when
disconnecting a screen during the last two months or so.

I think that this was (somehow?) fixed. Maybe you can confirm.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #23 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #22)
> Smells related to the new feature to show progress in taskitems?

Is there a way to test that? Can I build plasma without it?

Would a bisect help?

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

Bernd Steinhauser  changed:

   What|Removed |Added

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

--- Comment #18 from Bernd Steinhauser  ---
Ok, I'm closing this as an upstream bug.
In February I tried some more configs, but could not track it down to something
specific. The configurations didn't seem to change the behaviour.

After upgrading mesa and the kernel, I haven't seen this anymore. I've seen
freezes happening, but those always happened when a video was running, thus
seem to be related to that.
Currently I'm using the amdgpu driver and with that I haven't seen a freeze at
all no matter what settings I'm using.

Thus, I'm pretty certain now that if it still happens, it's an upstream bug in
the radeon/radeonsi driver.
And if so, it was likely fixed.

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

[kmahjongg] [Bug 361132] kmahjongg 16.04 fails to start after migrating KDE4 configuration

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361132

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361241

--- Comment #3 from Bernd Steinhauser  ---
That fixes the problem, thanks.

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

[kwin] [Bug 361241] Double click to maximize does not work in some situations

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361241

--- Comment #1 from Bernd Steinhauser  ---
Forgot to mention:
I ran kwin at commit id ed1d32288b50647469fb0e000f21b849e286ca36 to test this.
When using kwin at 95cbd7c1b3cdbe81fdee1682049bd08ab7fe99fb (parent), I cannot
reproduce it at all (or at least the above does not work when trying about 10
times).

Also present in 5.6.1.

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

[kwin] [Bug 361241] New: Double click to maximize does not work in some situations

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361241

Bug ID: 361241
   Summary: Double click to maximize does not work in some
situations
   Product: kwin
   Version: 5.6.1
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: li...@bernd-steinhauser.de

As mentioned in bug 360137, I sometimes see the issue of kwin not responding to
a double click on the window title decoration, which in my setup should
maximize the window.
I finally was able to find a way to reliably reproduce (see below) the issue
and track it down.
I was already pointed at
https://quickgit.kde.org/?p=kwin.git=commit=ed1d32288b50647469fb0e000f21b849e286ca36
and indeed that commit causes the issue to appear.
For reference, see bug 357450, which was fixed by the referenced commit.
bug 345473 seems unrelated as I'm only seeing the problem under certain
circumstance, most of the time it works.

Reproducible: Always

Steps to Reproduce:
1. Open a window, ensure it is not maximized.
2. Double click on the title, the window should maximize as expected
3. Double click to unmaximize, should work as expected
4. Click on the desktop containment / desktop background
5. Click on the window title once(!), don't move the cursor
6. Wait for at least 0.2 s
7. Double click on the window title, no response
>From here on, it doesn't seem to work reliably:
8. Wait for a second
9. Double click again, no response
etc.



• Only double click seems to be affected. Right click/wheel etc. work as
expected.
• The action that is linked to double click does not matter, shade etc. behave
the same.
• I chose "Happens every time", but I'm not sure if it is 100%, at least with
the procedure above I can reproduce it at least 9 times out of 10.
• The "Don't move the cursor" part is not strictly necessary, but it seems to
me like it increases the chance for this to happen. But I've seen it with
moving the cursor as well and I even saw this with  clicking inside a textbox
while the app is active like this one right here and then trying again, thus I
think the trigger has something to do with the app changing focus.
• If you don't double click but instead triple click, the window will maximize.

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

[kwin] [Bug 360719] Secondary user actions popup remains visible

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360719

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #13 from Bernd Steinhauser  ---
Can confirm this. Problem is that it happens randomly and thus is hard to
track.
I've often seen this happening when using the "Move to Screen" menu.

The glitch does also go away if the same menu is used again (maybe the bug
reporter can confirm that?).

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

[kwin] [Bug 361091] Translucency lost when starting video using mpv bypassing the compositor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361091

--- Comment #10 from Bernd Steinhauser  ---
Maybe that will be a bit out of reach of this bug, but would the situation be
better on wayland, especially when talking about video (i.e. mpv)?

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

[kwin] [Bug 361091] Translucency lost when starting video using mpv bypassing the compositor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361091

--- Comment #7 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #1)
> _NET_WM_BYPASS_COMPOSITOR isn't specified for unredirection (leaving aside
> that the specification is horrible in every aspect...)
> 
> This happens because of https://git.reviewboard.kde.org/r/126561/
> 
> The behavior is intended (whether or not and when or not media players
> should set that hint is a matter of its own)
> Also compare bug #349910
Thanks for the explanation. To  me that sounds very weird, but understandable.
I'm not sure that bypassing the compositor here is a good idea, despite the
explanation by wm4 regarding mpv.

> You can still use window rules to override the hint (force composite
> blocking to false) if mpv doesn't provide a setting for this.
mpv does have a setting as described above. It defaults to bypassing the
compositor since a few months.

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

[kwin] [Bug 361091] New: Translucency lost when starting video using mpv bypassing the compositor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361091

Bug ID: 361091
   Summary: Translucency lost when starting video using mpv
bypassing the compositor
   Product: kwin
   Version: 5.6.0
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: effects-various
  Assignee: kwin-bugs-n...@kde.org
  Reporter: li...@bernd-steinhauser.de

Tried with OpenGL 2.0 and 3.1, XRender, EGL, GLX, all the same.
Transparancy comes back when mpv exits or when the compositor is restarted or
the backand is changed.

It seems like it only happens when x11-bypass-compositor is enabled, which is
explained as:
"If set to yes (default), then ask the compositor to unredirect the mpv window.
This uses the _NET_WM_BYPASS_COMPOSITOR hint."
Thus, I've not seen it with other players like vlc, firefox html5 video or
ffplay, which don't seem to make use of that hint.
It could also be a bug in mpv.

Reproducible: Always

Steps to Reproduce:
1. Enable the Translucency effect, ensure it works 
2. Start a movie using mpv. Video output does not matter (tested xv, x11, vdpau
and opengl)
3. Check if Translucency works
4. Quit mpv
5. Check if Translucency works

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

[plasmashell] [Bug 360621] plasmashell hangs when moving panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360621

--- Comment #5 from Bernd Steinhauser  ---
Yes, looks good. Haven't seen it yet, at least. If so I'll let you know.
Thanks.

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #54 from Bernd Steinhauser  ---
(In reply to Theresa from comment #53)
> I have my laptop connected to a HDMI monitor as well, as soon as I press the
> "power off" button when I take a break/lunch break... the panel/taskbar
> disappears. If I'm lucky to panel is moved to the VGA monitor which I
> sometimes also connect. If the VGA monitor is disconnected then the panel is
> completely gone, until I log out/reboot.
> This definitely doesn't seem like normal behaviour to me, when I just
> power-off the monitor (I am not even unplugging the cable).
Some newer screens do that. I think it's part of a newer specification.
It's very annoying, especially since one of my screens even cuts the connection
if you switch to a different input, which is very very annoying if you use a
monitor for two computers (e.g. desktop and laptop).
> 
> Is there a workaround for this problem?
Sometimes there are configuration options. My Dell has a setting "Displayport
1.2" that (among other things?) controls this behavior.
My Eizo has a hidden control menu where you can adjust settings that change it
for both Displayport and HDMI.

Either way, the desktop has to be able to cope with that, since screen layouts
do change in reality, especially for mobile computers.
But I guess everybody here knows that. ;)

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #51 from Bernd Steinhauser  ---
Something that never happened before to me:
Yesterday, plasmashell moved both panels to one screen, so far normal.
Today, both panels are gone. Possibly moved somewhere I can't see them.
Changing the screen config doesn't bring them back.

If I add a default panel to the screen where they were last, plasmashell adds
the panel on top, thus expecting a panel at the bottom. But there is nothing
there.

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #48 from Bernd Steinhauser  ---
(In reply to cherenz from comment #45)
> (In reply to Bernd Steinhauser from comment #44)
> > This is getting repetitive. The bug is not fixed by Qt 5.6, it's not fixed
> > by KF5 5.20 and neither Plasma 5.5.95.
> > 
> > If you don't see, you're lucky (congrats), but the bug is still there, as
> > pointed out above.
> 
> However, it is interesting to see that some users seem not to be affected
> anymore. Right?
Depends. There could be multiple issues. I too noticed, that the panel movement
seems to be a bit more stable, but it does still switch them around
nevertheless.

Especially, I still get the effect that two panels from two different screens
end up on exactly the same screen, which in my opinion makes no sense. I could
understand if screens are swapped, but this is something else.

In the end, there could be a lot of reasons why some people don't see it
anymore and others still do.
Configuration, screen setup, version of software XY etc.

I tried with Qt 5.6 (with those mentioned 3 patches to QtDBus applied), with
Plasma 5.6 on KF 5.20 with a clean plasma app config and I can still reproduce
it, but as Nakato mentioned, it seems to be *a bit* more stable.

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #37 from Bernd Steinhauser  ---
Nope, been using Qt 5.6 for 2-3 weeks now and it did not improve things.
Neither the -rc, nor the release version.

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

[plasmashell] [Bug 360621] plasmashell hangs when moving panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360621

--- Comment #2 from Bernd Steinhauser  ---
Yes, all three patches were applied before building Qt 5.6.0.

Does not matter for this one, though. This happens with and without the
patches.

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #34 from Bernd Steinhauser  ---
This got actually worse with 5.5.95. Not sure about the desktop, because I gave
up on using wallpapers, because plasmashell will do whatever it wants with them
anyway.
However, it is really impressive with what accuracy and determination,
plasmashell moves two panels that were on different screens onto the same
screen after reboot.

I mean I can understand if screen numbering gets messed up and things that
should be on screen X end up on screen Y and the other way round. But just
putting everything on screen X and nothing on screen Y? Why?
It really feels like there is no concept of remembering where things were when
shutting down.

Also interesting is that it constantly complains about 
"requesting unexisting screen 3"
when nothing in .config/plasma-org.kde.plasma.desktop-appletsrc has an entry
that could be related to a "screen 3". Everything in there says -1, 0, 1 or 2.
The other plasma config files don't mention screen 3 either, afaics.
Not sure what's going on, or is it just that some parts of plasma count from 0
and some count from 1?
Well then I could understand if it gets confused by itself. ;)

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

[plasmashell] [Bug 360621] New: plasmashell hangs when moving panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360621

Bug ID: 360621
   Summary: plasmashell hangs when moving panel
   Product: plasmashell
   Version: 5.5.95
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Panel
  Assignee: plasma-b...@kde.org
  Reporter: li...@bernd-steinhauser.de

Have not seen this happening in Plasma 5.5, but only since 5.5.95.
I should mention, that I performed the upgrade to Qt 5.6 at the same time,
currently it's the release version 5.6.0.

I have to move panels around quite often, because plasmashell keeps placing
them on the wrong screen. (There is a bug report about that and I'm CCed on
it.)

Reproducible: Sometimes

Steps to Reproduce:
1. Open the panel settings
2. Click on "Screen Edge" and drag the panel around
3. Dragging the panel to a different screen seems to trigger the bug more
often, as well as changing to horizontal/vertical layout. (right/left edge
instead of top/bottom edge) I have seen it on the same screen as well, though.

Actual Results:  
The panel movement gets stuck in between, panel background and settings
background are painted, but not the panel content.
plasmashell does not respond anymore (neither panel, nor desktop) and has to be
killed.

Expected Results:  
Should work

The last messages from the journal:
Mar 16 18:43:18 orionis plasmashell[1160]: Both point size and pixel size set.
Using pixel size.
Mar 16 18:43:18 orionis plasmashell[1160]: Both point size and pixel size set.
Using pixel size.
Mar 16 18:43:19 orionis plasmashell[1160]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/batterymonitor.qml:
QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling.

The last one 12 times.

Then the log is spammed with this message:
Mar 16 18:43:19 orionis plasmashell[1160]: QTransform::translate with NaN
called

Until I kill plasmashell.

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

[KScreen] [Bug 360430] kscreen randomly rewrites screen configuration

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360430

--- Comment #5 from Bernd Steinhauser  ---
As I don't see this every time, I guess there is a race going on.

To me, it looks like kscreen tries to look for a config, when some daemon or
backend is sometimes not available to retrieve the config (e.g. kded or
kdeinit).
Then it tries a best guess at the screen config and writes that config to disk
(at that time, the backend/daemon/whatever would be available, because it
happens a bit later).

Since I'm not good at understanding c++ and since I don't know kscreen in
detail, that's just speculation.
However, I remember from times where loading a config was successful, that
there are lines in the log telling you that it found a config and tries to
apply that.
When the config gets rewritten, I can't find such lines in the log, but there
aren't logs about something failing either. Other than the lines about some
xrandr, but iirc that's normal (since there are multiple ones).

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

[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #44 from Bernd Steinhauser  ---
This is getting repetitive. The bug is not fixed by Qt 5.6, it's not fixed by
KF5 5.20 and neither Plasma 5.5.95.

If you don't see, you're lucky (congrats), but the bug is still there, as
pointed out above.

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

[KScreen] [Bug 360430] kscreen randomly rewrites screen configuration

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360430

--- Comment #3 from Bernd Steinhauser  ---
It's easier to remove write access to the file, but that still does not solve
the problem at all.

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

[plasmashell] [Bug 360173] Plasma freeze sometime with notification & high load CPU and RAM

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360173

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #8 from Bernd Steinhauser  ---
I get this quite often. It's often accompanied by a message like this:
plasmashell[1443]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.systemtray/contents/ui/CompactRepresentation.qml:88:9:
QML TaskDelegate: Binding loop detected for property "height"
or 
plasmashell[1443]:
file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/configuration/PanelConfiguration.qml:78:5:
QML ToolBar: Binding loop detected for property "implicitWidth"

and sometimes I see a lot of these messages afterwards:
QTransform::translate with NaN called

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #20 from Bernd Steinhauser  ---
hw accel for firefox does not make a significant difference.
Tab changing in konsole, kate can also be used to trigger the stuttering.

To me it seemed like it might have something to do with window management, so I
tried different options for the switchers (including turning both main and
alternative off), but it didn't change anything, at least immediately. So
that's not it.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #17 from Bernd Steinhauser  ---
Well, there is definitely something wrong with kwin as well, but I have yet to
find out the details.
For example, sometimes it does not respond to a double-click on the window
decoration, which should lead to a maximization (can try 3 times and I'm surely
fast enough). After dragging the window a bit and trying again, it works
instantly.

But it's interesting that there seem to be quite a few triggers for the cursor
lag and afaics it's always accompanied by a strong increase in plasmashells cpu
usage. It's also interesting to see that it's always in two processes
simultaneously: The first and second started process (thread?).
One of the triggers I found for example: Fiddling around with firefox,
sometimes bringing up a tooltip or context menu results in such stuttering. I
have no idea why plasmashell would be involved there.
Even loading a new website or just opening a new tab results in a strong
increase in plasmashell's cpu usage accompanied by the cursor lag.
Why? Maybe, just maybe I could understand if it would be related to an
compositing effect, but it happens without compositing as well.

This is all very, very strange.

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

[KScreen] [Bug 360430] kscreen randomly rewrites screen configuration

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360430

--- Comment #1 from Bernd Steinhauser  ---
Created attachment 97851
  --> https://bugs.kde.org/attachment.cgi?id=97851=edit
screen configuration

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

[KScreen] [Bug 360430] New: kscreen randomly rewrites screen configuration

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360430

Bug ID: 360430
   Summary: kscreen randomly rewrites screen configuration
   Product: KScreen
   Version: 5.5.95
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: common
  Assignee: se...@kde.org
  Reporter: li...@bernd-steinhauser.de

I've seen this a lot since 5.5.95. I'm not sure if I saw it before, if so then
it happened only rarely.

I have a screen configuration with three screens. I will attach it to the bug.
The x positions of the screens should be 0, 1920 and 3840 and are correctly
assigned in the config file.
At startup, all three screens are connected (seeing the sddm login screen on
all three).
After login, I'm presented with a clone setup and find in the file above the x
position 0, 0 and 0.
If I disconnect one of the screens (thus a different config file gets loaded),
change the file so the correct x positions are in there and reconnect the
screen, the file is loaded as it should and the correct screen setup is done.

The only messages in journal I could find are:
Mar 12 10:02:14 orionis kscreen_backend_launcher[1119]: kscreen.xrandr:
Connected output 83 to CRTC 79
Mar 12 10:02:14 orionis kscreen_backend_launcher[1119]: kscreen.xrandr:
Connected output 85 to CRTC 80
Mar 12 10:02:14 orionis kscreen_backend_launcher[1119]: kscreen.xrandr:
Connected output 86 to CRTC 81
Mar 12 10:02:14 orionis kscreen_backend_launcher[1119]: kscreen.xcb.helper:
Detected XRandR 1.4
Mar 12 10:02:14 orionis kscreen_backend_launcher[1119]: kscreen.xcb.helper:
Event Base:  88
Mar 12 10:02:14 orionis kscreen_backend_launcher[1119]: kscreen.xcb.helper:
Event Error:  145

Then there are some detail messages about the connected screens (layout,
rotation etc.), but nothing interesting there.
Interesting part is that I can't find something in the logs about loading or
saving a screen configuration, but this must have happened since the config
file was changed.
IIRC, the respective log lines should come from kded5 or kdeinit5.

Reproducible: Always

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #15 from Bernd Steinhauser  ---
Yes, I'm sure about that. I will see if I can reproduce it somehow.
Is there a way to find out *what* kwin or plasmashell are doing when those
issues occur?
gdb?

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #13 from Bernd Steinhauser  ---
I'm not sure, but it could be related:
Yesterday, after letting the system run for 1 day without restarting anything
desktop-related, I observed a stuttering performance when playing a video. For
that, it did not matter if it was a video inside a browser (e.g. youtube) or a
file played by a media player.
Restarting plasmashell did not help, but restarting kwin did. (Suspending
compositing did not help either.)

Thus, whatever causes these performance issues, it could be that kwin is
affected as well, i.e. if it has something to do with the dbus changes in Qt
5.6?

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

[frameworks-kded] [Bug 360245] kded crashing with Qt 5.6.0-rc

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360245

--- Comment #3 from Bernd Steinhauser  ---
Thanks for that hint. building polkit-qt scm did actually fix kded and other
things improved as well (i.e. kmix and akregator weren't showing up in the
systray).

Maybe it would be a good idea to make a new release of polkit-qt targeting qt
5.6.

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

[plasmashell] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #10 from Bernd Steinhauser  ---
kded crashes and therefore is not running. See bug 360245.

I've had it running a couple of times and then it complained about blocking
dbus calls.

btw, I haven't seen memory consumption of either kwin or plasmashell increasing
over time. That said, it did increase, but only from around 200M to 280M, which
shouldn't be problematic.

Anyway, I guess it's safe to reassign this to plasmashell. From all I've seen
so far, it seems very unlikely, that this is kwin's fault.

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

[frameworks-kded] [Bug 360245] New: kded crashing with Qt 5.6.0-rc

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360245

Bug ID: 360245
   Summary: kded crashing with Qt 5.6.0-rc
   Product: frameworks-kded
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: afies...@kde.org
  Reporter: li...@bernd-steinhauser.de
CC: kdelibs-b...@kde.org

Since updating to Qt 5.6.0-rc, I get a reproducible crash in kded leading to
misbehaviour of the desktop. See the attached log.

I've tried with two upstream Qt patches:
https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=6729ec8d39a7f17308b7178bed23084e52bc0231
and
https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=f7106a1efa98156c7f1276665c673000e6131c05

But afaics, it did not improve things.

Reproducible: Always

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

[frameworks-kded] [Bug 360245] kded crashing with Qt 5.6.0-rc

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360245

--- Comment #1 from Bernd Steinhauser  ---
Created attachment 97757
  --> https://bugs.kde.org/attachment.cgi?id=97757=edit
Output of coredumpctl

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

[kwin] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #8 from Bernd Steinhauser  ---
I meant plasmashell. It's interesting to see how, the plasmashell cpu usage
instantly peaks to 70-100% when moving the mouse. Given that's only the usage
of one cpu (so total would be 400% on this quadcore system) that's not too bad,
but it looks like the usage is increasing over time.

Regarding memory consumption, at least after the start the memory consumption
is reasonable (approx. 200M in column "M_RESIDENT" of htop).
I will let it run for a couple of hours and see if things get worse.

Another thing that I've noticed is that applications seem to have issues
talking to kded since I upgraded to qt 5.6.0-rc.
This already led to kmix and akregator not showing up in the systray and
possibly other issues.

Not sure how plasmashell works internally and if it needs kded here, but maybe
it should be considered that the issues are related.

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

[kwin] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #6 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #5)
> (In reply to Bernd Steinhauser from comment #4)
> 
> > So it looks more like it's a plasma bug. Theory: plasma temporarily consumes
> > a huge amount of cpu time which leads to kwin or X starting to lag for a
> > short time.
> 
> Could be, but doesn't explain the difference between GLX and EGL (unless
> you're not actually running EGL but failsafe to uncomposited or render - I
> don't think so, though) - how about xrender, btw?
xrender is the same. Might be slightly slower, but the lags are the same.
Regarding the difference between GLX and EGL, that might be the implementation
in mesa, don't know.

> Next test would be to deactivate all effecs in "kcmshell5 kwineffects" - or
> go for the simpler way:
Or even simpler: Just switch of compositing:
Compositing
===
Compositing is not active
It's actually a bit embarrassing that I didn't try this before. Anyway, even
with compositing switched off, I see the lags, so it's safe to say that it's
unrelated to compositing. 

> Preferred candidates:
> slidingpopups
> kwin4_effect_morphingpopups
> kwin4_effect_fade
> blur
> contrast
Despite the above I tried specific effects and didn't find any of them to make
a difference.

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

[kwin] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #4 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #3)
> > the cursor jumps for 1 to 1.5 seconds
> The cursor should be done in hardware and painted directly into the scanout
> buffer.
> 
> Does any other item in the panel cause this?
Yeah, I noticed that especially items showing tooltips when hovering over them
show this behavior, but it's not as easy to notice because the area of those
widgets is small compared to the task manager.
Items I found to cause lag: Menu (currently kickoff), Desktop Switcher, Task
Manager and the panel settings symbol.
However, not all of them do. The systray does not seem to be affected and
neither is the clock.

I also don't notice this right away, it gets worse over time and after a couple
of hours there is a strong effect.
Right after (re-)starting plasma, everything looks normal.
So it looks more like it's a plasma bug. Theory: plasma temporarily consumes a
huge amount of cpu time which leads to kwin or X starting to lag for a short
time.

> 
> Let's say I simply completely distrust QML.
> Please edit
> /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml
> and comment 
> 
> // toolTipItem: toolTipDelegate
> 
> and 
> 
> //ToolTipDelegate {
> //id: toolTipDelegate
> 
> //visible: false
> //}
> 
> restart plasmashell and check again.
Nope, that didn't help. The task manager still behaves the same.

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

[kwin] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

--- Comment #2 from Bernd Steinhauser  ---
Created attachment 97698
  --> https://bugs.kde.org/attachment.cgi?id=97698=edit
glxinfo

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

[kwin] [Bug 360137] Low performance when moving mouse cursor over task manager tabs in panel

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360137

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

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

[KScreen] [Bug 360113] New: Configured and Applied Screen Config do not match

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360113

Bug ID: 360113
   Summary: Configured and Applied Screen Config do not match
   Product: KScreen
   Version: 5.5.95
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: kcm
  Assignee: se...@kde.org
  Reporter: li...@bernd-steinhauser.de

I'm on 5.5.95, but I've seen this since 5.4 at least.

As kscreen does not (always) respect the saved config, I have to reconfigure my
screens quite often and then this happens:
1. Move all screens (DP-0, HDMI-0 and DVI-0) to the correct position, select
primary output (DVI-0)
2. Ensure that the screen positions are (0,0), (1920,0) and (3840,0) as shown
by the position info of kscreen
3. Apply the config
4. Notice that the screens are not aligned vertically (i.e. by trying to move
the mouse cursor along the top)
5. Go back to the kcm, notice that the vertical positions of the screen are now
different, i.e. the middle screen is at (1920,40), but doesn't have to be that
position exactly, the offset could be different.
6. Move the middle screen to the correct position
7. Apply the config
8. Notice that the screen's are still not aligned properly
9. Go back to the kcm, notice that (e.g.) the left screen is now misaligned
10. Align that
Etc.

If I'm lucky, I can get it set up within 2 tries, but if I'm unlucky, I'll
spend 5min trying to align the screens.

I really wonder how hard can it be? :(

I'm not sure what additional info to provide.

Reproducible: Always

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

[KScreen] [Bug 356884] kscreen messes with original xrandr config, does not respect saved config, and apply defined config only on the second try.

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356884

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

[KScreen] [Bug 346961] Multi Monitor configuration lost on reboot, must reconfigure after startup

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346961

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

[konsole] [Bug 358560] Konsole crashes when I unplug a second monitor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358560

--- Comment #5 from Bernd Steinhauser  ---
Right, but killing it will also kill processes running in the konsole session,
which I really would like to avoid.

Anyway, maybe this should be moved into a separate bug, because this one
actually talks about konsole crashing, while what you and I observe is konsole
disappearing due to the disconnect or reconnect.

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

[plasmashell] [Bug 336570] Task list not updated in multiscreen setup

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=336570

--- Comment #19 from Bernd Steinhauser  ---
Ok, was a bit fast there. I missed, that you have to come from the side of
showing only tasks from the current screen on all screens featuring a task
list.
It does work if you let one stay with the feature deactivated and only activate
for one of them.
As soon as you activate it for both (or all of them) and then change it back,
it starts to go wrong.

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

[kdelibs] [Bug 154839] Allow alternate shortcuts in list of global shortcuts

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=154839

--- Comment #18 from Bernd Steinhauser  ---
In Plasma 5 at least this feature is present, so I guess this can be closed.

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

[plasmashell] [Bug 341674] High CPU load when using second panel in multiscreen setup

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=341674

Bernd Steinhauser  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #29 from Bernd Steinhauser  ---
Retested with 5.5.5 and things look much better now. CPU load is still a tad
higher with multiple panels, but it doesn't raise over time and doesn't consume
100% of a cpu core. Thus closing with worksforme.

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

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

[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.

[plasmashell] [Bug 336570] Task list not updated in multiscreen setup

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=336570

--- Comment #18 from Bernd Steinhauser  ---
I didn't really try this, because multiple panels for me caused massive
performance issues (opened a bug for that), so I couldn't use them.

Now that you mentioned it, I tried again at it seems to work for me, so somehow
it got fixed, I guess. Didn't try for long, though.

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

[konsole] [Bug 358560] Konsole crashes when I unplug a second monitor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358560

--- Comment #2 from Bernd Steinhauser  ---
I did notice, that for me, it's not actually crashing, but konsole just
disappears (as in not visible anymore).

The process is reparanted to init and childs run until I kill konsole.

That's also why drkonqi doesn't appear.

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

[kwin] [Bug 343661] stops drawing window content after some time, likely SyncObject related

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343661

--- Comment #57 from Bernd Steinhauser  ---
Can confirm, that KWIN_EXPLICIT_SYNC doesn't change the behavior.

However, I noticed that it might be a bit driver-dependent. For my GPU (AMD
Kaveri), I can use two different KMS drivers: radeon or amdgpu
(mesa driver is in both cases radeonsi, ddx is xf86-video-ati or
xf86-video-amdgpu)
When I use amdgpu with vdpau, I see this exact behavior *every* time I open a
video with mpv and I see it a lot more often with other windows ("normal"
windows without any video output). With xvideo, it does happen, but not always.
When I use radeon I do see the problem, but only occasionally and most of the
time with video output (e.g. firefox or mpv, although with the latter I think
I've only seen it with xvideo).

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #17 from Bernd Steinhauser  ---
Last time it happened I forgot to enable ssh before, so I could not check.
After that I started testing the setting mentioned above and it didn't happen
again.
I will reenable translucency and see if I can reproduce the bug and ssh into
the system. Unfortunately, I'm not using radeon as a module, so reloading it
won't be possible unless I recompile my kernel.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #15 from Bernd Steinhauser  ---
Ok, tried to reproduce the quick-tiling thing in two ways:
1) Using shortcuts for quick tile left, right and top
2) Dagging the window quickly (works best in the top corner where kwin switches
between side, top-side and top)

Neither of these had any effect other than the window jumping around as it
should. There was no freeze and I do not observe the behaviour described in
that bug.

So I'm pretty sure this one is different.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #14 from Bernd Steinhauser  ---
Looking at that bug it seems different to me in that for me it leads to a
complete freeze (cannot even kill X with sysrq+k (security access key). For
allan, things seemed to get working again once he switched to VT7 and back.

Will try to repoduce by using the snapping functions and if that happens, try
to ssh and gdb the thing.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #12 from Bernd Steinhauser  ---
(In reply to Bernd Steinhauser from comment #11)
> (In reply to Thomas Lübking from comment #10)
> > > layers.acceleration.disabled false
> > layers.acceleration.disabled true
> This is the first thing I'm trying and so far it looks good, I haven't had a
> freeze since. Will require some more time to be sure, though.
Was wrong here. The day after I wrote this, I had a freeze with a completely
unrelated non-gtk and non-Qt application. (It's actually a java one.)
The acceleration in FF was disabled at the time.

So this was not it. The next thing I tried was this:
> > kwin4_effect_translucency
> Try to disable this.
I've disabled this since the 15th of January. I've been happily dragging
windows around and I haven't seen a freeze since then.
Since that was over 2 weeks ago, I think it's relatively safe to so that the
issue was caused by the translucency effect. Of course this means that without
the compositor enabled this should not happen and this
> I think (but I'm not sure here), I've even tried with the compositor switched 
> off
would have been wrong?

Are there special OpenGL extensions that translucency requires? Maybe I could
have a look at the kernel/mesa changes related to that and see if there were
changes that could cause this kind of behavior?

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

[konsole] [Bug 358560] Konsole crashes when I unplug a second monitor

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358560

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #1 from Bernd Steinhauser  ---
Can confirm this. I've seen this for quite some time, but since for me drkonqi
does not appear I just wondered why my konsole displays disappear.
The programs running in there continue to do so, but konsole itself is gone.

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

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

[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

[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

[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

[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 342326] window contents freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=342326

--- Comment #28 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #26)
> vdpau specific: does it 
> a) start to update when you suspend the compositor
> b) still update when you resume the compositor afterwards?

Not sure if that matters, but for xv video output, both a) and b) can be
answered with yes. Trying with vdpau again, now.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #11 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #10)
> > layers.acceleration.disabled false
> layers.acceleration.disabled true
This is the first thing I'm trying and so far it looks good, I haven't had a
freeze since. Will require some more time to be sure, though.
> Isn't double negation a pleasure for everyone? ;-)
Oh yeah … ;)

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

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

[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] New: Black screen when reconnecting display

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357988

Bug ID: 357988
   Summary: Black screen when reconnecting display
   Product: kwin
   Version: 5.5.3
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: li...@bernd-steinhauser.de

This sounds very similar to bug 353975, but I'm pretty sure, that there are two
bugs, one in plasmashell and one in kwin or X11 or driver. bug 356322 could be
related as well but is for 4.x

The bug in plasmashell causes one screen to misbehave, there is no desktop
background shown, no context menu available etc., but windows can be moved
there and are usable.

The bug in kwin behaves different. The screen is completely black, only the
mouse pointer is visible if moved there. Windows can be moved there, but will
not show up.
Neither `kwin_x11 --replace` nor a restart of plasmashell will fix this.
Suspending compositing does not help either.
It will however be fixed when switching to the console (i.e. Ctrl+Alt+F2) and
back.
There is no flickering when doing so.

Currently, it happens every time I disconnect and reconnect the screen, but
I've also seen a rate of approx. 50% 2 or 3 weeks ago.

Reproducible: Always




The driver is the radeonsi driver. mesa is currently scm, but have seen this
with 11.x as well.
Kernel is 4.4, xorg-server is at 1.18.0.

These are the messages I get when disconnecting the screen. Upon reconnection,
there are no messages from kwin directly:
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47691, resource id:
12582942, major code: 19 (DeleteProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47693, resource id:
12582942, major code: 19 (DeleteProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47694, resource id:
12582942, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47695, resource id:
12582942, major code: 19 (DeleteProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47696, resource id:
12582942, major code: 19 (DeleteProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47697, resource id:
12582942, major code: 19 (DeleteProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47698, resource id:
12582942, major code: 7 (ReparentWindow), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47699, resource id:
12582942, major code: 6 (ChangeSaveSet), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47700, resource id:
12582942, major code: 2 (ChangeWindowAttributes), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 47701, resource id:
12582942, major code: 10 (UnmapWindow), minor code: 0

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

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

[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

[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=edit
glxinfo -l

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

[kwin] [Bug 356882] No compositing with Mesa 11.1.0 (EGL 1.5) and Plasma/KWin 5.5.1 when using EGL OpenGL interface

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356882

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

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

[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

[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=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

[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=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 342326] window contents freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=342326

--- Comment #27 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #26)
> vdpau specific: does it 
> a) start to update when you suspend the compositor
> b) still update when you resume the compositor afterwards?

I've tried to reproduce this with vdpau for approx. a week now and doesn't seem
to happen, so I'm not sure anymore it is triggered with that.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #8 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #6)
> Even gtk+ windows should just kick the NETWM moveresize in the WM
> 
> > kwin4_effect_translucency
> Try to disable this.
Will do.

> > electricBorderMaximize: true
> > electricBorderTiling: true
> and this
ok.

> Do you have autohiding panels on one of the edges?
No.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #5 from Bernd Steinhauser  ---
Created attachment 96538
  --> https://bugs.kde.org/attachment.cgi?id=96538=edit
qdbus-qt5 org.kde.KWin /KWin org.kde.KWin.supportInformation with compositing
enabled

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #4 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #3)
> *cough*
> 
> > Compositing
> > ===
> > Compositing is not active
Hm, that's interesting, I didn't notice that. It seems like I can't enable
compositing with egl anymore.
This definitely worked before, but I can't tell when it stopped working.
However, yesterday when the problem occurred, I was using the glx interface. I
just switched to give egl another try, but didn't notice that the compositor
was inactive then.

> 
> > I think (but I'm not sure here), I've even tried with the compositor 
> > switched off.
> Wow.
Like I said, I'm not sure here, but will try again when I don't fear data loss.

> > I've seen this issue since the update from 5.4.x to 5.5.0.
> https://git.reviewboard.kde.org/r/126266/
> (A rather wild guess given the apparent GPU state - the grab should not be
> required and would not impact visual updates)
I can give it a try, although the application I see it the most with is gtk
(firefox).

> > This seems to be a complete lockup of the gpu
> dmesg tail (if you can, probably via ssh?)
I normally have ssh deactivated, but will activate and see if I can get
anything out of it.
I highly doubt that, though. journal seemed to work, kernel logging seemed to
work (it did log the sysrq sync message), I synced the file system, so any
message that would have been in dmesg should have ended up in the journal as
well.

Could use that to debug some program when the issue happens, but for that I
would require upfront information about what to do.

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #9 from Bernd Steinhauser  ---
(In reply to Thomas Lübking from comment #7)
> PS: and HW acceleration in FF! ("about:config" iirc, filter for "accel")

apz.fling_accel_base_mult 1.0
apz.fling_accel_interval_ms 500
apz.fling_accel_supplemental_mult 1.0
layers.acceleration.disabled false
layers.acceleration.draw-fps false
layers.acceleration.force-enabled false

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

[kwin] [Bug 342326] window contents freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=342326

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #24 from Bernd Steinhauser  ---
I'm seeing this quite often with mpv (when a video is drawn). It definitely
happens when using xv, but I think also when using vdpau (but will try
explicitely).
I've also seen this happening when watching a video inside Firefox.

IIRC, I've seen this with both EGL and GLX.

Restarting kwin will fix it. Restarting the application will fix it as well.

Will try the sync option.

The video driver is radeonsi on a Kaveri. I'll attach the kwin support info
file.

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

[kwin] [Bug 343661] stops drawing window content after some time, likely SyncObject related

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343661

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

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

[KScreen] [Bug 357727] New: Failed to retrieve current config: "Backend invalidated"

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357727

Bug ID: 357727
   Summary: Failed to retrieve current config: "Backend
invalidated"
   Product: KScreen
   Version: 5.5.2
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: common
  Assignee: dvra...@kde.org
  Reporter: li...@bernd-steinhauser.de

Since some time, I think since version 5.5, kscreen likes to spam the logs with
the message:
kscreen: Failed to retrieve current config:  "Backend invalidated"

and sometimes
kscreen: Failed to retrieve current config:  "Failed to prepare backend"

This was mentioned in other bugs, but since I don't see their effects, I guess
this is an independent issue.
There is no apparent effect noticeable, everything seems to continue working.
Setting up the screen layout works fine.
Yet kscreen for some reason likes to push out this message every 10 s.

Reproducible: Always

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

[kwin] [Bug 357728] New: Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

Bug ID: 357728
   Summary: Dragging window leads to display freeze
   Product: kwin
   Version: 5.5.2
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: li...@bernd-steinhauser.de

Now I am aware, that this is possibly a bug in the display driver that is
triggered by kwin.
If this is the case, what I'm here hoping for is to gather relevant information
if anything.

The bug occurs randomly (but still relatively often), when I try to drag a
window from one screen to another.
(I'm not sure if this is bound to multiscreen, since I rarely try to drag
windows around on a single screen. Haven't seen that at least.)
This can lead to the whole desktop freezing. This seems to be a complete lockup
of the gpu, I can't get back to the console even after using sysrq + r.
sysrq itself is still working as shown by the output. I can sync and reboot the
system.
Sound will continue to play and the kernel does not spit out a bug info (so it
doesn't indicate that there is something wrong).

I've not seen this happening for any trigger other than dragging a window. I
tried with and without the transparency effect.
I've also tried OpenGL 3.1 and 2.0, I've tried GLX and EGL. I think (but I'm
not sure here), I've even tried with the compositor switched off.

I've seen this issue since the update from 5.4.x to 5.5.0. A kernel update was
not performed before that started to happen (kernel 4.3. I'm now using 4.4-rc8,
but that does not affect this.).
mesa was 11.0.4 when updating kde and was updated up to 11.1.0 since.

I've since basically stopped using the dragging windows feature and just move
windows around by using the "Move to Screen" functionality and this works fine.
Only if I forget about this issue and drag a window anyway, I'm in real danger
to lock up my system (as happened yesterday again).

Reproducible: Sometimes

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

[kwin] [Bug 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #2 from Bernd Steinhauser  ---
Created attachment 96537
  --> https://bugs.kde.org/attachment.cgi?id=96537=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 357728] Dragging window leads to display freeze

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357728

--- Comment #1 from Bernd Steinhauser  ---
Created attachment 96536
  --> https://bugs.kde.org/attachment.cgi?id=96536=edit
Last messages from journal when the freeze occured

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

[plasmashell] [Bug 356954] plasmashell hangs when desktop settings dialog is moved to another screen

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356954

Bernd Steinhauser  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #2 from Bernd Steinhauser  ---
Just updated to 5.5.1 today and cannot reproduce any more.

So it's either gone through that update or I did something else to make it go
away (although I wouldn't know what).

Marking as resolved.

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

[plasmashell] [Bug 356954] New: plasmashell hangs when desktop settings dialog is moved to another screen

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356954

Bug ID: 356954
   Summary: plasmashell hangs when desktop settings dialog is
moved to another screen
   Product: plasmashell
   Version: 5.5.0
  Platform: Exherbo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Multi-screen support
  Assignee: aleix...@kde.org
  Reporter: li...@bernd-steinhauser.de
CC: plasma-b...@kde.org

Wanted to setup a new background on one screen. Since I wanted to preview the
background image on the whole screen, I moved the dialog to the next screen and
noticed that it as well as the panel, desktop etc. became unresponsive. Didn't
see an error message in the log, though.

Reproducible: Always

Steps to Reproduce:
1. Open Desktop Settings (Right Click -> Desktop Settings)
2. Notice everything works fine
3. Move this window to another screen
4. Notice everything related to plasmashell stopped working

I didn't wait too long to see if it comes back, but it at least hung for one
minute before I killed it.



Current installed version is 5.5.0, will upgrade to .1 soon.

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

[plasmashell] [Bug 355953] Desktop on screens are switched on restart

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=355953

--- Comment #3 from Bernd Steinhauser  ---
Another interesting observation. Yesterday Plasma moved the panel, after
disconnecting one screen.
And it moved it onto the screen I just disconnected. Interestingly, when
reconnecting, it wasn't moved back.

I think that shouldn't happen. ;)

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

[plasmashell] [Bug 355953] Desktop on screens are switched on restart

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=355953

--- Comment #2 from Bernd Steinhauser  ---
Just wanted to add: The black screen is usable as in Windows can be moved
there, maximized etc.
The application switcher can appear on that screen as well.
(So kwin seems to work properly.)

However, the desktop menu (right click) is not accessible and no settings icon
is there. So Plasma does not seem to be active on that screen.

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

[plasmashell] [Bug 349482] After resume from suspend, non-primary display in multi-screen setup is black

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=349482

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #5 from Bernd Steinhauser  ---
Likely the same issue as bug 353975. The crash mentioned was fixed lately (at
least I haven't seen plasma crashing on screen changes since a few weeks).

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

[plasmashell] [Bug 353975] Black screen on second display.

[Bernd Steinhauser via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=353975

Bernd Steinhauser  changed:

   What|Removed |Added

 CC||li...@bernd-steinhauser.de

--- Comment #11 from Bernd Steinhauser  ---
Can confirm this in Plasma 5.5.

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