On Wed, Apr 27, 2011 at 03:34:42PM +0100, Chris Wilson wrote: > On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > > > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > >> float scale_x, scale_y; > > > > > > No float in kernel. Would have to use fixed point. > > > > Bleh, of course ;-) 32bit with a 16 bit shift should be good enough > > for all scaling needs > > Or just specify the source size. You already know the output size... The source size needs to be specified with sub-pixel precision. Otherwise you can't do accurate clipping. Another thing to consider is whether you expect user space to do the clipping against the CRTC dimensions, or if the kernel will do it. Personally I like the OpenWF Display approach with it's attributes, and atomic commits. That kind of thing is a lot easier to extend than a fixed structure which is supposed to have all the bells and whistles from day 1. Also some overlay related properties are in fact more CRTC properties, eg. on OMAP3 colorkeying and alpha blending are configured for the whole output path, not for individual overlays. Perhaps connector properties can be abused for those, even though they have nothing to do with connectors as such. But some way to atomically commit the whole state should be available. -- Ville Syrjälä syrjala@xxxxxx http://www.sci.fi/~syrjala/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
