Re: [PATCH v3 3/6] drm/modes: Allow to specify rotation and reflection on the commandline

From: "Noralf Trønnes" <noralf@tronnes.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: eben@raspberrypi.org, David Airlie <airlied@linux.ie>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	dri-devel@lists.freedesktop.org,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Sean Paul <seanpaul@chromium.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 3/6] drm/modes: Allow to specify rotation and reflection on the commandline
Date: Wed, 12 Jun 2019 15:21:19 +0200	[thread overview]
Message-ID: <c73e9c29-e20b-65e0-553c-67b9c2cd349a@tronnes.org> (raw)
In-Reply-To: <20190611132049.njlrgbtobzgyzyzh@flea>

Den 11.06.2019 15.20, skrev Maxime Ripard:
> Hi Noralf,
> 
> On Fri, Apr 19, 2019 at 10:53:28AM +0200, Noralf Trønnes wrote:
>> Den 18.04.2019 18.40, skrev Noralf Trønnes:
>>>
>>>
>>> Den 18.04.2019 14.41, skrev Maxime Ripard:
>>>> Rotations and reflections setup are needed in some scenarios to initialise
>>>> properly the initial framebuffer. Some drivers already had a bunch of
>>>> quirks to deal with this, such as either a private kernel command line
>>>> parameter (omapdss) or on the device tree (various panels).
>>>>
>>>> In order to accomodate this, let's create a video mode parameter to deal
>>>> with the rotation and reflexion.
>>>>
>>>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>>> ---
>>>>  drivers/gpu/drm/drm_client_modeset.c |  10 +++-
>>>>  drivers/gpu/drm/drm_modes.c          | 110 ++++++++++++++++++++++------
>>>>  include/drm/drm_connector.h          |   9 ++-
>>>>  3 files changed, 109 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c
>>>> index f2869c82510c..15145d2c86d5 100644
>>>> --- a/drivers/gpu/drm/drm_client_modeset.c
>>>> +++ b/drivers/gpu/drm/drm_client_modeset.c
>>>> @@ -823,6 +823,7 @@ EXPORT_SYMBOL(drm_client_modeset_probe);
>>>>  bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int *rotation)
>>>>  {
>>>>  	struct drm_connector *connector = modeset->connectors[0];
>>>> +	struct drm_cmdline_mode *cmdline;
>>>>  	struct drm_plane *plane = modeset->crtc->primary;
>>>>  	u64 valid_mask = 0;
>>>>  	unsigned int i;
>>>> @@ -844,6 +845,15 @@ bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int *rotat
>>>>  		*rotation = DRM_MODE_ROTATE_0;
>>>>  	}
>>>>
>>>> +	/**
>>>> +	 * We want the rotation on the command line to overwrite
>>>> +	 * whatever comes from the panel.
>>>> +	 */
>>>> +	cmdline = &connector->cmdline_mode;
>>>> +	if (cmdline->specified &&
>>>> +	    cmdline->rotation != DRM_MODE_ROTATE_0)
>>>
>>> I believe you need to drop that second check, otherwise rotate=0 will
>>> not overwrite panel rotation.
>>>
>>>> +		*rotation = cmdline->rotation;
>>
>> I remembered that you wanted this to propagate to DRM userspace. That's
>> not happening here.
> 
> It's propated to the userspace through the plane's rotation property,
> I just checked.
> 

Oh, so the rotation property stores its value in plane_state->rotation.
And this is set in: drm_client_modeset_commit_atomic() ->
drm_client_panel_rotation(): plane_state->rotation = rotation;

>> The only way I see for that to happen, is to set
>> ->panel_orientation. And to repeat myself, imo that makes
>> 'orientation' a better name for this video= option.
> 
> orientation and rotation are two different things to me. The
> orientation of a panel for example is absolute, while the rotation is
> a transformation. In this particular case, I think that both the
> orientation and the rotation should be taken into account, with the
> orientation being the default state, and the hardware / panel will
> tell us that, while the rotation would be a transformation from that
> default to whatever the user wants.
> 
> More importantly, the orientation is a property of the hardware (ie,
> how the display has been assembled), while the rotation is a software
> construct.
> 
> And if the property being used to expose that is the rotation, I guess
> it would make sense to just use the same name and remain consistent.
> 

Ok, I see. Based on this, I would assume that rotation would be relative
to the orientation, but I see that in this patch rotation doesn't take
orintation into account, it just overwrites it. I don't how userspace
deals with rotation on top of orientation.

Noralf.

> Maxime
> 
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel