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.
It's that fundamental assumption that we break by making the pipe_src
stuff official and which is the part that freaks me out a bit.
> The other drivers are something I would not touch. Given how many places
> we had to frob in i915 I'm somewhat sure I'd not like what I see there
> and then any patch I might cook up would be too half assed to satisfy my
> quality standards anyway.
Yeah, other drivers only need to be audited I think once they start
supporting the pipe_src stuff. But I think the core+helpers should be
able to cope properly.
> As far as always filling the crtc->w,h always goes, I'm not sure that's
> the best idea anyway since we still need the "0 is special" handling.
> Well, we could fill them out, but then we definitely need a flag or
> something to indicate that they came from the mode and not the
> properties, so that we know whether we should overwrite them from
> with {h,v}display during a subsquent modeset or if they should keep
> their current value.
Hm, I guess we can keep that implicit meaning, but then we need a
small helper to get at the crtc viewport, e.g. drm_crtc_viewport_rect
or so. That would also be an excellent place to document this trickery
properly.
Oh and: Such drm changes _really_ must be split out into separate prep
patches cc: dri-devel.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
