i915: Dealing with 90° rotated display ?

i915: Dealing with 90° rotated display ?

[Hans de Goede]

Hi Jani,

As discussed here:

https://bugs.freedesktop.org/show_bug.cgi?id=94894

I've a mini-laptop which uses a phone-screen,
so the native orientation of the screen is portrait,
where as for a clam-shell device one wants it to
be landscape. Ideally there would be a flag somewhere
to tell the i915 driver that the panel is mounted
90° rotated in its bezel and have the i915 driver
apply that rotation on top of whatever rotation
userspace requests.

So question is there already a place (variable) in
the i915 driver where one can set such a rotation
offset to apply on top of what userspace requests ?

If not do you have any idea how feasible adding one
would be and can you give me a few pointers / hints
where to start with such a thing ?

Regards,

Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: i915: Dealing with 90° rotated display ?

[Ville Syrjälä]

On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
> Hi Jani,
> 
> As discussed here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=94894
> 
> I've a mini-laptop which uses a phone-screen,
> so the native orientation of the screen is portrait,
> where as for a clam-shell device one wants it to
> be landscape. Ideally there would be a flag somewhere
> to tell the i915 driver that the panel is mounted
> 90° rotated in its bezel and have the i915 driver
> apply that rotation on top of whatever rotation
> userspace requests.
> 
> So question is there already a place (variable) in
> the i915 driver where one can set such a rotation
> offset to apply on top of what userspace requests ?
> 
> If not do you have any idea how feasible adding one
> would be and can you give me a few pointers / hints
> where to start with such a thing ?

You could have a look at my branch (which I pointed out in the bug).

But note that 90/270 degree rotation is a little busted currently.
You'll need at least
https://patchwork.freedesktop.org/patch/120208/

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: Dealing with 90° rotated display ?

[Hans de Goede]

Hi,

On 15-02-17 15:59, Ville Syrjälä wrote:
> On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
>> Hi Jani,
>>
>> As discussed here:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=94894
>>
>> I've a mini-laptop which uses a phone-screen,
>> so the native orientation of the screen is portrait,
>> where as for a clam-shell device one wants it to
>> be landscape. Ideally there would be a flag somewhere
>> to tell the i915 driver that the panel is mounted
>> 90° rotated in its bezel and have the i915 driver
>> apply that rotation on top of whatever rotation
>> userspace requests.
>>
>> So question is there already a place (variable) in
>> the i915 driver where one can set such a rotation
>> offset to apply on top of what userspace requests ?
>>
>> If not do you have any idea how feasible adding one
>> would be and can you give me a few pointers / hints
>> where to start with such a thing ?
>
> You could have a look at my branch (which I pointed out in the bug).

Ok, so the patch that actually is relevant to this
discussion (and not just a cleanup / bug-fix) seems to be:

https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e

Right ?

AFAICT that will make fbcon inherit the rotation setting of
the primary plan on the primary crt. That may solve the
original bug as reported, but not the case / device I'm
talking about. What I would like to see is a "rotation offset"
field somewhere to be applied to all rotations in a way which
is hidden from userspace. Specifically the device I've has a
screen which is 720x1280 in resolution, but I want userspace
to see it as a 1280x720 screen because that is how it is used
in the hardware. So I want a 90° rotation to be applied which
is completely hidden from userspace. So when userspace
(e.g. the Xorg server + modesetting driver) asks for 0° degree
rotation under the hood they get 90 applied, when they aks for
the panel resolution they get 1280x720 instead of 720x1280.

Basically the idea is that the kernel as the HAL it is supposed
to be (amongst other things) hide the hardware weirdness / quirk
of using a portrait panel in a landscape bezel.

I hope this clarifies what I want to achieve and yes of course
fbcon should follow suite and also pick up the rotation offset.

> But note that 90/270 degree rotation is a little busted currently.
> You'll need at least
> https://patchwork.freedesktop.org/patch/120208/

Ok.

Regards,

Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: i915: Dealing with 90° rotated display ?

[Ville Syrjälä]

