All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>, Hans de Goede <j.w.r.degoede@gmail.com>
Cc: linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	David Airlie <airlied@linux.ie>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Daniel Drake <drake@endlessm.com>,
	dri-devel@lists.freedesktop.org,
	Bastien Nocera <hadess@hadess.net>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary
Date: Mon, 30 Oct 2017 11:09:27 +0000	[thread overview]
Message-ID: <873cb3a6-342f-a1aa-0569-874d86f320b3@redhat.com> (raw)
In-Reply-To: <20171030095212.fuglrxyc3jpfrnjg@phenom.ffwll.local>

Hi,

On 30-10-17 10:52, Daniel Vetter wrote:
> On Mon, Oct 23, 2017 at 09:14:22AM +0200, Hans de Goede wrote:
>> Apply the "panel orientation" drm connector prop to the primary plane so
>> that fbcon and fbdev using userspace programs display the right way up.
>>
>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id”894
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Changes in v2:
>> -New patch in v2 of this patch-set
>>
>> Changes in v3:
>> -Use a rotation member in struct drm_fb_helper_crtc and set that from
>>   drm_setup_crtcs instead of looping over all crtc's to find the right one
>>   later
>> -Since we now no longer look at rotation quirks directly in the fbcon code,
>>   set fb_info.fbcon_rotate_hint when the panel is not mounted upright and
>>   we cannot use hardware rotation
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 76 +++++++++++++++++++++++++++++++++++++++--
>>   include/drm/drm_fb_helper.h     |  8 +++++
>>   2 files changed, 82 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index 116d1f1337c7..e0f95f2cc52f 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -41,6 +41,7 @@
>>   #include <drm/drm_atomic.h>
>>   #include <drm/drm_atomic_helper.h>
>>   
>> +#include "drm_crtc_internal.h"
>>   #include "drm_crtc_helper_internal.h"
>>   
>>   static bool drm_fbdev_emulation = true;
>> @@ -350,6 +351,7 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>>   static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool active)
>>   {
>>   	struct drm_device *dev = fb_helper->dev;
>> +	struct drm_plane_state *plane_state;
>>   	struct drm_plane *plane;
>>   	struct drm_atomic_state *state;
>>   	int i, ret;
>> @@ -368,8 +370,6 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool activ
>>   retry:
>>   	plane_mask = 0;
>>   	drm_for_each_plane(plane, dev) {
>> -		struct drm_plane_state *plane_state;
>> -
>>   		plane_state = drm_atomic_get_plane_state(state, plane);
>>   		if (IS_ERR(plane_state)) {
>>   			ret = PTR_ERR(plane_state);
>> @@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool activ
>>   
>>   	for (i = 0; i < fb_helper->crtc_count; i++) {
>>   		struct drm_mode_set *mode_set = &fb_helper->crtc_info[i].mode_set;
>> +		struct drm_plane *primary = mode_set->crtc->primary;
>> +
>> +		/* Cannot fail as we've already gotten the plane state above */
>> +		plane_state = drm_atomic_get_new_plane_state(state, primary);
>> +		plane_state->rotation = fb_helper->crtc_info[i].rotation;
>>   
>>   		ret = __drm_atomic_helper_set_config(mode_set, state);
>>   		if (ret != 0)
>> @@ -2334,6 +2339,57 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
>>   	return best_score;
>>   }
>>   
>> +/*
>> + * This function checks if rotation is necessary because of panel orientation
>> + * and if it is, if it is supported.
>> + * If rotation is necessary and supported, its gets set in fb_crtc.rotation.
>> + * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
>> + * or-ed into fb_helper->rotations. In drm_setup_crtcs_fb() we check if only
>> + * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
>> + * the unsupported rotation.
>> + */
>> +static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
>> +				    struct drm_fb_helper_crtc *fb_crtc,
>> +				    struct drm_connector *connector)
>> +{
>> +	struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
>> +	uint64_t valid_mask = 0;
>> +	int i, rotation;
>> +
>> +	fb_crtc->rotation = DRM_MODE_ROTATE_0;
>> +
>> +	switch (connector->display_info.panel_orientation) {
>> +	case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
>> +		rotation = DRM_MODE_ROTATE_180;
>> +		break;
>> +	case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
>> +		rotation = DRM_MODE_ROTATE_90;
>> +		break;
>> +	case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
>> +		rotation = DRM_MODE_ROTATE_270;
>> +		break;
> 
> For 90/270 hw rotation you need to flip the coordinates/sizes of the fb.

You're probably right, I don't have any hardware supporting
270 degree rotation to test this with.

>> +	default:
>> +		rotation = DRM_MODE_ROTATE_0;
>> +	}
>> +
>> +	if (rotation = DRM_MODE_ROTATE_0 || !plane->rotation_property) {
>> +		fb_helper->rotations |= rotation;
>> +		return;
>> +	}
>> +
>> +	for (i = 0; i < plane->rotation_property->num_values; i++)
>> +		valid_mask |= (1ULL << plane->rotation_property->values[i]);
> 
> This isn't a good enough check for atomic drivers (and not for gen9+ intel
> hw), since we might expose 90° rotations, but it only works if you have
> the correct tiling format.
> 
> For atomic drivers it'd be really good if we could do a TEST_ONLY commit
> first, and if that fails, fall back to sw rotation.
> 
> But that poses a bit a chicken&egg with creating the framebuffer (we need
> one for the TEST_ONLY), so probably a bit too much more for this. And
> afaiui your quirk list only applies to older stuff.
> 
> At least add a FIXME meanwhile? In a way we have a FIXME already for
> multi-pipe, since we don't try to fall back to fewer pipes if the single
> atomic commit failed.
> 
> Or maybe just don't use 90/270 hw rotation for now since it seems buggy in
> your code anyway.

I was wondering about this (need for special fb layout) myself too, I
agree also given the above comment that it is probably best to only
support 0/180 degree hardware rotation for now, I will do for the next
version (and add a TODO comment).


>> +
>> +	if (!(rotation & valid_mask)) {
>> +		fb_helper->rotations |= rotation;
>> +		return;
>> +	}
>> +
>> +	fb_crtc->rotation = rotation;
>> +	/* Rotating in hardware, fbcon should not rotate */
>> +	fb_helper->rotations |= DRM_MODE_ROTATE_0;
> 
> Wrong bitopt I think.

No this is intentional, if we've a panel requiring say 90 degree rotation
which we will do in software and another panel (weird example) doing 180
degree rotation in hardware, then we want to or both
DRM_MODE_ROTATE_90 and DRM_MODE_ROTATE_0 into the rotations bitmask
(0 since the hardware rotation requires no sw rotation).
The rotations bitmask is the *combination* of all rotations we need
fbcon to do in software and when that ends up being more then one
rotation we chicken out and just don't do any software rotation,
maybe I should rename rotations to sw_rotations?

A better real world example is a 90 degree rotated panel with
an external monitor, in that case for the panel we hit:

	if (!(rotation & valid_mask)) {
		fb_helper->rotations |= rotation;
		return;
	}

Or-ing in the panel's DRM_MODE_ROTATE_90.

And for the monitor we hit:

	if (rotation = DRM_MODE_ROTATE_0 || !plane->rotation_property) {
		fb_helper->rotations |= rotation;
		return;
	}

Or-ing in the monitors's DRM_MODE_ROTATE_0.

So we end up with 2 bits set in fb_helper->rotations, hitting the
default in the switch case and picking FB_ROTATE_UR, since we cannot
satisfy both rotations in fbcon at the same time.


> Or you're doing some really funny control logic by oring in another value
> to hit the default case below which doesn't rotate anything. I think that
> should be done explicitly, by explicitly setting to rotation to ROTATE_0
> instead of this. Same for the check above.

I hope my explanation above explains why I'm or-ing together rotations,
basically I want to detect if we need more then 1 type of software-rotation
in fbcon and in that case bail out and fallback to FB_ROTATE_UR.

Regards,

Hans


> 
>> +}
>> +
>>   static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>>   			    u32 width, u32 height)
>>   {
>> @@ -2393,6 +2449,7 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>>   		drm_fb_helper_modeset_release(fb_helper,
>>   					      &fb_helper->crtc_info[i].mode_set);
>>   
>> +	fb_helper->rotations = 0;
>>   	drm_fb_helper_for_each_connector(fb_helper, i) {
>>   		struct drm_display_mode *mode = modes[i];
>>   		struct drm_fb_helper_crtc *fb_crtc = crtcs[i];
>> @@ -2412,6 +2469,7 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>>   			modeset->mode = drm_mode_duplicate(dev,
>>   							   fb_crtc->desired_mode);
>>   			drm_connector_get(connector);
>> +			drm_setup_crtc_rotation(fb_helper, fb_crtc, connector);
>>   			modeset->connectors[modeset->num_connectors++] = connector;
>>   			modeset->x = offset->x;
>>   			modeset->y = offset->y;
>> @@ -2453,6 +2511,20 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
>>   		}
>>   	}
>>   	mutex_unlock(&fb_helper->dev->mode_config.mutex);
>> +
>> +	switch (fb_helper->rotations) {
>> +	case DRM_MODE_ROTATE_90:
>> +		info->fbcon_rotate_hint = FB_ROTATE_CCW;
>> +		break;
>> +	case DRM_MODE_ROTATE_180:
>> +		info->fbcon_rotate_hint = FB_ROTATE_UD;
>> +		break;
>> +	case DRM_MODE_ROTATE_270:
>> +		info->fbcon_rotate_hint = FB_ROTATE_CW;
>> +		break;
>> +	default:
>> +		info->fbcon_rotate_hint = FB_ROTATE_UR;
>> +	}
>>   }
>>   
>>   /* Note: Drops fb_helper->lock before returning. */
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index 33fe95927742..4ee834a077a2 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;
>> +	int rotation;
>>   };
>>   
>>   /**
>> @@ -158,6 +159,13 @@ struct drm_fb_helper {
>>   	struct drm_fb_helper_crtc *crtc_info;
>>   	int connector_count;
>>   	int connector_info_alloc_count;
>> +	/**
>> +	 * @rotations:
>> +	 * Bitmask of all rotations requested for panel-orientation which
>> +	 * could not be handled in hardware. If only one bit is set
>> +	 * fbdev->fbcon_rotate_hint gets set to the requested rotation.
>> +	 */
>> +	int rotations;
>>   	/**
>>   	 * @connector_info:
>>   	 *
>> -- 
>> 2.14.2
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>, Hans de Goede <j.w.r.degoede@gmail.com>
Cc: linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	David Airlie <airlied@linux.ie>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Daniel Drake <drake@endlessm.com>,
	dri-devel@lists.freedesktop.org,
	Bastien Nocera <hadess@hadess.net>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane
Date: Mon, 30 Oct 2017 12:09:27 +0100	[thread overview]
Message-ID: <873cb3a6-342f-a1aa-0569-874d86f320b3@redhat.com> (raw)
In-Reply-To: <20171030095212.fuglrxyc3jpfrnjg@phenom.ffwll.local>

Hi,

On 30-10-17 10:52, Daniel Vetter wrote:
> On Mon, Oct 23, 2017 at 09:14:22AM +0200, Hans de Goede wrote:
>> Apply the "panel orientation" drm connector prop to the primary plane so
>> that fbcon and fbdev using userspace programs display the right way up.
>>
>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Changes in v2:
>> -New patch in v2 of this patch-set
>>
>> Changes in v3:
>> -Use a rotation member in struct drm_fb_helper_crtc and set that from
>>   drm_setup_crtcs instead of looping over all crtc's to find the right one
>>   later
>> -Since we now no longer look at rotation quirks directly in the fbcon code,
>>   set fb_info.fbcon_rotate_hint when the panel is not mounted upright and
>>   we cannot use hardware rotation
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 76 +++++++++++++++++++++++++++++++++++++++--
>>   include/drm/drm_fb_helper.h     |  8 +++++
>>   2 files changed, 82 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index 116d1f1337c7..e0f95f2cc52f 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -41,6 +41,7 @@
>>   #include <drm/drm_atomic.h>
>>   #include <drm/drm_atomic_helper.h>
>>   
>> +#include "drm_crtc_internal.h"
>>   #include "drm_crtc_helper_internal.h"
>>   
>>   static bool drm_fbdev_emulation = true;
>> @@ -350,6 +351,7 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>>   static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool active)
>>   {
>>   	struct drm_device *dev = fb_helper->dev;
>> +	struct drm_plane_state *plane_state;
>>   	struct drm_plane *plane;
>>   	struct drm_atomic_state *state;
>>   	int i, ret;
>> @@ -368,8 +370,6 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool activ
>>   retry:
>>   	plane_mask = 0;
>>   	drm_for_each_plane(plane, dev) {
>> -		struct drm_plane_state *plane_state;
>> -
>>   		plane_state = drm_atomic_get_plane_state(state, plane);
>>   		if (IS_ERR(plane_state)) {
>>   			ret = PTR_ERR(plane_state);
>> @@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool activ
>>   
>>   	for (i = 0; i < fb_helper->crtc_count; i++) {
>>   		struct drm_mode_set *mode_set = &fb_helper->crtc_info[i].mode_set;
>> +		struct drm_plane *primary = mode_set->crtc->primary;
>> +
>> +		/* Cannot fail as we've already gotten the plane state above */
>> +		plane_state = drm_atomic_get_new_plane_state(state, primary);
>> +		plane_state->rotation = fb_helper->crtc_info[i].rotation;
>>   
>>   		ret = __drm_atomic_helper_set_config(mode_set, state);
>>   		if (ret != 0)
>> @@ -2334,6 +2339,57 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
>>   	return best_score;
>>   }
>>   
>> +/*
>> + * This function checks if rotation is necessary because of panel orientation
>> + * and if it is, if it is supported.
>> + * If rotation is necessary and supported, its gets set in fb_crtc.rotation.
>> + * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
>> + * or-ed into fb_helper->rotations. In drm_setup_crtcs_fb() we check if only
>> + * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
>> + * the unsupported rotation.
>> + */
>> +static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
>> +				    struct drm_fb_helper_crtc *fb_crtc,
>> +				    struct drm_connector *connector)
>> +{
>> +	struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
>> +	uint64_t valid_mask = 0;
>> +	int i, rotation;
>> +
>> +	fb_crtc->rotation = DRM_MODE_ROTATE_0;
>> +
>> +	switch (connector->display_info.panel_orientation) {
>> +	case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
>> +		rotation = DRM_MODE_ROTATE_180;
>> +		break;
>> +	case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
>> +		rotation = DRM_MODE_ROTATE_90;
>> +		break;
>> +	case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
>> +		rotation = DRM_MODE_ROTATE_270;
>> +		break;
> 
> For 90/270 hw rotation you need to flip the coordinates/sizes of the fb.

You're probably right, I don't have any hardware supporting
270 degree rotation to test this with.

>> +	default:
>> +		rotation = DRM_MODE_ROTATE_0;
>> +	}
>> +
>> +	if (rotation == DRM_MODE_ROTATE_0 || !plane->rotation_property) {
>> +		fb_helper->rotations |= rotation;
>> +		return;
>> +	}
>> +
>> +	for (i = 0; i < plane->rotation_property->num_values; i++)
>> +		valid_mask |= (1ULL << plane->rotation_property->values[i]);
> 
> This isn't a good enough check for atomic drivers (and not for gen9+ intel
> hw), since we might expose 90° rotations, but it only works if you have
> the correct tiling format.
> 
> For atomic drivers it'd be really good if we could do a TEST_ONLY commit
> first, and if that fails, fall back to sw rotation.
> 
> But that poses a bit a chicken&egg with creating the framebuffer (we need
> one for the TEST_ONLY), so probably a bit too much more for this. And
> afaiui your quirk list only applies to older stuff.
> 
> At least add a FIXME meanwhile? In a way we have a FIXME already for
> multi-pipe, since we don't try to fall back to fewer pipes if the single
> atomic commit failed.
> 
> Or maybe just don't use 90/270 hw rotation for now since it seems buggy in
> your code anyway.

