Bug 95016

Summary:

X unresponsive + faulty image when changing external screen resolution using xrandr

Product:

DRI

Reporter:

gt6

Component:

DRM/Intel

Assignee:

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

Status:

CLOSED FIXED

QA Contact:

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

Severity:

major

Priority:

medium

CC:

intel-gfx-bugs

Version:

XOrg git

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

BDW

i915 features:

display/atomic, display/DP

Attachments:

Description	Flags
Faulty tiled image in frozen X after running xrandr	none
dmesg with debug output	none
Xorg.0.log up until using xrandr and then switching to TTY2 to kill it	none
xrandr --verbose (with both screen working correctly)	none
Faulty tiled image in frozen X after running xrandr	none
screenshot after a "blind" attempt at re-setting the layout	none

Description gt6 2016-04-19 10:32:32 UTC

Created attachment 123046 [details]
Faulty tiled image in frozen X after running xrandr

Bug description:
This is a Dell XPS 13 9343 (2015) with a native resolution of 1920x1080 via eDP. If I boot it with an external screen (3440x1440) attached via DP, the image from the laptop gets mirrored automatically when X starts. If I attempt to change the resolution and layout by running

xrandr --output DP1 --auto --right-of eDP1
  or
xrandr --output DP1 --mode 3440x1440 --right-of eDP1

then X becomes unresponsive 9 out of 10 times and I have to kill it from another VT (e.g. TTY2). The resolution of the external screen does indeed change, but the image from the laptop is tiled a bunch of times and I can't interact with anything (the mouse cursor is frozen, too).

Attached is a screenshot I managed to grab by running

xrandr --output eDP1 --auto --output DP1 --auto --right-of eDP1 & (sleep 4; scrot)

In the screenshot, the upper left tile is on my laptop as I expect it. The part on the right is the external screen showing the unexpected tiling.

The problem exists in drm-intel-nightly


System environment:
-- chipset: Intel Broadwell-U
-- system architecture: 64-bit
-- xf86-video-intel: 1:2.99.917+622+gde44aaa-1
-- xserver: 1.18.3-1
-- mesa: 11.2.0-1
-- libdrm: 2.4.67-2
-- kernel: problem present on 4.4.5-1, 4.5-1 and linux-drm-intel-nightly-20160419-1
-- Linux distribution: Archlinux
-- Machine or mobo model: Dell XPS 13 9343
-- Display connector: internal eDP, external DP


Reproducing steps:
 * Connect external screen via DP
 * run xrandr --output DP1 --auto --right-of eDP1


Additional info:
Xorg.0.log is attached. The output regarding xrandr (timestamp 3041.823) seems normal. The "got pause for" output comes from me switching to TTY2 after the problem occurs.
dmesg with debug is attached.
xrandr --verbose is attached (for the rare case that changing the resolution worked).

> uname -a
Linux tachychineta 4.6.0-1-drm-intel-nightly #1 SMP PREEMPT Tue Apr 19 12:00:49 CEST 2016 x86_64 GNU/Linux

I wasn't able to create a vbios dump:
> echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
> cat /sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump
cat: '/sys/devices/pci0000:00/0000:00:02.0/rom': Input/output error

Comment 1 gt6 2016-04-19 10:33:57 UTC

Created attachment 123047 [details]
dmesg with debug output

dmesg contains 2 runs of reproducing the problem, once around timestamp 27, the second time around timestamp 163.

Comment 2 gt6 2016-04-19 10:34:17 UTC

Created attachment 123048 [details]
Xorg.0.log up until using xrandr and then switching to TTY2 to kill it

Comment 3 gt6 2016-04-19 10:34:58 UTC

Created attachment 123049 [details]
xrandr --verbose (with both screen working correctly)

Comment 4 gt6 2016-04-19 10:36:24 UTC

Created attachment 123050 [details]
Faulty tiled image in frozen X after running xrandr

Comment 5 gt6 2016-04-20 13:56:57 UTC

Created attachment 123091 [details]
screenshot after a "blind" attempt at re-setting the layout

I discovered that X still accepts input, but it just doesn't draw anything correctly. The only thing that changes is the mouse cursor when (blindly) switching work-spaces. It'll change from a pointer to a text cursor depending on the application that is open. However, nothing else on the screen changes.

I can still enter commands on the keyboard. If, after attempting to change the layout using xrandr without succes, I "blindly" run

