Bug 87662 - [ALL 3.18 Bisected] DVI --rotation inverted can't invert normally
Summary: [ALL 3.18 Bisected] DVI --rotation inverted can't invert normally
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: high major
Assignee: Sonika
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-24 03:13 UTC by Li Xu
Modified: 2017-07-24 22:49 UTC (History)
8 users (show)

See Also:
i915 platform: ALL
i915 features: display/Other


Attachments
dmesg (113.05 KB, text/plain)
2014-12-24 03:13 UTC, Li Xu
no flags Details
Possible fix for 3.18 (2.11 KB, patch)
2015-01-07 14:39 UTC, Ander Conselvan de Oliveira
no flags Details | Splinter Review
xrandr on vlv (212.75 KB, text/plain)
2015-03-18 09:14 UTC, Sonika
no flags Details
Xorg.0.log (17.84 KB, text/plain)
2015-03-27 03:18 UTC, Ding Heng
no flags Details
dmesg on stable v3.19.2 (46.13 KB, text/plain)
2015-03-27 03:21 UTC, Ding Heng
no flags Details
dmesg on nightly20150326 (47.08 KB, text/plain)
2015-03-27 03:22 UTC, Ding Heng
no flags Details

Description Li Xu 2014-12-24 03:13:20 UTC
Created attachment 111254 [details]
dmesg

System Environment:
--------------------------

Regression: Yes. 
good commit:

2014Q3_efi  62de88e8e65811010deac5375f8f0d8b14dc4d94 


Platform: SNB


Kernel: 
--------------------------

kernel 3.18 stable b2776bf7149bddd1f4161f14f79520f17fc1d71d

Bug detailed description:
-----------------------------
DVI can't invert normally after run xrandr --output HDMI3 --rotation inverted.
And --rotation left/right/normal can work.

Steps:
---------------------------
Boot up.
xrandr --output ${DISPLAY1} --rotation inverted
Comment 1 Chris Wilson 2014-12-24 07:09:50 UTC

*** This bug has been marked as a duplicate of bug 86548 ***
Comment 2 Li Xu 2015-01-04 08:13:45 UTC
48404c1e53d4e15d7e3e77cd2c8f3f22973ef38e is the first bad commit
commit 48404c1e53d4e15d7e3e77cd2c8f3f22973ef38e
Author: Sonika Jindal <sonika.jindal@intel.com>
Date:   Fri Aug 22 14:06:04 2014 +0530

    drm/i915: Add 180 degree primary plane rotation support

    Primary planes support 180 degree rotation. Expose the feature
    through rotation drm property.

    v2: Calculating linear/tiled offsets based on pipe source width and
    height. Added 180 degree rotation support in ironlake_update_plane.

    v3: Checking if CRTC is active before issueing update_plane. Added
    wait for vblank to make sure we dont overtake page flips. Disabling
    FBC since it does not work with rotated planes.

    v4: Updated rotation checks for pending flips, fbc disable. Creating
    rotation property only for Gen4 onwards. Property resetting as part
    of lastclose.

    v5: Resetting property in i915_driver_lastclose properly for planes
    and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
    width in i9xx_update_plane and ironlake_update_plane. Removed tab
    based indentation and unnecessary braces in intel_crtc_set_property
    and intel_update_fbc. FBC and flip related checks should be done only
    for valid crtcs.

    v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
    and positioning the disable code in intel_update_fbc.

    v7: In case rotation property on inactive crtc is updated, we return
    successfully printing debug log as crtc is inactive and only property change
    is preserved.

    v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
    crtc->primary->fb  and return value of update_primary_plane is ignored.

    v9: added rotation property to primary plane instead of crtc. Removing reset
    of rotation property from lastclose. rotation_property is moved to
    drm_mode_config, so drm layer will take care of resetting. Adding updation of
    fbc when rotation is set to 0. Allowing rotation only if value is
    different than old one.

    v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
    set_property(Daniel).

    v11: Using same set_property function for both primary and sprite, Adding
    primary plane specific code in the same function (Matt).

    v12: Removing disabling/ enabling of fbc from set_property because it is done
    from intel_pipe_set_base. Other formatting

    v13: we need to call disable_fbc before changing the rotation to 180,
    disable_fbc from intel_pipe_set_base gets called very late, that will
    be used to re-enable fbc if rotation is set to 0 (Ville).

    Testcase: igt/kms_rotation_crc

    Signed-off-by: Uma Shankar <uma.shankar@intel.com>
    Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
    Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
    [danvet: Add FIXME to explain why we need the open-coded update_fbc
    hunk to disable fbc when rotated 180 degree. And make checkpatch
    happier.]
    Acked-by: Matt Roper <matthew.d.roper@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 3 Ander Conselvan de Oliveira 2015-01-07 14:39:40 UTC
