On Fri, Nov 9, 2012 at 3:20 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Nov 07, 2012 at 02:29:45PM -0600, Rob Clark wrote:
On Thu, Nov 1, 2012 at 5:39 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote:
On Thu, 1 Nov 2012 19:07:02 +0200 Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
On Thu, 1 Nov 2012 12:12:35 +0100 Daniel Vetter daniel@ffwll.ch wrote:
> On Thu, Oct 25, 2012 at 8:05 PM, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä ville.syrjala@linux.intel.com > > > > Send completion events when the atomic modesetting operations has > > finished succesfully. > > > > Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com > > I have to admit I'm not on top of the latest ioctl/interface > discussion, but one new requirement for the modeset (not the pageflip > part) of the all this atomic stuff I've discovered is that the kernel > needs to be able to select the crtcs for each output completely > unrestricted. I think userspace should simply pass in abstract crtc > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual > crtcs it has selected. > > We can't do that remapping internally because the crtc abstraction is leaky: > - wait_for_vblank requires the pipe id, which could then change on every modeset > - similarly userspace doing MI_WAIT for scanlines needs to know the > actual hw pipe in use by a crtc. > And current userspace presumes that the mapping between crtc->pipe > doesn't change.
I don't know if it is possible, but it would be nice to try to clean up crtc<->pipe stuff.. userspace, at least modetest, assumes crtc == crtc_list[pipe]. But I haven't noticed yet anywhere that this relationship is documented. And if you are thinking about doing what I think you are thinking about doing, then this assumption would no longer hold for i915.
This relationship does already no longer hold on i915 - on gen3 at least we sometimes switch the crtc->pipe assignement (to make fbc more useful), which means even with todays code userspace cannot assume (when running on i915), that the vblank pipe satisfies crtc == crtc_list[pipe].
hmm, how does this not break weston compositor-drm (and modetest w/ vsync'd flipping.. although I suppose that is a less important use-case)
How frequently do you emit waits for scanline? Places where the pipe # ends up in cmdstream, would it be too crazy to handle that like a reloc where the kernel goes and fixes up the actual value in the cmdstream as it does it's GEM reloc pass? If you did this then you could virtualize pipe as well as crtc.
Every dri2 copyregion or Xv upload to the frontbuffer on pre-gen6 will use it. And we need old userspace to keep on working - presumably the fb layer will switch to using the new atomic modeset stuff (if available) to figure out an optimal config, so this is relevant.
yeah, not quite sure how the backwards-compat should work.. you'd have to somehow only dynamically reassign crtcs if you could tell that userspace is new enough to cope..
BR, -R
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch