I'm not sure if I'm missing something here, but I don't see how this is
supposed to work.

This just multiplies the height of the drm_mode_fb_cmd2 object with the
number of buffers. Let's say I have width=1024, height=768, then now I
have a framebuffer which has height=2304 (in the num_buffers=3 case). At
some point this FB is set as the primary plane, giving us a 1024x2304
mode. I don't think that this is intended.

In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at
all. The underlying BO should be larger, but not the FB itself. If this
is supposed to work, then the fbdev helpers should create as many FBs as
there are buffers, and then offset each of these FB into the BO.

What I'm also not seeing is code that handles the fbdev's virtual
resolutions. After all num_buffers should only increase those. Same for
the panning ioctl().

So, is this just a part of a larger series?

I remember seeing such a hack in the Hardkernel vendor kernel. But there
it only worked because of some bug in the crtc (mixer) code.

With best wishes,

P.S.: I'm signed up to dri-devel in digest mode, so sorry if this mail
doesn't properly show up in the corresponding ml thread.
dri-devel mailing list

Reply via email to