From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes
Date: Tue, 17 Sep 2013 16:32:59 +0300 [thread overview]
Message-ID: <20130917133259.GV4531@intel.com> (raw)
In-Reply-To: <20130917132041.GA3977@strange.amr.corp.intel.com>
On Tue, Sep 17, 2013 at 02:20:41PM +0100, Damien Lespiau wrote:
> On Tue, Sep 17, 2013 at 12:37:48PM +0200, Daniel Vetter wrote:
> > I guess we should start to check that. For 3d framebuffers with 2
> > separate buffer handles for each plane I think we need to add another flag
> > to addfb2, e.g.
> >
> > #define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, doubles plane count */
> >
> > and then also throw in the respective check code into the core that
> > userspace supplies sufficient amounts of buffers in framebuffer_check()
> > by adjusting drM_format_num_planes and drm_format_plane_cpp.
>
> Would we really need that flag? we can just count the number of buffers
> and decide from that number whether we're in the 1 or 2 buffer(s) case?
I'd go with explicit flags. We have one for interlaced already. Although
ATM the interlaced flag must mean that the fields are interleaved in the
same buffer. But if we want separate buffers for each field, we need a
flag for that too. Or we just pretend the old interlace flag doesn't
exist yet and steal it for that purpose. I don't think anyone is using
the flag yet. But anyway we'd need a new ioctl :(
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-09-17 13:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 17:48 HDMI stereo support v4 Damien Lespiau
2013-09-16 17:48 ` [PATCH 01/12] drm: Move the GET_CAP macros next to the corresponding ioctl structure Damien Lespiau
2013-09-16 17:48 ` [PATCH 02/12] drm: Add a SET_CLIENT_CAP ioctl Damien Lespiau
2013-09-16 17:48 ` [PATCH 03/12] drm: Add HDMI stereo 3D flags to struct drm_mode_modeinfo Damien Lespiau
2013-09-16 17:48 ` [PATCH 04/12] drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctl Damien Lespiau
2013-09-16 17:48 ` [PATCH 05/12] drm/edid: Expose mandatory stereo modes for HDMI sinks Damien Lespiau
2013-09-16 18:29 ` Ville Syrjälä
2013-09-16 21:28 ` Damien Lespiau
2013-09-17 13:48 ` Damien Lespiau
2013-09-16 17:48 ` [PATCH 06/12] drm: Extract add_hdmi_mode() out of do_hdmi_vsdb_modes() Damien Lespiau
2013-09-16 17:48 ` [PATCH 07/12] drm: Reject modes with more than 1 stereo flags set Damien Lespiau
2013-09-16 17:48 ` [PATCH 08/12] drm: Set the relevant infoframe field when scanning out a 3D mode Damien Lespiau
2013-09-16 18:59 ` Ville Syrjälä
2013-09-16 17:48 ` [PATCH 09/12] drm: Track the number of buffers that compose a framebuffer Damien Lespiau
2013-09-16 17:48 ` [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes Damien Lespiau
2013-09-17 8:20 ` [Intel-gfx] " Ville Syrjälä
2013-09-17 9:03 ` Damien Lespiau
2013-09-17 9:54 ` Ville Syrjälä
2013-09-17 10:37 ` [Intel-gfx] " Daniel Vetter
2013-09-17 11:02 ` Ville Syrjälä
2013-09-17 13:34 ` [Intel-gfx] " Daniel Vetter
2013-09-17 13:20 ` Damien Lespiau
2013-09-17 13:32 ` Ville Syrjälä [this message]
2013-09-17 13:33 ` Daniel Vetter
2013-09-16 17:48 ` [PATCH 11/12] drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modes Damien Lespiau
2013-09-17 8:22 ` Ville Syrjälä
2013-09-17 8:52 ` [Intel-gfx] " Damien Lespiau
2013-09-16 17:48 ` [PATCH 12/12] drm: Carry over the stereo flags when adding the alternate mode Damien Lespiau
2013-09-17 9:17 ` HDMI stereo support v4 Damien Lespiau
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=20130917133259.GV4531@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=damien.lespiau@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).