Bug 94840

Summary:

[Ivy Bridge] Image on second monitor gets stuck except or mouse pointer

Product:

xorg

Reporter:

Frederik Himpe <fhimpe>

Component:

Driver/intel

Assignee:

Chris Wilson <chris>

Status:

RESOLVED INVALID

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

normal

Priority:

medium

Version:

git

Hardware:

Other

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg.0.log	none
dmesg	none
xrandr	none
dmesg Linux 4.5 with Intel xorg driver	none
xrandr with Intel driver	none
Xorg.0.log with Intel driver	none

Description Frederik Himpe 2016-04-06 10:17:25 UTC

On my Debian testing x86_64 system, I recently started to have problems with my
dual-screen setup: suddenly the image on my second monitor seems to get
stuck, except for the mouse pointer.

For example when I move a window from the laptop monitor to my second
screen, the window does not appear at all on the second screen. However,
the mouse pointer does while I am dragging the window over the second
screen.

To get out of this situation, I open GNOME's Displays configuration,
switch the second monitor to a duplicate of the first, and then in the
confirmation dialog that comes after the change, choose to revert the
change. Then everything works normally again. dmesg nor Xorg.0.log contain
any error.

The problem seems unrelated to the Linux kernel version: it happens with both Linux 4.3 as 4.5. I am using xserver 1.18.3 and the Intel X driver Debian
package 2:2.99.917+git20160325-1 and GNOME 3.18. It probably started when either the xserer was updated to 3.18 or with an update of the Intel driver.

The system is a HP EliteBook 8470p with this GPU:
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
processor Graphics Controller [8086:0166] (rev 09)

Comment 1 Frederik Himpe 2016-04-06 10:17:47 UTC

Created attachment 122758 [details]
Xorg.0.log

Comment 2 Frederik Himpe 2016-04-06 10:18:14 UTC

Created attachment 122759 [details]
dmesg

Comment 3 Frederik Himpe 2016-04-06 10:18:34 UTC

Created attachment 122760 [details]
xrandr

Comment 4 Chris Wilson 2016-04-06 10:39:17 UTC

You are not using the -intel driver (it is out of date).

Comment 5 Frederik Himpe 2016-04-06 13:04:57 UTC

OK, it looks I messed my configuration up when I wanted to see if this problem also happens an older Intel driver.

But so this means that this bug happens with both Intel driver 2:2.99.917+git20160325-1 and Linux 4.5 and with vesa driver and Linux 4.3, both running X server 1.18.3. Does this mean that the problem is in the X server itself?

Comment 6 Frederik Himpe 2016-04-06 13:08:16 UTC

Created attachment 122762 [details]
dmesg Linux 4.5 with Intel xorg driver

FY: During this session I undocked my system and docked it later again. The bug did not occur when doing this, but later on, and is not related to this docking/undocking you will see in the logs.

Comment 7 Frederik Himpe 2016-04-06 13:08:35 UTC

Created attachment 122763 [details]
xrandr with Intel driver

Comment 8 Frederik Himpe 2016-04-06 13:08:55 UTC

Created attachment 122764 [details]
Xorg.0.log with Intel driver

Comment 9 Chris Wilson 2016-04-06 13:16:57 UTC

Yeah, it's unlikely that both drivers have exactly the same bug. So either the rendering of the window stops (compositor), is not being handled (xserver) or the frame on the external display is stuck (kernel).

I guess you have an older kernel around that you can quickly compare with?

Comment 10 Frederik Himpe 2016-04-06 13:32:11 UTC

I see this problem now with both Linux 4.3 and 4.5. Is it useful to test an even older kernel? I am pretty sure that I have been using Linux 4.3 and 4.4 for months without seeing this problem, so I would surprised that the kernel is the culprit.

I am going to test now whether this happens with xserver 1.18.0 instead of 1.18.3.

If I understand it correctly, the bug could also be in GNOME? Then I will have to add that to my list of things to try.

Comment 11 Chris Wilson 2016-04-06 13:42:37 UTC

(In reply to Frederik Himpe from comment #10)
> I see this problem now with both Linux 4.3 and 4.5. Is it useful to test an
> even older kernel? I am pretty sure that I have been using Linux 4.3 and 4.4
> for months without seeing this problem, so I would surprised that the kernel
> is the culprit.

Ok, if you had said ~3.19 I would have felt a bit more confident ;)
 
> I am going to test now whether this happens with xserver 1.18.0 instead of
> 1.18.3.
> 
> If I understand it correctly, the bug could also be in GNOME? Then I will
> have to add that to my list of things to try.

Yes, in theory it may be gnome-shell not copying the window pixmap onto its framebuffer that it then present. Doubtful, but it is a possibility.

Comment 12 Frederik Himpe 2016-04-29 07:35:02 UTC

Closing this bug as I do not experience this problem any more after upgrading to GNOME 3.20. So I guess the bug was in GNOME in the end.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.