On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: > 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. Also, WAITFORGO is a pretty abysmal name. It seems like what you want is a WAITFORHWSYNC or something similar. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
