On Thu, Aug 14, 2014 at 07:36:13PM +0200, Daniel Vetter wrote: > On Thu, Aug 14, 2014 at 6:45 PM, Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote: > >> On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä > >> <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> > My quick grep audit tells me the viewport check and > >> > drm_primary_helper_update() are the only places in the core that care. > >> > The latter is rather dubious anyway since the clipping should be done > >> > against the adjusted mode and not the user specified mode, so anyone > >> > using that is already dancing on thin ice. > >> > >> My understanding has always been that the requested mode is what > >> userspace plans to feed into the pipe, and the adjusted mode is what > >> actually lands in the sink. Yeah there's some hilarity in the vblank > >> code which somehow presumes that the vblank counter works with the > >> adjusted mode because that's what i915 needs. > > > > The problem with clipping planes to the user size is that the driver is > > free to frob the mode a bit to line it up with hardware constraints. So > > what the user requested might be a few pixels off compared to what the > > hardware will end up using, and then if you configure the plane > > blindly using the coordinates clipped against the user size, the > > hardware may get somewhat upset. > > Hm, I've thought we didn't do that yet, but only frobbed the adjusted > mode to make it fit our requirements for e.g interlaced stuff. I don't > think it would be good if we start doing that since there's no way for > userspace to be aware of the resulting single-pixel border of garbage. > > _If_ we need to do that I think we should frob modes when adding them > to the connector mode list. Sure but the user can supply any mode, doesn't have to be on any list. And the only sane rule for the frobbing would be that you can (slightly) reduce hdisp/vdisp but never expand them so that there will never be any extra garbage exposed (and the FB might not be big enough anyway). But even reducing hdisp/vdisp by one pixel can be enough to anger the hardware if a plane then extends one pixel into the blanking. This isn't much of a problem for i915 though. The hardware is generally good enough to not need it. Double wide and (s)dvo/lvds gang mode are the only exception that comes to mind. Even there we just need to make pipe src width even, but still that's something we have to account when clipping planes. On older hardware there were generally more restrictions eg. some legacy baggage from VGA days which required horizontal timings to be multiples of 8. I also "fondly" remember much more magic timing restrictions in certain pieces hardware which were something close to "if (foo*bar % this == that) frob else don't". IMO these kinds of restrictions are too magic to make rejecting the mode an option, so frobbing is the lesser of two evils. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
