From: Maxime Ripard <maxime.ripard@bootlin.com>
To: "Noralf Trønnes" <noralf@tronnes.org>
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 v2 3/5] drm/modes: Allow to specify rotation and reflection on the commandline
Date: Thu, 18 Apr 2019 09:43:17 +0200 [thread overview]
Message-ID: <20190418074317.xls44gr3nbhyhop4@flea> (raw)
In-Reply-To: <e42d94f0-7e4e-48b8-d252-6aabc9502235@tronnes.org>
[-- Attachment #1.1: Type: text/plain, Size: 3497 bytes --]
On Wed, Apr 17, 2019 at 04:58:07PM +0200, Noralf Trønnes wrote:
> Den 17.04.2019 16.30, skrev Maxime Ripard:
> > On Tue, Apr 16, 2019 at 04:50:00PM +0200, Noralf Trønnes wrote:
> >> Den 11.04.2019 15.22, 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_fb_helper.c | 4 +-
> >>> drivers/gpu/drm/drm_modes.c | 110 +++++++++++++++++++++++++++------
> >>> include/drm/drm_connector.h | 1 +-
> >>> 3 files changed, 95 insertions(+), 20 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> >>> index b3a5d79436ae..8781897559b2 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -2521,6 +2521,7 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
> >>> struct drm_connector *connector)
> >>> {
> >>> struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
> >>> + struct drm_cmdline_mode *mode = &connector->cmdline_mode;
> >>> uint64_t valid_mask = 0;
> >>> int i, rotation;
> >>>
> >>> @@ -2540,6 +2541,9 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
> >>> rotation = DRM_MODE_ROTATE_0;
> >>> }
> >>>
> >>> + if (mode->rotation != DRM_MODE_ROTATE_0)
> >>> + fb_crtc->rotation = mode->rotation;
> >>> +
> >>
> >> We already have a property to describe initial display/panel rotation.
> >> If we can set connector->display_info.panel_orientation from the video=
> >> parameter, then there's no need to modify drm_fb_helper, it will just work.
> >>
> >> In that case, maybe 'orientation' is a better argument name with values
> >> mapped to the enum.
> >
> > I wouldn't put it at the same level though. As far as I understand it,
> > the orientation is a hardware constraint: the hardware has been
> > designed that way, and should honor that orientation to make it look
> > with the top, well, on top.
> >
> > However, the rotation is more of a user choice, and you could
> > definitely envision having a combination of a rotation and an
> > orientation constraint.
> >
>
> Does this rotation only apply to the fbdev emulation and should not
> propogate to DRM userspace?
I guess it definitely should be propagated to the DRM userspace.
> I actually don't understand how the DRM plane rotation works for 90/270
> rotation. Should the framebuffer width/height be swapped when attaching
> to a rotated plane?
I'm not sure either, especially since the stride might be a bit
different too. However, since (as you pointed out) it would be much
harder to support, I left it out of that patch series for the moment.
> Btw drm_setup_crtc_rotation() doesn't support 90/270 plane rotation even
> if the hw supports it. It will instead sw rotate fbcon, but fbdev
> userspace remains unrotated.
That would need to be addressed eventually yep.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: eben@raspberrypi.org, David Airlie <airlied@linux.ie>,
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 v2 3/5] drm/modes: Allow to specify rotation and reflection on the commandline
Date: Thu, 18 Apr 2019 09:43:17 +0200 [thread overview]
Message-ID: <20190418074317.xls44gr3nbhyhop4@flea> (raw)
In-Reply-To: <e42d94f0-7e4e-48b8-d252-6aabc9502235@tronnes.org>
[-- Attachment #1.1: Type: text/plain, Size: 3497 bytes --]
On Wed, Apr 17, 2019 at 04:58:07PM +0200, Noralf Trønnes wrote:
> Den 17.04.2019 16.30, skrev Maxime Ripard:
> > On Tue, Apr 16, 2019 at 04:50:00PM +0200, Noralf Trønnes wrote:
> >> Den 11.04.2019 15.22, 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_fb_helper.c | 4 +-
> >>> drivers/gpu/drm/drm_modes.c | 110 +++++++++++++++++++++++++++------
> >>> include/drm/drm_connector.h | 1 +-
> >>> 3 files changed, 95 insertions(+), 20 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> >>> index b3a5d79436ae..8781897559b2 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -2521,6 +2521,7 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
> >>> struct drm_connector *connector)
> >>> {
> >>> struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
> >>> + struct drm_cmdline_mode *mode = &connector->cmdline_mode;
> >>> uint64_t valid_mask = 0;
> >>> int i, rotation;
> >>>
> >>> @@ -2540,6 +2541,9 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
> >>> rotation = DRM_MODE_ROTATE_0;
> >>> }
> >>>
> >>> + if (mode->rotation != DRM_MODE_ROTATE_0)
> >>> + fb_crtc->rotation = mode->rotation;
> >>> +
> >>
> >> We already have a property to describe initial display/panel rotation.
> >> If we can set connector->display_info.panel_orientation from the video=
> >> parameter, then there's no need to modify drm_fb_helper, it will just work.
> >>
> >> In that case, maybe 'orientation' is a better argument name with values
> >> mapped to the enum.
> >
> > I wouldn't put it at the same level though. As far as I understand it,
> > the orientation is a hardware constraint: the hardware has been
> > designed that way, and should honor that orientation to make it look
> > with the top, well, on top.
> >
> > However, the rotation is more of a user choice, and you could
> > definitely envision having a combination of a rotation and an
> > orientation constraint.
> >
>
> Does this rotation only apply to the fbdev emulation and should not
> propogate to DRM userspace?
I guess it definitely should be propagated to the DRM userspace.
> I actually don't understand how the DRM plane rotation works for 90/270
> rotation. Should the framebuffer width/height be swapped when attaching
> to a rotated plane?
I'm not sure either, especially since the stride might be a bit
different too. However, since (as you pointed out) it would be much
harder to support, I left it out of that patch series for the moment.
> Btw drm_setup_crtc_rotation() doesn't support 90/270 plane rotation even
> if the hw supports it. It will instead sw rotate fbcon, but fbdev
> userspace remains unrotated.
That would need to be addressed eventually yep.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-04-18 7:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 13:22 [PATCH v2 0/5] drm/vc4: Allow for more boot-time configuration Maxime Ripard
2019-04-11 13:22 ` Maxime Ripard
2019-04-11 13:22 ` [PATCH v2 1/5] drm/modes: Rewrite the command line parser Maxime Ripard
2019-04-11 13:22 ` Maxime Ripard
2019-04-12 16:02 ` kbuild test robot
2019-04-12 16:02 ` kbuild test robot
2019-04-11 13:22 ` [PATCH v2 2/5] drm/modes: Support modes names on the command line Maxime Ripard
2019-04-11 13:22 ` Maxime Ripard
2019-04-11 13:22 ` [PATCH v2 3/5] drm/modes: Allow to specify rotation and reflection on the commandline Maxime Ripard
2019-04-11 13:22 ` Maxime Ripard
2019-04-15 16:39 ` Daniel Vetter
2019-04-15 16:39 ` Daniel Vetter
2019-04-16 14:50 ` Noralf Trønnes
2019-04-16 14:50 ` Noralf Trønnes
2019-04-17 14:30 ` Maxime Ripard
2019-04-17 14:30 ` Maxime Ripard
2019-04-17 14:58 ` Noralf Trønnes
2019-04-17 14:58 ` Noralf Trønnes
2019-04-18 7:43 ` Maxime Ripard [this message]
2019-04-18 7:43 ` Maxime Ripard
2019-04-11 13:22 ` [PATCH v2 4/5] drm/modes: Parse overscan properties Maxime Ripard
2019-04-11 13:22 ` Maxime Ripard
2019-04-15 16:45 ` Daniel Vetter
2019-04-15 16:45 ` Daniel Vetter
2019-04-16 14:52 ` Noralf Trønnes
2019-04-16 14:52 ` Noralf Trønnes
2019-04-17 14:07 ` Maxime Ripard
2019-04-17 14:07 ` Maxime Ripard
2019-04-17 15:30 ` Noralf Trønnes
2019-04-17 15:30 ` Noralf Trønnes
2019-04-17 15:38 ` Noralf Trønnes
2019-04-17 15:38 ` Noralf Trønnes
2019-04-11 13:22 ` [PATCH v2 5/5] drm/selftests: Add command line parser selftests Maxime Ripard
2019-04-11 13:22 ` Maxime Ripard
2019-04-12 7:18 ` kbuild test robot
2019-04-12 7:18 ` kbuild test robot
2019-04-12 9:55 ` kbuild test robot
2019-04-12 9:55 ` kbuild test robot
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=20190418074317.xls44gr3nbhyhop4@flea \
--to=maxime.ripard@bootlin.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eben@raspberrypi.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=noralf@tronnes.org \
--cc=paul.kocialkowski@bootlin.com \
--cc=seanpaul@chromium.org \
--cc=thomas.petazzoni@bootlin.com \
/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.