* i915: Dealing with 90° rotated display ? @ 2017-02-15 14:54 Hans de Goede 2017-02-15 14:59 ` Ville Syrjälä 2017-02-27 10:31 ` ✓ Fi.CI.BAT: success for " Patchwork 0 siblings, 2 replies; 7+ messages in thread From: Hans de Goede @ 2017-02-15 14:54 UTC (permalink / raw) To: intel-gfx, dri-devel; +Cc: Jani Nikula 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915: Dealing with 90° rotated display ? 2017-02-15 14:54 i915: Dealing with 90° rotated display ? Hans de Goede @ 2017-02-15 14:59 ` Ville Syrjälä 2017-02-16 10:01 ` Hans de Goede 2017-02-27 10:31 ` ✓ Fi.CI.BAT: success for " Patchwork 1 sibling, 1 reply; 7+ messages in thread From: Ville Syrjälä @ 2017-02-15 14:59 UTC (permalink / raw) To: Hans de Goede; +Cc: Jani Nikula, intel-gfx, dri-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915: Dealing with 90° rotated display ? 2017-02-15 14:59 ` Ville Syrjälä @ 2017-02-16 10:01 ` Hans de Goede 2017-02-16 16:58 ` Ville Syrjälä 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2017-02-16 10:01 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Jani Nikula, intel-gfx, dri-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915: Dealing with 90° rotated display ? 2017-02-16 10:01 ` Hans de Goede @ 2017-02-16 16:58 ` Ville Syrjälä 2017-02-20 13:24 ` Hans de Goede 0 siblings, 1 reply; 7+ messages in thread From: Ville Syrjälä @ 2017-02-16 16:58 UTC (permalink / raw) To: Hans de Goede; +Cc: Jani Nikula, intel-gfx, dri-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915: Dealing with 90° rotated display ? 2017-02-16 16:58 ` Ville Syrjälä @ 2017-02-20 13:24 ` Hans de Goede 2017-02-25 18:28 ` Hans de Goede 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2017-02-20 13:24 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Jani Nikula, intel-gfx, dri-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915: Dealing with 90° rotated display ? 2017-02-20 13:24 ` Hans de Goede @ 2017-02-25 18:28 ` Hans de Goede 0 siblings, 0 replies; 7+ messages in thread From: Hans de Goede @ 2017-02-25 18:28 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Jani Nikula, intel-gfx, dri-devel [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* ✓ Fi.CI.BAT: success for i915: Dealing with 90° rotated display ? 2017-02-15 14:54 i915: Dealing with 90° rotated display ? Hans de Goede 2017-02-15 14:59 ` Ville Syrjälä @ 2017-02-27 10:31 ` Patchwork 1 sibling, 0 replies; 7+ messages in thread From: Patchwork @ 2017-02-27 10:31 UTC (permalink / raw) To: Hans De Goede; +Cc: intel-gfx == 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-27 10:31 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-15 14:54 i915: Dealing with 90° rotated display ? Hans de Goede 2017-02-15 14:59 ` Ville Syrjälä 2017-02-16 10:01 ` Hans de Goede 2017-02-16 16:58 ` Ville Syrjälä 2017-02-20 13:24 ` Hans de Goede 2017-02-25 18:28 ` Hans de Goede 2017-02-27 10:31 ` ✓ Fi.CI.BAT: success for " Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.