On Mon, Sep 16, 2013 at 06:35:12PM +0100, Damien Lespiau wrote:
> On Fri, Sep 13, 2013 at 04:10:24PM +0000, Joakim Plate wrote:
> > Damien Lespiau <damien.lespiau <at> intel.com> writes:
> >
> > > +static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
> > > + { 1920, 1080, 24, 0,
> > > + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING
> > },
> > > + { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE,
> > > + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> > > + { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE,
> > > + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> > > + { 1280, 720, 50, 0,
> > > + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING
> > },
> > > + { 1280, 720, 60, 0,
> > > + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
> > > +};
> >
> >
> > I may be missing something here... But..
>
> Oops, did not see your answer, please don't forget to include me in Cc:
> next time and not just the list.
>
> > The frame packed modes are much higher in pixels than this and include frame
> > packing.
> > 1080*2+45=2050
> > 720*2+30=1470
> >
> > Unless you intend to hide the left/right split in mesa or other place, we
> > need to get the ability to render to both fields somehow.
> >
> > Either as the full 2050 pixels high or at 1080*2 and the driver adds the
> > blanking.
>
> Right, so at the moment, my proposition is that userspace is responsible for
> giving us a framebuffer with the right dimensions. For instance in
> intel-gpu-tools's testdisplay I have:
>
> struct box {
> int x, y, width, height;
> };
>
> struct stereo_fb_layout {
> int fb_width, fb_height;
> struct box left, right;
> };
>
> static void stereo_fb_layout_from_mode(struct stereo_fb_layout *layout,
> drmModeModeInfo *mode)
> {
> unsigned int format = mode->flags & DRMTEST_MODE_FLAG_3D_MASK;
> const int hdisplay = mode->hdisplay, vdisplay = mode->vdisplay;
>
> switch (format) {
>
> [...]
>
> case DRM_MODE_FLAG_3D_FRAME_PACKING:
> {
> int vactive_space = mode->vtotal - vdisplay;
>
> layout->fb_width = hdisplay;
> layout->fb_height = 2 * vdisplay + vactive_space;
>
> box_init(&layout->left,
> 0, 0, hdisplay, vdisplay);
> box_init(&layout->right,
> 0, vdisplay + vactive_space, hdisplay, vdisplay);
> break;
> }
>
> and then adjust the timings if needed:
>
> static void adjust_stereo_timings(drmModeModeInfo *mode)
> {
> unsigned int layout = mode->flags & DRMTEST_MODE_FLAG_3D_MASK;
> uint16_t vdisplay, vactive_space;
>
> switch (layout) {
> case DRM_MODE_FLAG_3D_TOP_AND_BOTTOM:
> case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
> return;
> case DRM_MODE_FLAG_3D_FRAME_PACKING:
> vactive_space = mode->vtotal - mode->vdisplay;
> vdisplay = mode->vdisplay;
>
> mode->vdisplay += vdisplay + vactive_space;
> mode->vsync_start += vdisplay + vactive_space;
> mode->vsync_end += vdisplay + vactive_space;
> mode->vtotal += vdisplay + vactive_space;
> mode->clock = (mode->vtotal * mode->htotal * mode->vrefresh) /
> 1000;
I'm wondering if we should take in the 2D mode timings and do this
adjustment in the kernel instead. Not quite sure what the pros/cons
are for doing it in userland.
Oh and now that vactive is actually part of the framebuffer as well, we
need to be more careful in the kernel how we adjust the mode. I can't
recall if we have special hardware needs wrt. the vertical timings, but
if we do we should probably review them all to avoid adjustments that
would cause issues with stereo modes.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
