Bug#582516: kde 4:4.4.3-1 / plasma-desktop / nvidia-driver ?: Dual monitor system: Erasing background on wrong display e.g. when Alt-Tab window list pops up...
Package: kde
Version: 4:4.4.3-1
Affected package may be kde, kde-window-manager, kwin or plasma-desktop,
might be even nvidias proprietary driver (low probability for that).
Reproducability: every time (with the right focus/display constellation)
Hi debian team,
Using debian "testing" on a dual-screen system, I've recently seen problems
with the handling of window backgrounds.
Brief description:
------------------
Alt-Tab shows a popup window-list which can be used to
select=activate=transfer_focus to another window.
On a multi monitor system, the window list appears on the display where the
mouse pointer is currently located while Alt-Tab is pressed.
When I use Alt-Tab for the FIRST time on one display (having moved the
pointer there before), then when the window-list is displayed, a shape of
same size and form is erased to something similar to background colour on
the other display (that had the pointer when Alt-Tab was used before).
This shape is not automatically redrawn after the window-list disappears.
So effectively, using Alt-Tab after moving the pointer to the other
display, punches a large hole into the display that had the pointer before.
If Alt-Tab is used with the pointer on my primary display, and thus the the
window-list appears on the primary display, and the punched hole appears on
the second display, then some icons from the desktop appear inside that
hole - but at an y-position that doesn't match their original relation to
the window-list on the first display.
My second display has a background image (the first hasn't), but that
background image is not mirrored into the hole on the other display at all.
Other occasions/affected/unaffected components: some; see below.
To reproduce one example easily and fast:
-----------------------------------------
Preparation:
(-3) Please set up a dual-monitor system. (Mine uses nvidia TwinView: both
monitors belong to the same X11 screen, the desktop extends accross both
monitors, the secondary display is positioned above the primary display.)
(-2) Please open two large application windows (whatever), mostly covering
the primary and secondary display, respectively. (This might be optional,
as even the normal folderview? desktop content might suffice.)
(-1) Move the mouse pointer onto display 1.
(0) Press and release Alt-Tab.
All this is just to get into a defined state where the window-list was
displayed at least once on display 1, before we're going to display it on
display 2 to formally trigger the error. If the error already has occured
by now, please ignore it. :-)
Triggering the error:
(1) Move the mouse pointer onto display 2.
(2) Press Alt-Tab to bring up the window-list.
What happens:
(3) That window-list appears on the display 2 (correct)...
(4) At the same time, a shape of the same size and form and similar
position of that window-list is cleared to something close to my desktop
background colour on display 1, like a big hole (incorrect).
(5) Moreover: Release Alt-Tab if you haven't already.
Whereas the window-list on display 2 disappears (correct)...
(6) ...that shape on the display 1 remains. Until whatever window(s)
(previously punched) in the same area on display 1 are redrawn.
Quite a peculiar sidenote:
My true background colour is a uniform #400080 (R=64 G=00 B=128).
When I use the kcolorchoser pipette to pick the colour of the hole,
during the first measurement inside that hole after having measured
something else or restarted kcolorchoser,
the kcolorchoser readout shows #672A88 for ~1/10th second, then
changes to #652988 and stays there;
but during all directly following measurements,
the kcolorchoser readout shows #672A88 immediately
and permanently -
all for that same hole, while nothing has visibly changed!)
More details:
(7) Now, make the window-with-punched hole on display 1 redraw itself.
The hole disappears.
(8) Keep the mouse pointer to display 2 again, just as in step (1).
(9) Press Alt-Tab again. This time, the window-list appears on display 2
again - but now without punching a hole in display 1! (now correct)
(10) Now, move the mouse pointer to display 1.
(11) Press Alt-Tab again. This time, the window-list appears on the display
1 (correct)...
(12) ...and this time, a hole is punched into display 2. The erroneous
behaviour occurs the other way round.
(13) Now let the window-list disappear again.
Again, the hole on display 2 doesn't disappear.
(14) Make your hole-punched window on display 2 redraw itself.
(15) Keep the mouse pointer on display 1, just as in step (10).
(16) Press Alt-Tab - the window list appears on display 1 again,
and again, now without punching a hole into display 2.
So apparently, whenever the window-list is called *for the first time* to
appear (determined by mouse pointer) on any given display, *after having
previously appeared on the other display*, the unwanted hole is newly
punched into that other display.
The problem is *not* visible on subsequent times the window-list is
called on the same display.
Hypothesis:
-----------
I think some background-erasing/grabbing? variable is not updated with the
current display early enough before the window-list is produced, but it is
only updated (maybe as side effect in the course of other things happening)
after the window-list has been shown at least once. Too late, that is.
Other affected stuff:
---------------------
I've observed similar behaviour in a few (rare) other occasions with
smaller windows accompanied by smaller "holes" on the other display.
One example: A popup notification "download complete" (from the
"Benachrichtigungen" im "Systemabschnitt der Kontrolleiste"
("Notifications" in the "system portion of the control bar/task
bar/'dock'?) (NOT in the Mozilla download window!) showed the same error
once. As the problem requires a suitable history and relation between
displays, focus and the newly appearing window, I haven't seen it so often
for anything as for the window-list (which I use quite often).
The popup for Alt-F2 "execute command" is quite certainly NOT affected.
I have the feeling, that it should be related to kde/plasma components and
does not appear on other software. Nevertheless (I'm highly unsure!), it
might also have appeared once when the eclipse splash screen was displayed.
Relationship with upgrade history:
----------------------------------
The current upgrade was made as the last revision of kdm which I had tried
had not automatically redrawn the background image around the login dialog.
THAT problem (which also had only recently been introduced) was fixed by
the current release. I'm relatively (not absolutely) sure that the current
problem (reported in this mail) had NOT been in the previous release that I
had used.
Affected packages:
------------------
I upgraded a number of components within a few days, so I'm unsure whether
this bug is caused by any kde 4 or plasma package, X11, or the current
(proprietary) nvidia driver.
xwininfo reports "kwin" for the task switching popup-window, and
"plasma-desktop" for the "Benachrichtigungen und Aktionen" Icon in the
system-portion of the control bar.
About my system:
$ dpkg-query -l kde* plasma* | grep ii
plama-* and kde-* packages are mostly version 4:4.4.3-1; for example:
...
ii kde-window-manager 4:4.4.3-1
...
ii plasma-desktop 4:4.4.3-1
ii plasma-widget-folderview 4:4.4.3-1
ii plasma-widgets-workspace 4:4.4.3-1
...
$ cat /proc/version
Linux version 2.6.34-CD (root@nova) (gcc version 4.4.4 (Debian 4.4.4-1) )
#1 SMP PREEMPT Wed May 19 14:43:06 CEST 2010
$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
...
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro FX 2500M/PCI/SSE2
OpenGL version string: 2.1.2 NVIDIA 195.36.24
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler
OpenGL extensions:
X Server Information:
Display Name: nova:0
Server Version Number: 11.0
Server Vendor String: The X.Org Foundation
Server Vendor Version: 1.7.7 (10707000)
NV-CONTROL Version: 1.22
Screens: 1
X Server Display Information:
Primary display: LPL (DFP-0 on GPU-0)
Resolution 1440x900, Position Absolute +0+1024
X Screen Number 0, 16.7 Million Colors (Depth 24)
Secondary display: Silicon Graphics SGI MultiLink (DFP-1 on GPU-0)
Resolution 1600x1024, Position Absolute +0 +0
(well, I selected "Above" to activate the 2nd display)
X Screen Number 0, 16.7 Million Colors (Depth 24)
--
This is as much as I can write now - hope it helps and would love to
read any feedback.
Thank you for considering my input and thank you for your fine efforts!
Kind regards, Joerg
Reply to: