On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote:
> On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote:
> > With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO
> > (breaking standard applications).
>
> Applications using the standard fbdev API won't work with manual update
> displays anyway. You need omapfb specific code to handle it so having
> another small difference is not a big deal.
>
> In DirectFB the that's trivial since there's already a simple omap
> gfxdriver where you could override the default flip functionality with
> WAITFORGO based stuff.
>
> Or, as I said, you could add another standard ioctl and fix up userspace
> to use it where appropriate and if the kernel driver supports it.
>
It seems like the WAITFORGO semantics could be layered on top of drivers
using deferred I/O pretty easily, but the question is whether this is
something that userspace plans to make general use of or not. If the only
user of it in userspace code is OMAP-specific, then there's probably not
a lot of point in moving it over to be generic, but if there are
sufficient cases where userspace cares about this information independent
of WAITFORVSYNC for manual update displays, then we can certainly look at
moving it over for those cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
