On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote: > >> But I think we could still do this w/ one ioctl per crtc for atomic-pageflip. > > > > We could, if we want to sacrifice the synced multi display case. I just > > think it might be a real use case at some point. IVI feels like the most > > likely short term cadidate to me, but perhaps someone would finally > > introduce some new style phone/tablet thingy. I have seen > > concepts/prototypes of such multi display gadgets in the past, but the > > industry apparently got a bit stuck on the rectangular slab with > > touchscreen on one side design. > > I could be wrong, but I think IVI the screens would normally be too > far apart to matter? I was thinking of something like a display on the dash that normally sits low with only a small sliver visible, and extends upwards when you fire up a movie player for example. Internally it could be made up of two displays for power savings purposes. > Anyways, it is really only a problem if you can't do two ioctl()s > within one vblank period. If it actually turns out to be a real > problem, Well exactly that's the problem this whole atomic pageflip stuff is trying to tackle, no? ;) > we could always add later an ioctl that takes an array of > 'struct drm_mode_crtc_atomic_page_flip's. I'm not sure if this is > really useful or not.. but maybe I'm thinking too much about how > weston does it's rendering of different output's independently. I'm just now thinking of surfaceflinger's way of doing things, with its prepare and commit phases. If you need to issue two ioctls to handle cloned displays, then you can end up in a somewhat funky situation. Let's say you have a video overlay in use (one each display naturally), and you increase the downscaling factor enough so that you now have enough memory bandwith to support only one overlay. With independent check ioctls for each display, you never have the full device state available in the kernel, so each check succeeds during the prepare phase. So you decide that you can keep using the video overlays. You then proceed to commit the state, but after the first display has been commited you get an error when trying to commit the second one. What can you do now? The only option is to keep displaying the old frame on the other displays for some time longer, and then on the next frame you can switch to GPU composition. But on the next frame you perhaps no longer need to use GPU composition, but since you can't verify that in the prepare phase, you have no other option but to use GPU composition. So when you run into a configuration that can be supported only partially, you get animation stalls on some displays due to skipped frames, and you always have to fall back to GPU composition for the next frame. If on the other hand you would check the whole state in one ioctl, you'd get the error in the first prepare phase, and could fall back to GPU composition immediately. Am I too much of a perfectionst in considering such things? I don't think so, but perhaps other people disagree. > I wonder.. if you have some special hw setup where you can keep the > multiple display's in sync-lock, maybe a special virtual crtc would > work. That way userspace it appears as a single display. I'm not > really sure how crazy that would be to implement. Sure, add more abstraction layers and you can solve any problem :) > But I think in the > common case, where the displays are not vsync locked, treating the > page flips of different crtc's independently, and rendering the > contents for different outputs independently (like weston) makes the > most sense. My API design doesn't preclude that at all. In light of my android tale above how would weston decide whether it can use overlays in such a case? -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
