On Mon, May 26, 2014 at 11:37 AM, Daniel Vetter <daniel@xxxxxxxx> 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.
I do kinda think userspace would want to know somehow if an fb is
going to be really late and explicitly submit an older fb. If you
were resizing, for example, I don't think the driver could make the
call to leave one plane displaying an older fb.
But I do think we can bikeshed about that in parallel with getting the
inital atomic infrastructure merged.
BR,
-R
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