I was wondering about this (need for special fb layout) myself too, I
agree also given the above comment that it is probably best to only
support 0/180 degree hardware rotation for now, I will do for the next
version (and add a TODO comment).


>> +
>> +	if (!(rotation & valid_mask)) {
>> +		fb_helper->rotations |= rotation;
>> +		return;
>> +	}
>> +
>> +	fb_crtc->rotation = rotation;
>> +	/* Rotating in hardware, fbcon should not rotate */
>> +	fb_helper->rotations |= DRM_MODE_ROTATE_0;
> 
> Wrong bitopt I think.

No this is intentional, if we've a panel requiring say 90 degree rotation
which we will do in software and another panel (weird example) doing 180
degree rotation in hardware, then we want to or both
DRM_MODE_ROTATE_90 and DRM_MODE_ROTATE_0 into the rotations bitmask
(0 since the hardware rotation requires no sw rotation).
The rotations bitmask is the *combination* of all rotations we need
fbcon to do in software and when that ends up being more then one
rotation we chicken out and just don't do any software rotation,
maybe I should rename rotations to sw_rotations?

A better real world example is a 90 degree rotated panel with
an external monitor, in that case for the panel we hit:

	if (!(rotation & valid_mask)) {
		fb_helper->rotations |= rotation;
		return;
	}

