On Thu, Mar 5, 2015 at 3:20 PM, Hai Li <hali@xxxxxxxxxxxxxx> wrote: > The framebuffer var width and height should reflect the size of > framebuffer memory allocated, which is the entire surface size. > > In case of dual DSI connectors with TILE properties, this change > makes the whole image show on the dual DSI panel, instead of > duplicated images on both sides. > > Signed-off-by: Hai Li <hali@xxxxxxxxxxxxxx> > --- > drivers/gpu/drm/msm/msm_fbdev.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c > index df60f65..d3e8b14 100644 > --- a/drivers/gpu/drm/msm/msm_fbdev.c > +++ b/drivers/gpu/drm/msm/msm_fbdev.c > @@ -169,7 +169,8 @@ static int msm_fbdev_create(struct drm_fb_helper *helper, > } > > drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth); > - drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height); > + drm_fb_helper_fill_var(fbi, helper, > + sizes->surface_width, sizes->surface_height); > so, I believe the intention for separation if surface_width/height and fb_width/height, it to allocate a buffer that is big enough (width and height) for all connected displays (so as to not leave some display scanning out too small of a buffer), but size the fbdev buffer small enough that text would be visible on all screens. Using surface_width/height here instead of fb_width/height would break that. But I think I have a different idea.. we could implement fb helper func initial_config() to just call drm_pick_crtcs() (which we'd have to export), and then for each of the crtcs[n] connected to a connector with TILE property, populate the offsets[n].x/y. Or possibly we should just make drm_setup_crtcs() clever enough to do that automatically.. that would result in larger fb_size and the two crtc's scanning out their own parts of the buffer. BR, -R > dev->mode_config.fb_base = paddr; > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
