Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1586585
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC |
| Date | 2017-02-23 02:00 +0100 |
| Message-ID | <tdPVg-1JC-11@gated-at.bofh.it> (permalink) |
| References | <tbatb-2fc-5@gated-at.bofh.it> <tbatb-2fc-3@gated-at.bofh.it> <tdfyp-161-5@gated-at.bofh.it> <tdgkN-1pa-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
Hi Ville, Stefan,
On Tue, Feb 21, 2017 at 12:55:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 21, 2017 at 11:00:59AM +0100, Stefan Lengfeld wrote:
> > 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'.
>
> Have a look at matroxfb.
>
> >
> > 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 ))
>
> Again the matrox driver is different. And looks like unichrome might have
> done something even more exotic with the argument.
>
> But I do agree that using this with the kms fbdev implementation could
> be quite problematic as you can't actually know which crtcs the
> fb_helper has picked.
I'm not sure what a good solution might be then. Is just waiting for
always the first crtc acceptable? All the code I could find is passing
0 as an argument anyway, so that's effectively the same behaviour
anyway here. And getting tearing might be a good argument in favour of
moving to KMS :)
Thanks
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-02-15 17:20 +0100
Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Stefan Lengfeld <contact@stefanchrist.eu> - 2017-02-21 11:10 +0100
Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Ville Syrjälä <ville.syrjala@linux.intel.com> - 2017-02-21 12:00 +0100
Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-02-23 02:00 +0100
Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Stefan Lengfeld <contact@stefanchrist.eu> - 2017-02-23 10:10 +0100
Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Daniel Vetter <daniel@ffwll.ch> - 2017-02-26 22:20 +0100
Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Michel Dänzer <michel@daenzer.net> - 2017-02-22 08:10 +0100
csiph-web