Or-ing in the panel's DRM_MODE_ROTATE_90.

And for the monitor we hit:

	if (rotation == DRM_MODE_ROTATE_0 || !plane->rotation_property) {
		fb_helper->rotations |= rotation;
		return;
	}

Or-ing in the monitors's DRM_MODE_ROTATE_0.

So we end up with 2 bits set in fb_helper->rotations, hitting the
default in the switch case and picking FB_ROTATE_UR, since we cannot
satisfy both rotations in fbcon at the same time.


> Or you're doing some really funny control logic by oring in another value
> to hit the default case below which doesn't rotate anything. I think that
> should be done explicitly, by explicitly setting to rotation to ROTATE_0
> instead of this. Same for the check above.

I hope my explanation above explains why I'm or-ing together rotations,
basically I want to detect if we need more then 1 type of software-rotation
in fbcon and in that case bail out and fallback to FB_ROTATE_UR.

Regards,

Hans


> 
>> +}
>> +
>>   static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>>   			    u32 width, u32 height)
>>   {
>> @@ -2393,6 +2449,7 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>>   		drm_fb_helper_modeset_release(fb_helper,
>>   					      &fb_helper->crtc_info[i].mode_set);
>>   
>> +	fb_helper->rotations = 0;
>>   	drm_fb_helper_for_each_connector(fb_helper, i) {
>>   		struct drm_display_mode *mode = modes[i];
>>   		struct drm_fb_helper_crtc *fb_crtc = crtcs[i];
>> @@ -2412,6 +2469,7 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>>   			modeset->mode = drm_mode_duplicate(dev,
>>   							   fb_crtc->desired_mode);
>>   			drm_connector_get(connector);
>> +			drm_setup_crtc_rotation(fb_helper, fb_crtc, connector);
>>   			modeset->connectors[modeset->num_connectors++] = connector;
>>   			modeset->x = offset->x;
>>   			modeset->y = offset->y;
>> @@ -2453,6 +2511,20 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
>>   		}
>>   	}
>>   	mutex_unlock(&fb_helper->dev->mode_config.mutex);
>> +
>> +	switch (fb_helper->rotations) {
>> +	case DRM_MODE_ROTATE_90:
>> +		info->fbcon_rotate_hint = FB_ROTATE_CCW;
>> +		break;
>> +	case DRM_MODE_ROTATE_180:
>> +		info->fbcon_rotate_hint = FB_ROTATE_UD;
>> +		break;
>> +	case DRM_MODE_ROTATE_270:
>> +		info->fbcon_rotate_hint = FB_ROTATE_CW;
>> +		break;
>> +	default:
>> +		info->fbcon_rotate_hint = FB_ROTATE_UR;
>> +	}
>>   }
>>   
>>   /* Note: Drops fb_helper->lock before returning. */
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index 33fe95927742..4ee834a077a2 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;
>> +	int rotation;
>>   };
>>   
>>   /**
>> @@ -158,6 +159,13 @@ struct drm_fb_helper {
>>   	struct drm_fb_helper_crtc *crtc_info;
>>   	int connector_count;
>>   	int connector_info_alloc_count;
>> +	/**
>> +	 * @rotations:
>> +	 * Bitmask of all rotations requested for panel-orientation which
>> +	 * could not be handled in hardware. If only one bit is set
>> +	 * fbdev->fbcon_rotate_hint gets set to the requested rotation.
>> +	 */
>> +	int rotations;
>>   	/**
>>   	 * @connector_info:
>>   	 *
>> -- 
>> 2.14.2
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-10-30 11:09 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23  7:14 [PATCH v3 0/7] drm/fbdev: Panel orientation connector property support Hans de Goede
2017-10-23  7:14 ` Hans de Goede
2017-10-23  7:14 ` [PATCH v3 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-23 12:43   ` Sebastian Reichel
2017-10-23 12:43     ` Sebastian Reichel
2017-10-23 13:54     ` Hans de Goede
2017-10-23 13:54       ` Hans de Goede
2017-10-23  7:14 ` [PATCH v3 2/7] drm: Add panel orientation quirks Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-30  9:39   ` [Intel-gfx] " Daniel Vetter
2017-10-30  9:39     ` Daniel Vetter
2017-10-30 10:52     ` [Intel-gfx] " Hans de Goede
2017-10-30 10:52       ` Hans de Goede
2017-10-23  7:14 ` [PATCH v3 3/7] drm: Add support for a panel-orientation connector property Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-30  9:43   ` [Intel-gfx] " Daniel Vetter
2017-10-30  9:43     ` Daniel Vetter
2017-10-30 10:57     ` Hans de Goede
2017-10-30 10:57       ` Hans de Goede
2017-10-31 10:07       ` [Intel-gfx] " Daniel Vetter
2017-10-31 10:07         ` Daniel Vetter
2017-10-23  7:14 ` [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-30  9:52   ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary Daniel Vetter
2017-10-30  9:52     ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane Daniel Vetter
2017-10-30 11:09     ` Hans de Goede [this message]
2017-10-30 11:09       ` Hans de Goede
2017-10-31 10:14       ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary Daniel Vetter
2017-10-31 10:14         ` [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane Daniel Vetter
2017-10-31 10:24         ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary Hans de Goede
2017-10-31 10:24           ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane Hans de Goede
2017-10-31 10:40           ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary Daniel Vetter
2017-10-31 10:40             ` [Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane Daniel Vetter
2017-10-23  7:14 ` [PATCH v3 5/7] drm/i915: Add "panel orientation" property to the panel connector Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-23  7:14 ` [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-30  9:53   ` [Intel-gfx] [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation Daniel Vetter
2017-10-30  9:53     ` [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk Daniel Vetter
2017-10-30 11:10     ` [Intel-gfx] [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation Hans de Goede
2017-10-30 11:10       ` [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk Hans de Goede
2017-11-04 13:13     ` [Intel-gfx] [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation Hans de Goede
2017-11-04 13:13       ` [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk Hans de Goede
2017-10-23  7:14 ` [PATCH v3 7/7] fbcon: Remove dmi quirk table Hans de Goede
2017-10-23  7:14   ` Hans de Goede
2017-10-23  7:33 ` ✗ Fi.CI.BAT: warning for drm/fbdev: Panel orientation connector property support Patchwork
2017-10-23  9:02   ` Hans de Goede
2017-10-23  9:04 ` ✗ Fi.CI.IGT: failure " Patchwork
2017-10-30  9:58 ` [Intel-gfx] [PATCH v3 0/7] " Daniel Vetter
2017-10-30  9:58   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873cb3a6-342f-a1aa-0569-874d86f320b3@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=airlied@linux.ie \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=drake@endlessm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hadess@hadess.net \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=j.w.r.degoede@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.