Using the intel DDX 2.99.917 on a HD Graphics 4400. When doing a 180 rotation using gnome-control-center I'm getting a black screen and the kernel errors below. Yet, using xrandr --output eDP1 --rotate inverted everything works fine. In GNOME, it's mutter that ends up calling XRRSetCrtcConfig and both in that case and with xrandr, the arguments to XRRSetCrtcConfig are exactly the same, they look like: Breakpoint 1, XRRSetCrtcConfig (dpy=0x1cd5a80, resources=0x6276800, crtc=63, timestamp=0, x=0, y=0, mode=77, rotation=4, outputs=0x72a0ce0, noutputs=1) at XrrCrtc.c:126 in both cases. So, I'm stumped as to why one works and the other doesn't. Here's the journal output when it fails: gdm-Xorg-:0[3533]: (II) intel(0): switch to mode 1366x768@60.0 on eDP1 using pipe 0, position (0, 0)...n none kernel: [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun If I then lock/unlock the session, which turns DPMS off and back on again I get regular output back (i.e. stops being black) and the following kernel trace: kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 0 PID: 3533 at drivers/gpu/drm/i915/intel_display.c:1256 assert_plane.constp...[i915]() kernel: plane A assertion failure (expected on, current off) kernel: Modules linked in: synaptics_usb ccm rfcomm fuse arc4 intel_rapl iosf_mbi x86_pkg_temp_the...obuf2_me kernel: CPU: 0 PID: 3533 Comm: Xorg Tainted: G W 3.19.0-1.fc22.x86_64 #1 kernel: Hardware name: LENOVO 20AMS22U0C/20AMS22U0C, BIOS GIET72WW (2.22 ) 03/25/2014 kernel: 0000000000000000 0000000073d612f6 ffff880213effb28 ffffffff817761b3 kernel: 0000000000000000 ffff880213effb80 ffff880213effb68 ffffffff8109bbfa kernel: ffff8800371a0000 0000000000000000 ffff8800371a0000 ffff8800c8d94800 kernel: Call Trace: kernel: [<ffffffff817761b3>] dump_stack+0x45/0x57 kernel: [<ffffffff8109bbfa>] warn_slowpath_common+0x8a/0xc0 kernel: [<ffffffff8109bc85>] warn_slowpath_fmt+0x55/0x70 kernel: [<ffffffffa0142c94>] assert_plane.constprop.85+0x74/0xb0 [i915] kernel: [<ffffffffa014a2e3>] hsw_disable_ips+0x33/0x190 [i915] kernel: [<ffffffffa014a6c8>] intel_crtc_disable_planes+0x48/0x140 [i915] kernel: [<ffffffff810c565d>] ? ttwu_do_activate.constprop.91+0x5d/0x70 kernel: [<ffffffffa014b450>] haswell_crtc_disable+0x40/0x390 [i915] kernel: [<ffffffffa014c669>] intel_crtc_control+0x59/0x120 [i915] kernel: [<ffffffffa014c791>] intel_crtc_update_dpms+0x61/0x70 [i915] kernel: [<ffffffffa0152309>] intel_connector_dpms+0x69/0x80 [i915] kernel: [<ffffffffa003ecea>] drm_mode_obj_set_property_ioctl+0x36a/0x370 [drm] kernel: [<ffffffffa003ed2f>] drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm] kernel: [<ffffffffa002ea8b>] drm_ioctl+0x1db/0x640 [drm] kernel: [<ffffffff8140fc62>] ? brightness_store+0xf2/0x120 kernel: [<ffffffff81231476>] do_vfs_ioctl+0x2c6/0x4d0 kernel: [<ffffffff8121f101>] ? __sb_end_write+0x21/0x70 kernel: [<ffffffff81231701>] SyS_ioctl+0x81/0xa0 kernel: [<ffffffff8113f9e6>] ? __audit_syscall_exit+0x1f6/0x2a0 kernel: [<ffffffff8177c969>] system_call_fastpath+0x12/0x17 kernel: ---[ end trace 75b0c3fa16143d67 ]---
It's not the call to set the rotation that matters, but a preceding one. The issue is that a regression slipped into 3.19 that caused the kernel to think that the first rotation was of a 0x0 plane.
(In reply to Chris Wilson from comment #1) > It's not the call to set the rotation that matters, but a preceding one. The > issue is that a regression slipped into 3.19 that caused the kernel to think > that the first rotation was of a 0x0 plane. Which one is that exactly? Has it been fixed since? Can we close this one?
This seems fixed at least as of 4.1.4 .
Thanks for the follow-up!
Closing resolved+fixed based on "This seems fixed..." by Reporter.
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.