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:
[...]
and then adjust the timings if needed:
So, actually it seems that this will change a bit. User space still needs to compute a correct fb size. In the case of frame packing, note that user-space also needs to add the vblank lines, because it has to know where to place the second eye starting at vdisplay + vblank.
The kernel will be in charge of tweaking the timings if needed though, see: http://lists.freedesktop.org/archives/dri-devel/2013-September/045386.html