Created attachment 111913 [details] [review]
Possible fix for 3.18

In -nightly this issue is fixed by

commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Mon Dec 1 15:40:11 2014 -0800

    drm/i915: remove intel_pipe_set_base() (v4)

That seems a bit to big to backport, so I wrote the attached patch that should have the same effect of keeping the src and dst rects up to date when a legacy path changes the fb of a crtc.
Comment 4 Chris Wilson 2015-01-07 14:48:13 UTC
This bug can be hit without changing the fb. If you write a test case to rotate the fbcon, for example.
Comment 5 Jani Nikula 2015-03-03 14:10:09 UTC
(In reply to Ander Conselvan de Oliveira from comment #3)
> In -nightly this issue is fixed by
> 
> commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
> Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Date:   Mon Dec 1 15:40:11 2014 -0800
> 
>     drm/i915: remove intel_pipe_set_base() (v4)

Please retest with current nightly.
Comment 6 Jesse Barnes 2015-03-03 20:07:37 UTC
Sonika, can you take a look at this one?
Comment 7 Yi Sun 2015-03-06 01:07:47 UTC
(In reply to Jani Nikula from comment #5)
> (In reply to Ander Conselvan de Oliveira from comment #3)
> > In -nightly this issue is fixed by
> > 
> > commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
> > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > Date:   Mon Dec 1 15:40:11 2014 -0800
> > 
> >     drm/i915: remove intel_pipe_set_base() (v4)
> 
> Please retest with current nightly.

This bug is blocked by bug 89350, which blocked bi-weekly testing for BSW.
I tended to retest this so long as Mika's patch is applied.

Heng, please watch bug 89350,  then re-test this ASAP.
Comment 8 Ding Heng 2015-03-06 08:35:28 UTC
(In reply to Yi Sun from comment #7)
> (In reply to Jani Nikula from comment #5)
> > (In reply to Ander Conselvan de Oliveira from comment #3)
> > > In -nightly this issue is fixed by
> > > 
> > > commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
> > > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > Date:   Mon Dec 1 15:40:11 2014 -0800
> > > 
> > >     drm/i915: remove intel_pipe_set_base() (v4)
> > 
> > Please retest with current nightly.
> 
> This bug is blocked by bug 89350, which blocked bi-weekly testing for BSW.
> I tended to retest this so long as Mika's patch is applied.
> 
> Heng, please watch bug 89350,  then re-test this ASAP.

This issue still exist if you run xinit and do inverted rotation immediately.
Comment 9 Sonika 2015-03-17 12:10:43 UTC
I tried with SKL with latest -nightly, and I don't see this issue.
I don't have an SNB system. But I'l try on VLV once and will get back.
Comment 10 Sonika 2015-03-18 09:13:48 UTC
Even on VLV, I am unable to reproduce this issue with ubuntu.
I tried: 
xrandr -o inverted
xrandr -o normal

Although I see that in both the cases the rotation is set to 0 and there is no setproperty ioctl getting called. But the screen rotates when inverted and back to normal when normal is set.
Attached are the logs from VLV with latest -nightly and ubuntu.
Looks like xserver is doing the rotation by itself in this case.
Comment 11 Sonika 2015-03-18 09:14:25 UTC
Created attachment 114433 [details]
xrandr on vlv
Comment 12 Daniel Vetter 2015-03-18 10:23:35 UTC
(In reply to Sonika from comment #11)
> Created attachment 114433 [details]
> xrandr on vlv

Have you double-checked this is indeed nightly? Because of the noise it's not possible to see that.

btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.
Comment 13 Chris Wilson 2015-03-18 10:40:50 UTC
If you really, really want to know what's going on in the ddx side, compile xf86-video-intel with --enable-debug=full
Comment 14 Sonika 2015-03-19 04:50:49 UTC
(In reply to Daniel Vetter from comment #12)
> (In reply to Sonika from comment #11)
> > Created attachment 114433 [details]
> > xrandr on vlv
> 
> Have you double-checked this is indeed nightly? Because of the noise it's
> not possible to see that.
> 
> btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.

Yes, -nightly is what I built. But is it possible to find the branch from the logs somewhere?
Comment 15 Ding Heng 2015-03-19 06:07:17 UTC
I had retest this case on the same machine with the same monitor on latest nightly branch. The issue could not be reproduced. I also change the kernel to the older version (nightly branch 2015-03-05 and 2014-12-24) and with older X11(unstalbe 2015-03-05), seem this bug is not able to be reproduced, it is weird. Any suggestion for reproduce this issue?
Comment 16 Yi Sun 2015-03-20 00:58:07 UTC
If no one can reproduce this bug I tend to close it.
Any other finding, we'll file new one.
Comment 17 Ding Heng 2015-03-27 03:17:44 UTC
I reproduce this issue on a BDW. Reopen this bug.
A DP or HDMI minitor will also met this issue.

kernel: stable v3.19.2
X11R7: /X11R7_64_2015Q1
cat /proc/cmdline
BOOT_IMAGE=kernels//stable/v3.19.2/bzImage_x86_64 root=/dev/sda2 hostname=x-bdw09 modules_path=kernels//stable/v3.19.2/modules_x86_64/lib/modules/3.19.2_v3.19.2+ acpi_rsdp=0xac7e1014
The reproduce step is to run "xrandr --output eDP1 --rotation left --output DP1 --rotation inverted" immediately after xinit is run.

with nightly branch latest kernel 
60c5b7f582e8ced10dcd557db4ea66665e6a4dff(2015-03-26)

the issue is a little different.

Only command "xrandr -o inverted" will cause DP monitor fail to show anything.
xrandr --output eDP1 --rotation left --output DP1 --rotation inverted works well
Comment 18 Ding Heng 2015-03-27 03:18:37 UTC
Created attachment 114657 [details]
Xorg.0.log
Comment 19 Ding Heng 2015-03-27 03:21:14 UTC
Created attachment 114658 [details]
dmesg on stable v3.19.2
Comment 20 Ding Heng 2015-03-27 03:22:21 UTC
Created attachment 114659 [details]
dmesg on nightly20150326
Comment 21 Ding Heng 2015-03-27 10:21:54 UTC
This issue was found in at least BSW/BDW/BYT/HSW. The bisect point is right. I had tried on commit before the bisect commit, the issue will not appear.
Comment 22 Daniel Vetter 2015-04-02 08:15:05 UTC
(In reply to Sonika from comment #14)
> (In reply to Daniel Vetter from comment #12)
> > (In reply to Sonika from comment #11)
> > > Created attachment 114433 [details]
> > > xrandr on vlv
> > 
> > Have you double-checked this is indeed nightly? Because of the noise it's
> > not possible to see that.
> > 
> > btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.
> 
> Yes, -nightly is what I built. But is it possible to find the branch from
> the logs somewhere?

Kernel version is printed at the top of dmesg as the very first line, or can be printed with 

$ uname -r

If you enable CONFIG_LOCALVERSION_AUTO then this will even show your exact git version.
Comment 23 Yi Sun 2015-04-03 01:11:27 UTC
(In reply to Daniel Vetter from comment #22)
> (In reply to Sonika from comment #14)
> > (In reply to Daniel Vetter from comment #12)
> > > (In reply to Sonika from comment #11)
> > > > Created attachment 114433 [details]
> > > > xrandr on vlv
> > > 
> > > Have you double-checked this is indeed nightly? Because of the noise it's
> > > not possible to see that.
> > > 
> > > btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.
> > 
> > Yes, -nightly is what I built. But is it possible to find the branch from
> > the logs somewhere?
> 
> Kernel version is printed at the top of dmesg as the very first line, or can
> be printed with 
> 
> $ uname -r
> 
> If you enable CONFIG_LOCALVERSION_AUTO then this will even show your exact
> git version.

CONFIG_LOCALVERSION_AUTO sounds good. QA always specify version in makefile when building a kernel by the script. I'd like have a try. :p
Comment 24 wendy.wang 2015-04-07 07:20:59 UTC
Downgrade the priority to high based on 2015-03-27 test result:

with nightly branch latest kernel 
60c5b7f582e8ced10dcd557db4ea66665e6a4dff(2015-03-26)

the issue symptom is:

Only command "xrandr -o inverted" will cause DP monitor fail to show anything.
xrandr --output eDP1 --rotation left --output DP1 --rotation inverted works well

QA will report another bug against drm-intel-nightly bug behavior, to distinguish with this stable branch issue.
Comment 25 Paulo Zanoni 2016-03-08 19:05:00 UTC
One year later: is this bug still present?
Comment 26 Jani Nikula 2016-04-22 14:16:09 UTC
(In reply to Paulo Zanoni from comment #25)
> One year later: is this bug still present?

Timeout, presumed fixed. Please reopen if the problem persists with latest kernels.


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.