Bug 11909

Summary:	kde konsole window aperture gets confused with aperture(s) from other window(s) above/below
Product:	Mageia	Reporter:	Pierre Fortin <pf>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED OLD	QA Contact:
Severity:	normal
Priority:	Normal	CC:	doktor5000, nic
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:
Attachments:	konsole right 1/3 scrolls separately konsole window after windowshading konsole window stabilized after a while another example of gkrellm's apertures controlling konsole konsole after move to fresh desktop konsole overlaps gkrellm; but new app (KVIrc) has no effect on konsole

Description Pierre Fortin 2013-12-07 06:18:15 CET

Description of problem: Wow! How to even describe this problem...? After playing with the issue for a while, it appears the konsole window inherited apertures of those windows visible above it, or while konsole is window-shaded.

Note: I always run with one konsole window (several tabs each) on each desktop; only one such window is affected as I write this.

konsole scrolling, moving between tabs, and refresh are all VERY slow and any screen activities follow the various apertures of the other windows. For example, gkrellm has many apertures (graphs, titles, etc); each of gkrellm's apertures are inherited by konsole. Moving the konsole window around on the screen changes the apertures to whatever the overlapping other app windows have.

Actually, after more analysis, it appears this may be between konsole and gkrellm only. Newly opened app windows on the new desktop have no effect on the misbehaving konsole. The part of the konsole window not overlapped with gkrellm is extremely slowly updated -- what appears to be related to another window now seems to me to be simply "not gkrellm related".

Will try to describe more in screenshots...

Version-Release number of selected component (if applicable):
konsole-4.11.3-1.mga4
gkrellm-plugins-stock-2.3.5-10.mga4
gkrellm-2.3.5-9.mga4
gkrellm-plugins-2.3.5-10.mga4
and other mga4beta1 packages

How reproducible: no idea -- once it starts, there seems to be no way to stop it, except to terminate that konsole window. Moving it to a new, freshly created desktop

Steps to Reproduce:
1. no idea... may be remotely related to bug 11905
2.
3.

Reproducible:

Steps to Reproduce:

Comment 1 Pierre Fortin 2013-12-07 06:22:28 CET

Created attachment 4583 [details]
konsole right 1/3 scrolls separately

How this bug initially appeared.  The right 1/3 of the screen scrolls; but by small blocks which match the apertures from gkrellm (width=400; 12 updates/second) below.

Comment 2 Pierre Fortin 2013-12-07 06:26:44 CET

Created attachment 4584 [details]
konsole window after windowshading

Windowshading the konsole window. This shot shows some of the gkrellm apertures on the right, with the left 2/3 just empty -- this part is quite slow to be refreshed.

Comment 3 Pierre Fortin 2013-12-07 06:30:04 CET

Created attachment 4585 [details]
konsole window stabilized after a while

what the konsole window should look like.

Comment 4 Pierre Fortin 2013-12-07 06:32:08 CET

Created attachment 4586 [details]
another example of gkrellm's apertures controlling konsole

Here, some of the gkrellm graph aperture details are visible.

Comment 5 Pierre Fortin 2013-12-07 06:35:16 CET

Created attachment 4587 [details]
konsole after move to fresh desktop

Here, the gkrellm window is not overlapping, so only the remainder (all) shows the raw desktop through the non-gkrellm aperture. So the konsole is still delayed by no-longer-visible gkrellm apertures.

Comment 6 Pierre Fortin 2013-12-07 06:39:47 CET

Created attachment 4588 [details]
konsole overlaps gkrellm; but new app (KVIrc) has no effect on konsole

overlapped konsole and gkrellm show konsole using gkrellm apertures again; while new app (KVIrc) has no visible effect on konsole.  After many attempts, the only part of the KVIrc app that showed through was the Connect Now bar in KVIrc's Servers window.

Comment 7 Pierre Fortin 2013-12-07 06:41:33 CET

In the last attachment, forgot to mention that KVIrc did mask out the underlying raw desktop -- this can be seen at the upper right of the konsole window.

Comment 8 Manuel Hiebel 2013-12-22 13:31:39 CET

still valid ?

Keywords: (none) => NEEDINFO
Blocks: (none) => 12079

Comment 9 Florian Hubold 2013-12-23 15:54:16 CET

Underlying problem is probably that gkrellm uses fake transparency and writes to X root window (background) which may be picked up by many applications.

If at all, should probably be reported upstream at https://bugs.kde.org/

CC: (none) => doktor5000

Florian Hubold 2014-02-03 13:05:15 CET

Blocks: 12079 => (none)

Comment 10 Nic Baxter 2015-03-31 03:48:25 CEST

Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => OLD