Hello, 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, Tobias 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 dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