On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 15-02-17 15:59, Ville Syrjälä wrote:
> > On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
> >> Hi Jani,
> >>
> >> As discussed here:
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=94894
> >>
> >> I've a mini-laptop which uses a phone-screen,
> >> so the native orientation of the screen is portrait,
> >> where as for a clam-shell device one wants it to
> >> be landscape. Ideally there would be a flag somewhere
> >> to tell the i915 driver that the panel is mounted
> >> 90° rotated in its bezel and have the i915 driver
> >> apply that rotation on top of whatever rotation
> >> userspace requests.
> >>
> >> So question is there already a place (variable) in
> >> the i915 driver where one can set such a rotation
> >> offset to apply on top of what userspace requests ?
> >>
> >> If not do you have any idea how feasible adding one
> >> would be and can you give me a few pointers / hints
> >> where to start with such a thing ?
> >
> > You could have a look at my branch (which I pointed out in the bug).
> 
> Ok, so the patch that actually is relevant to this
> discussion (and not just a cleanup / bug-fix) seems to be:
> 
> https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e
> 
> Right ?

Looks that way, yes.

> 
> AFAICT that will make fbcon inherit the rotation setting of
> the primary plan on the primary crt. That may solve the
> original bug as reported, but not the case / device I'm
> talking about. What I would like to see is a "rotation offset"
> field somewhere to be applied to all rotations in a way which
> is hidden from userspace. Specifically the device I've has a
> screen which is 720x1280 in resolution, but I want userspace
> to see it as a 1280x720 screen because that is how it is used
> in the hardware. So I want a 90° rotation to be applied which
> is completely hidden from userspace.

That's not necessarily the best way since rotation may impose
additional restrictions on what the hardware can do. Which would
mean that your 0 degree setting would no longer be the setting
that should give the highest chance of success. That doesn't leave
much chance of userspace being able to work out a fallback strategy
when things don't succeed.

Oh, and the cursor plane can't even do 90/270 degree rotation, so
there's just no way to hide this fully.

That said, I did once implement a "full pipe rotation" thing, and even
added a knob into debugfs that allowed me to flip it without userspace
being involved. That's just something I used for testing the rotation
code initially. I just pushed some version of it here [1]. Obviously
90/270 effective rotation for the cursor still won't work.

[1] git://github.com/vsyrjala/linux.git full_pipe_rotation

> So when userspace
> (e.g. the Xorg server + modesetting driver) asks for 0° degree
> rotation under the hood they get 90 applied, when they aks for
> the panel resolution they get 1280x720 instead of 720x1280.

The idea was that userspace will inherit the initial rotation.
That does work correctly at least with the intel ddx. Given that our
rotation properties are per-plane, that would mean userspace would have
to deduce that the entire screen is rotation by simply looking at the
rotation of the primary plane. Or I suppose we could make the kernel
use the same default rotation for all planes, even the disabled ines.

> 
> Basically the idea is that the kernel as the HAL it is supposed
> to be (amongst other things) hide the hardware weirdness / quirk
> of using a portrait panel in a landscape bezel.

As said we can't really hide without causing additional grief to
userspace in the form of potential failures in configuring the
planes/crtcs.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: Dealing with 90° rotated display ?

[Hans de Goede]

Hi,

On 16-02-17 17:58, Ville Syrjälä wrote:
> On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 15-02-17 15:59, Ville Syrjälä wrote:
>>> On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
>>>> Hi Jani,
>>>>
>>>> As discussed here:
>>>>
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=94894
>>>>
>>>> I've a mini-laptop which uses a phone-screen,
>>>> so the native orientation of the screen is portrait,
>>>> where as for a clam-shell device one wants it to
>>>> be landscape. Ideally there would be a flag somewhere
>>>> to tell the i915 driver that the panel is mounted
>>>> 90° rotated in its bezel and have the i915 driver
>>>> apply that rotation on top of whatever rotation
>>>> userspace requests.
>>>>
>>>> So question is there already a place (variable) in
>>>> the i915 driver where one can set such a rotation
>>>> offset to apply on top of what userspace requests ?
>>>>
>>>> If not do you have any idea how feasible adding one
>>>> would be and can you give me a few pointers / hints
>>>> where to start with such a thing ?
>>>
>>> You could have a look at my branch (which I pointed out in the bug).
>>
>> Ok, so the patch that actually is relevant to this
>> discussion (and not just a cleanup / bug-fix) seems to be:
>>
>> https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e
>>
>> Right ?
>
> Looks that way, yes.
>
>>
>> AFAICT that will make fbcon inherit the rotation setting of
>> the primary plan on the primary crt. That may solve the
>> original bug as reported, but not the case / device I'm
>> talking about. What I would like to see is a "rotation offset"
>> field somewhere to be applied to all rotations in a way which
>> is hidden from userspace. Specifically the device I've has a
>> screen which is 720x1280 in resolution, but I want userspace
>> to see it as a 1280x720 screen because that is how it is used
>> in the hardware. So I want a 90° rotation to be applied which
>> is completely hidden from userspace.
>
> That's not necessarily the best way since rotation may impose
> additional restrictions on what the hardware can do. Which would
> mean that your 0 degree setting would no longer be the setting
> that should give the highest chance of success. That doesn't leave
> much chance of userspace being able to work out a fallback strategy
> when things don't succeed.
>
> Oh, and the cursor plane can't even do 90/270 degree rotation, so
> there's just no way to hide this fully.

Ok, I see that sucks, but I understand.

> That said, I did once implement a "full pipe rotation" thing, and even
> added a knob into debugfs that allowed me to flip it without userspace
> being involved. That's just something I used for testing the rotation
> code initially. I just pushed some version of it here [1]. Obviously
> 90/270 effective rotation for the cursor still won't work.
>
> [1] git://github.com/vsyrjala/linux.git full_pipe_rotation
>
>> So when userspace
>> (e.g. the Xorg server + modesetting driver) asks for 0° degree
>> rotation under the hood they get 90 applied, when they aks for
>> the panel resolution they get 1280x720 instead of 720x1280.
>
> The idea was that userspace will inherit the initial rotation.
> That does work correctly at least with the intel ddx.

Ah (userspace will inherit the initial rotation) I've yet to patch the
kernel to set up an initial rotation for this, I will give this a
try and see if that helps.

> Given that our
> rotation properties are per-plane, that would mean userspace would have
> to deduce that the entire screen is rotation by simply looking at the
> rotation of the primary plane. Or I suppose we could make the kernel
> use the same default rotation for all planes, even the disabled ines.

I think having userspace inherit the setting of the primary plane
is fine.

>> Basically the idea is that the kernel as the HAL it is supposed
>> to be (amongst other things) hide the hardware weirdness / quirk
>> of using a portrait panel in a landscape bezel.
>
> As said we can't really hide without causing additional grief to
> userspace in the form of potential failures in configuring the
> planes/crtcs.

Ack, not nice, but ack.

Regards,

Hans
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: Dealing with 90° rotated display ?

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Hi,

On 20-02-17 14:24, Hans de Goede wrote:

<snip>

>>> So when userspace
>>> (e.g. the Xorg server + modesetting driver) asks for 0° degree
>>> rotation under the hood they get 90 applied, when they aks for
>>> the panel resolution they get 1280x720 instead of 720x1280.
>>
>> The idea was that userspace will inherit the initial rotation.
>> That does work correctly at least with the intel ddx.
>
> Ah (userspace will inherit the initial rotation) I've yet to patch the
> kernel to set up an initial rotation for this, I will give this a
> try and see if that helps.

Ok, so for my case this does not help because only skylake and
later support 90 / 270 degree rotation and I'm on cherrytrail.

In case anyone is interested I've attached a rebased version
of the fbcon inherit wip patch (with the unrelated changes
to fb-helper's clone code removed).

Regards,

Hans

[-- Attachment #2: 0001-drm-fb-helper-Inherit-rotation-wip.patch --]
[-- Type: text/x-patch, Size: 7053 bytes --]

>From d6baf99228e6ce78f0a7e86feee48c34309e9b1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Sun, 29 Nov 2015 17:56:03 +0200
Subject: [PATCH] drm/fb-helper: Inherit rotation wip

---
 drivers/gpu/drm/drm_fb_helper.c      | 48 ++++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/intel_display.c | 30 +++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_drv.h     |  1 +
 include/drm/drm_fb_helper.h          |  2 ++
 4 files changed, 78 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f6d4d97..07de6d1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -159,6 +159,8 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct drm_
 {
 	struct drm_fb_helper_connector **temp;
 	struct drm_fb_helper_connector *fb_helper_connector;
+	struct drm_crtc *crtc = connector->encoder ?
+				connector->encoder->crtc : NULL;
 
 	if (!drm_fbdev_emulation)
 		return 0;
@@ -180,6 +182,11 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct drm_
 
 	drm_connector_reference(connector);
 	fb_helper_connector->connector = connector;
+	if (crtc && crtc->primary->state)
+		fb_helper_connector->rotation = crtc->primary->state->rotation;
+	if (!fb_helper_connector->rotation)
+		fb_helper_connector->rotation = DRM_ROTATE_0;
+
 	fb_helper->connector_info[fb_helper->connector_count++] = fb_helper_connector;
 	return 0;
 }
@@ -333,6 +340,35 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
 }
 EXPORT_SYMBOL(drm_fb_helper_debug_leave);
 
+static int fbdev_plane_index(struct drm_fb_helper *fb_helper,
+			     struct drm_plane *plane)
+{
+	int i;
+
+	if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+		return -ENODEV;
+
+	for (i = 0; i < fb_helper->crtc_count; i++) {
+		struct drm_crtc *crtc = fb_helper->crtc_info[i].mode_set.crtc;
+
+		if (crtc && crtc->primary == plane)
+			return i;
+	}
+
+	return -ENODEV;
+}
+
+static unsigned int fbdev_plane_rotation(struct drm_fb_helper *fb_helper,
+					 struct drm_plane *plane)
+{
+	int i = fbdev_plane_index(fb_helper, plane);
+
+	if (i < 0)
+		return DRM_ROTATE_0;
+	else
+		return fb_helper->crtc_info[i].rotation;
+}
+
 static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper)
 {
 	struct drm_device *dev = fb_helper->dev;
@@ -357,7 +393,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper)
 			goto fail;
 		}
 
-		plane_state->rotation = DRM_ROTATE_0;
+		plane_state->rotation = fbdev_plane_rotation(fb_helper, plane);
 
 		plane->old_fb = plane->fb;
 		plane_mask |= 1 << drm_plane_index(plane);
@@ -415,7 +451,7 @@ static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
 		if (plane->rotation_property)
 			drm_mode_plane_set_obj_prop(plane,
 						    plane->rotation_property,
-						    DRM_ROTATE_0);
+						    fbdev_plane_rotation(fb_helper, plane));
 	}
 
 	for (i = 0; i < fb_helper->crtc_count; i++) {
@@ -760,6 +796,7 @@ int drm_fb_helper_init(struct drm_device *dev,
 		if (!fb_helper->crtc_info[i].mode_set.connectors)
 			goto out_free;
 		fb_helper->crtc_info[i].mode_set.num_connectors = 0;
+		fb_helper->crtc_info[i].rotation = DRM_ROTATE_0;
 	}
 
 	i = 0;
@@ -2090,8 +2127,14 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
 
 			if (!drm_mode_equal(modes[o], modes[n]))
 				continue;
+
+			if (crtc->rotation &&
+			    crtc->rotation != fb_helper_conn->rotation)
+				continue;
 		}
 