xrandr --output DP1 --off

then the external display does indeed turn off, but the laptop display is still "frozen". If I then blindly run

xrandr --output DP1 --mode 3440x1440 --right-of eDP1

then the layout gets messed up even more. So it repeats the whole wrong-offset-tiling-issue. I attached a screenshot of this, where you can see that even the laptop display doesn't match up with the workspace borders anymore. The top-left corner is now in the wrong place as well, while this used to be correct after the first attempt (even if frozen).

Comment 6 gt6 2016-06-13 13:33:14 UTC

Is there anything I can do to help move this issue along? I still have the same problem in linux 4.6.2. It's really frustrating. Nine out of ten times, the display is garbled and I have to restart X. So I can't connect a display without completely interrupting my workflow.

Does anyone have a clue what the cause could be?

I can't be the only one who's experiencing this issue...

Comment 7 gt6 2016-06-13 14:03:16 UTC

Well, if there is anyone with the same problem, here's a possible solution:

1) Uninstall xf86-video-intel
2) Remove /etc/X11/xorg.conf.d/20-intel.conf if present
3) Reboot

X will now use xf86-video-modesetting instead of the intel driver. The modesetting driver appears to automatically choose the correct resolution (3440x1440) from the get-go and I don't experience any crashes when changing the screen layout.

Comment 8 Elio 2016-06-30 17:03:42 UTC

Hello,

I just tried to reproduce the problem with following configuration:

BDW-U NUC, emulating eDP with external Display (HP ZR24w) 1920 x 1200 as principal display

Attaching a 4k display (3840x2160). Using same command lines:

xrandr --output DP1 --auto --right-of eDP1
  or
xrandr --output DP1 --mode 3440x1440 --right-of eDP1

Both are working fine with this software configuration:

OS: Ubuntu 16.04
Kernel: 4.7.0 rc2

++ Date : jun-WW24-01-11:31:29 

 --> Component : drm 
	 url : http://cgit.freedesktop.org/mesa/drm 
	 tag : libdrm-2.4.68 
	 commit : fc09c5a 
	 author : Kenneth Graunke <kenneth@whitecape.org> 
	 age : 6 weeks ago 
 --> Component : mesa 
	 url : http://cgit.freedesktop.org/mesa/mesa 
	 tag : mesa-11.2.2 
	 commit : 3a9f628 
	 author : Emil Velikov <emil.velikov@collabora.com> 
	 age : 4 weeks ago 
 --> Component : xf86-video-intel 
	 url : http://cgit.freedesktop.org/xorg/driver/xf86-video-intel 
	 tag : 2.99.917 
	 commit : baec802 
	 author : Chris Wilson <chris@chris-wilson.co.uk> 
	 age : 1 year 6 months ago 
 --> Component : libva 
	 url : http://cgit.freedesktop.org/libva/ 
	 tag : libva-1.7.1.pre1 
	 commit : 453876f 
	 author : Xiang Haihao <haihao.xiang@intel.com> 
	 age : 4 days ago 
 --> Component : vaapi (intel-driver) 
	 url : http://cgit.freedesktop.org/vaapi/intel-driver 
	 tag : 1.7.1.pre1 
	 commit : 2975480 
	 author : Xiang Haihao <haihao.xiang@intel.com> 
	 age : 4 days ago 
 --> Component : cairo 
	 url : http://cgit.freedesktop.org/cairo 
	 tag : 1.15.2 
	 commit : db8a7f1 
	 author : Bryce Harrington <bryce@osg.samsung.com> 
	 age : 6 months ago 
 --> Component : xserver 
	 url :  http://cgit.freedesktop.org/xorg/xserver 
	 tag : xorg-server-1.18.3 
	 commit : 9454cd5 
	 author : Adam Jackson <ajax@redhat.com> 
	 age : 9 weeks ago 
 --> Component : intel-gpu-tools 
	 url : http://cgit.freedesktop.org/xorg/app/intel-gpu-tools 
	 tag : intel-gpu-tools-1.15 
	 commit : 3ce58b6 
	 author : Marius Vlad <marius.c.vlad@intel.com> 

Please let me know if this configuration works for you

Comment 9 Jari Tahvanainen 2017-01-10 13:39:48 UTC

Closing resolved+worksforme after 6 months of silence.

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.