On Mon, May 26, 2014 at 05:37:57PM +0200, Daniel Vetter wrote: > On Mon, May 26, 2014 at 06:23:05PM +0300, Ville Syrjälä wrote: > > On Mon, May 26, 2014 at 11:31:10AM +0200, Daniel Vetter wrote: > > > On Sat, May 24, 2014 at 02:30:21PM -0400, Rob Clark wrote: > > > > @@ -92,7 +100,18 @@ int drm_atomic_set_event(struct drm_device *dev, > > > > struct drm_atomic_state *state, struct drm_mode_object *obj, > > > > struct drm_pending_vblank_event *event) > > > > { > > > > - return -EINVAL; /* for now */ > > > > + switch (obj->type) { > > > > + case DRM_MODE_OBJECT_CRTC: { > > > > + struct drm_crtc_state *cstate = > > > > + drm_atomic_get_crtc_state(obj_to_crtc(obj), state); > > > > + if (IS_ERR(cstate)) > > > > + return PTR_ERR(cstate); > > > > + cstate->event = event; > > > > + return 0; > > > > + } > > > > + default: > > > > + return -EINVAL; > > > > + } > > > > > > Hm, I think if we only want completion events on crtcs (which I agree on) > > > > I don't. Unless you have a nice way of passing some kind of "fbs now > > available for rendering" list back to userland in the single crtc > > event. Last time I looked making the drm event stuff deal with > > variable length events looked more painful than just adding per > > plane events. But I must admit that I didn't really try to do it. > > Hm, why can't userspace keep a list of fb ids involved in a given crtc > pageflip around and index those with the cookie we pass around? > > I really don't see why the kernel has to implement a half-baked event > multiplexer (which just copies the same thing n times), while userspace is > perfectly capable of doing that itself? > > Now if the timestamps would be genuinely different then I'd agree, but > then that's not an atomic update. User space can't do it if flips get issued faster than the vrefresh rate. I still want my "moar fps" triple buffering mode. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel