On Thu, 1 Nov 2012 12:12:35 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Thu, Oct 25, 2012 at 8:05 PM, <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > Send completion events when the atomic modesetting operations has > > finished succesfully. > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > 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. > > An example why the kernel needs to pick the crtc for userspace: > - on ivb only pipe A has a 7x5 panel fitter, so usually you want to > put the panel on the first crtc > - but if you run in a 3 pipe configuration and have an eDP panel, it's > better to put the eDP output on pipe C, since then pipes A&B will have > full 4-lane fdi links to the pch ports (instead of otherwise only 2 > lanes each on links B&C) > - similarly when we have a 3 pipe configuration with all encoders on > the pch, we need to move the mode with the highest dotclock to pipe A > (since that's the only one which will have 4 lanes, pipe B&C will only > have 2 each). > - afaik these kind of asymmetric constraints won't disappear anytime > soon, haswell definitely still has some. Yeah that's a good point... adding a virtual crtc layer would solve this and let us preserve the existing ABI. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
