From: Stefan Lengfeld <contact@stefanchrist.eu> To: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Daniel Vetter <daniel.vetter@intel.com>, David Airlie <airlied@linux.ie>, Sean Paul <seanpaul@chromium.org>, Jani Nikula <jani.nikula@linux.intel.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Date: Tue, 21 Feb 2017 11:00:59 +0100 [thread overview] Message-ID: <20170221100059.GD17643@sill.h.stcim.de> (raw) In-Reply-To: <a71d7325494bef185d015697cbc9cbcdf37a923f.1487175046.git-series.maxime.ripard@free-electrons.com> Hi Maxime, On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote: > From: Stefan Christ <s.christ@phytec.de> > Maybe change the author here. Only the boilerplate code looks my original patch. The real code is your work ;-) > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or buffer flip for double buffering. It is tested on > the i.MX6. > > Code is based on > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_fb_helper.c | 63 ++++++++++++++++++++++++++++++++++- > include/drm/drm_fb_helper.h | 12 +++++- > 2 files changed, 74 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index c6de87abaca8..15ee9641c725 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1240,6 +1240,69 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > /** > + * drm_fb_helper_ioctl - legacy ioctl implementation > + * @info: fbdev registered by the helper > + * @cmd: ioctl command > + * @arg: ioctl argument > + * > + * A helper to implement the standard fbdev ioctl. Only > + * FBIO_WAITFORVSYNC is implemented for now. > + */ > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, > + unsigned long arg) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_device *dev = fb_helper->dev; > + struct drm_mode_set *mode_set; > + struct drm_crtc *crtc; > + u32 karg; > + int ret = 0; > + > + mutex_lock(&dev->mode_config.mutex); > + if (!drm_fb_helper_is_bound(fb_helper)) { > + ret = -EBUSY; > + goto unlock; > + } > + > + switch (cmd) { > + case FBIO_WAITFORVSYNC: > + if (get_user(karg, (__u32 __user *)arg)) { > + ret = -EFAULT; > + goto unlock; > + } > + > + if (karg >= fb_helper->crtc_count) { > + ret = -EINVAL; > + goto unlock; > + } Ville Syrjälä said [1]: FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want to do this for all the crtcs. Though what that crtc means for fb is rather poorly defined. Don't think it takes the crtc as a parameter in 'arg'. When you look at the existing fb_ioctl implementations in the directory drivers/video/fbdev/, the argument 'arg' is either ignored or must be '0'. Furthmore most exiting userspace code just passes the value "0" as the argument. For example DirectFB: static const int zero = 0; [...] if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC, &zero )) I see two options here: 1/ Just wait for the first vsync event on the first enabled crtc. This is a good approximation for the old framebuffer API. It has no concept of multiple crtcs with concurrenctly running scan out processes. (Maybe apart from extra vendor implementations). So if there are really more than one active crtcs in the system, bad luck with framebuffer API. There will be tearing. Userspace has to use the new DRM/KMS API. 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä described here [2] in the optimal implementation. Kind regards / Mit freundlichen Grüßen Stefan Lengfeld [1] https://lists.freedesktop.org/archives/dri-devel/2017-February/132617.html [2] https://lists.freedesktop.org/archives/dri-devel/2017-February/132820.html
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Lengfeld <contact@stefanchrist.eu> To: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter <daniel.vetter@intel.com> Subject: Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Date: Tue, 21 Feb 2017 11:00:59 +0100 [thread overview] Message-ID: <20170221100059.GD17643@sill.h.stcim.de> (raw) In-Reply-To: <a71d7325494bef185d015697cbc9cbcdf37a923f.1487175046.git-series.maxime.ripard@free-electrons.com> Hi Maxime, On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote: > From: Stefan Christ <s.christ@phytec.de> > Maybe change the author here. Only the boilerplate code looks my original patch. The real code is your work ;-) > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or buffer flip for double buffering. It is tested on > the i.MX6. > > Code is based on > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_fb_helper.c | 63 ++++++++++++++++++++++++++++++++++- > include/drm/drm_fb_helper.h | 12 +++++- > 2 files changed, 74 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index c6de87abaca8..15ee9641c725 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1240,6 +1240,69 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > /** > + * drm_fb_helper_ioctl - legacy ioctl implementation > + * @info: fbdev registered by the helper > + * @cmd: ioctl command > + * @arg: ioctl argument > + * > + * A helper to implement the standard fbdev ioctl. Only > + * FBIO_WAITFORVSYNC is implemented for now. > + */ > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, > + unsigned long arg) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_device *dev = fb_helper->dev; > + struct drm_mode_set *mode_set; > + struct drm_crtc *crtc; > + u32 karg; > + int ret = 0; > + > + mutex_lock(&dev->mode_config.mutex); > + if (!drm_fb_helper_is_bound(fb_helper)) { > + ret = -EBUSY; > + goto unlock; > + } > + > + switch (cmd) { > + case FBIO_WAITFORVSYNC: > + if (get_user(karg, (__u32 __user *)arg)) { > + ret = -EFAULT; > + goto unlock; > + } > + > + if (karg >= fb_helper->crtc_count) { > + ret = -EINVAL; > + goto unlock; > + } Ville Syrjälä said [1]: FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want to do this for all the crtcs. Though what that crtc means for fb is rather poorly defined. Don't think it takes the crtc as a parameter in 'arg'. When you look at the existing fb_ioctl implementations in the directory drivers/video/fbdev/, the argument 'arg' is either ignored or must be '0'. Furthmore most exiting userspace code just passes the value "0" as the argument. For example DirectFB: static const int zero = 0; [...] if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC, &zero )) I see two options here: 1/ Just wait for the first vsync event on the first enabled crtc. This is a good approximation for the old framebuffer API. It has no concept of multiple crtcs with concurrenctly running scan out processes. (Maybe apart from extra vendor implementations). So if there are really more than one active crtcs in the system, bad luck with framebuffer API. There will be tearing. Userspace has to use the new DRM/KMS API. 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä described here [2] in the optimal implementation. Kind regards / Mit freundlichen Grüßen Stefan Lengfeld [1] https://lists.freedesktop.org/archives/dri-devel/2017-February/132617.html [2] https://lists.freedesktop.org/archives/dri-devel/2017-February/132820.html _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-02-21 10:01 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-15 16:19 [PATCH v3 0/2] drm: Support framebuffer panning Maxime Ripard 2017-02-15 16:19 ` Maxime Ripard 2017-02-15 16:19 ` [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev Maxime Ripard 2017-02-15 16:19 ` Maxime Ripard 2017-02-20 17:07 ` Stefan Lengfeld 2017-02-23 0:49 ` Maxime Ripard 2017-02-23 0:49 ` Maxime Ripard 2017-02-26 21:06 ` Daniel Vetter 2017-02-15 16:19 ` [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard 2017-02-15 16:19 ` Maxime Ripard 2017-02-21 10:00 ` Stefan Lengfeld [this message] 2017-02-21 10:00 ` Stefan Lengfeld 2017-02-21 10:55 ` Ville Syrjälä 2017-02-21 10:55 ` Ville Syrjälä 2017-02-23 0:52 ` Maxime Ripard 2017-02-23 0:52 ` Maxime Ripard 2017-02-23 9:02 ` Stefan Lengfeld 2017-02-26 21:11 ` Daniel Vetter 2017-02-22 7:05 ` Michel Dänzer 2017-02-22 7:05 ` Michel Dänzer 2017-02-16 16:40 ` [PATCH v3 0/2] drm: Support framebuffer panning Neil Armstrong 2017-02-16 16:40 ` Neil Armstrong 2017-02-16 16:40 ` Neil Armstrong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170221100059.GD17643@sill.h.stcim.de \ --to=contact@stefanchrist.eu \ --cc=airlied@linux.ie \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jani.nikula@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=maxime.ripard@free-electrons.com \ --cc=seanpaul@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.