+		crtc->rotation = fb_helper_conn->rotation;
+
 		crtcs[n] = crtc;
 		memcpy(crtcs, best_crtcs, n * sizeof(struct drm_fb_helper_crtc *));
 		score = my_score + drm_pick_crtcs(fb_helper, crtcs, modes, n + 1,
@@ -2182,6 +2225,7 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
 			fb_crtc->desired_mode = mode;
 			fb_crtc->x = offset->x;
 			fb_crtc->y = offset->y;
+			fb_crtc->rotation = fb_helper->connector_info[i]->rotation;
 			modeset->mode = drm_mode_duplicate(dev,
 							   fb_crtc->desired_mode);
 			drm_connector_reference(connector);
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index e1e828a..29addfe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2757,6 +2757,8 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
 	plane_state->crtc_w = fb->width;
 	plane_state->crtc_h = fb->height;
 
+	plane_state->rotation = plane_config->rotation;
+
 	intel_state->base.src = drm_plane_state_src(plane_state);
 	intel_state->base.dst = drm_plane_state_dest(plane_state);
 
@@ -7407,6 +7409,9 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
 			plane_config->tiling = I915_TILING_X;
 			fb->modifier = I915_FORMAT_MOD_X_TILED;
 		}
+
+		if (val & DISPPLANE_ROTATE_180)
+			plane_config->rotation = DRM_ROTATE_180;
 	}
 
 	pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
@@ -8459,6 +8464,24 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
 		goto error;
 	}
 
+	/*
+	 * DRM_ROTATE_ is counter clockwise to stay compatible with Xrandr
+	 * while i915 HW rotation is clockwise, thats why this swapping.
+	 */
+	switch (val & PLANE_CTL_ROTATE_MASK) {
+	case PLANE_CTL_ROTATE_0:
+		break;
+	case PLANE_CTL_ROTATE_90:
+		plane_config->rotation = DRM_ROTATE_270;
+		break;
+	case PLANE_CTL_ROTATE_180:
+		plane_config->rotation = DRM_ROTATE_180;
+		break;
+	case PLANE_CTL_ROTATE_270:
+		plane_config->rotation = DRM_ROTATE_90;
+		break;
+	}
+
 	base = I915_READ(PLANE_SURF(pipe, 0)) & 0xfffff000;
 	plane_config->base = base;
 
@@ -8548,6 +8571,9 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc,
 			plane_config->tiling = I915_TILING_X;
 			fb->modifier = I915_FORMAT_MOD_X_TILED;
 		}
+
+		if (val & DISPPLANE_ROTATE_180)
+			plane_config->rotation = DRM_ROTATE_180;
 	}
 
 	pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
@@ -15045,7 +15071,9 @@ int intel_modeset_init(struct drm_device *dev)
 	drm_modeset_unlock_all(dev);
 
 	for_each_intel_crtc(dev, crtc) {
-		struct intel_initial_plane_config plane_config = {};
+		struct intel_initial_plane_config plane_config = {
+			.rotation = DRM_ROTATE_0
+		};
 
 		if (!crtc->active)
 			continue;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 11f2e41..c1dcd87 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -421,6 +421,7 @@ struct intel_initial_plane_config {
 	unsigned int tiling;
 	int size;
 	u32 base;
+	uint8_t rotation;
 };
 
 #define SKL_MIN_SRC_W 8
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 6f5aceb..19fc313 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -48,6 +48,7 @@ struct drm_fb_helper_crtc {
 	struct drm_mode_set mode_set;
 	struct drm_display_mode *desired_mode;
 	int x, y;
+	uint8_t rotation;
 };
 
 /**
@@ -159,6 +160,7 @@ struct drm_fb_helper_funcs {
 
 struct drm_fb_helper_connector {
 	struct drm_connector *connector;
+	uint8_t rotation;
 };
 
 /**
-- 
2.9.3


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for i915: Dealing with 90° rotated display ?

[Patchwork]

== Series Details ==

Series: i915: Dealing with 90° rotated display ?
URL   : https://patchwork.freedesktop.org/series/20254/
State : success

== Summary ==

Series 20254v1 i915: Dealing with 90° rotated display ?
https://patchwork.freedesktop.org/api/1.0/series/20254/revisions/1/mbox/

fi-bdw-5557u     total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050     total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205     total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700     total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900     total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820     total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770      total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r     total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650       total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770      total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u     total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hq    total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k     total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hq    total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600      total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest
5ce5568 i915: Dealing with 90° rotated display ?

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3975/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx