On Thu, 13 Feb 2020 09:11:36 +0100 Michel Dänzer <[email protected]> said:
> On 2020-02-12 6:42 p.m., Carsten Haitzler wrote: > > On Wed, 12 Feb 2020 16:45:50 +0100 Michel Dänzer <[email protected]> said: > > > >> On 2020-02-12 4:34 p.m., Carsten Haitzler wrote: > >>> On Wed, 12 Feb 2020 15:36:06 +0100 Michel Dänzer <[email protected]> > >>> said: > >>> > >>>> On 2020-02-12 2:06 p.m., Carsten Haitzler wrote: > >>>>> On Wed, 12 Feb 2020 13:23:28 +0200 Pekka Paalanen <[email protected]> > >>>>> said: > >>>>> > >>>>>> On Wed, 12 Feb 2020 11:07:56 +0000 > >>>>>> Carsten Haitzler <[email protected]> wrote: > >>>>>> > >>>>>>> On Wed, 12 Feb 2020 12:40:15 +0200 Pekka Paalanen > >>>>>>> <[email protected]> said: > >>>>>>> > >>>>>>>> On Wed, 12 Feb 2020 10:21:02 +0000 > >>>>>>>> Carsten Haitzler (The Rasterman) <[email protected]> wrote: > >>>>>>>> > >>>>>>>>> even better - if the /dev/dri/card0 > >>>>>>>>> device exists, dlopen libdrm and get some symbols from it and ... > >>>>>>>>> use it to request the drm device sent you vsync events so you can > >>>>>>>>> use the vsync interrupt as your frame event. this will be another > >>>>>>>>> fd to listen on in select() and of course you can turn this vblank > >>>>>>>>> event stream on and off. > >>>>>>>> > >>>>>>>> Please don't. Talk to the X server instead. > >>>>>>> > >>>>>>> and what vsync events does the xserver provide? > >>>>>> > >>>>>> You don't want vsync events. You have no idea what they > >>>>>> correspond to, or even if you opened the right device. > >>>>>> > >>>>>> https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/presentproto.txt > >>>>> > >>>>> I wrote the drm support before the present extension existed. The drm > >>>>> path is easy to support - only open if a single card exists (if > >>>>> multiple > >>>>> - don't do it and fall back to timer based animation) and you can filter > >>>>> for multiple screens as you get events for all screens. Yes - you end up > >>>>> syncing with a single chosen screen if you filter for just one of the > >>>>> vblank events, but it's better than using the system clock. > >>>> > >>>> You only get an event for the CRTC you ask for in the > >>>> DRM_IOCTL_WAIT_VBLANK ioctl. How do yo know which CRTC to pick? > >>> > >>> drmVBlank vbl; > >>> vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT; > >>> vbl.request.sequence = 1; > >>> vbl.request.signal = 0; > >>> drmWaitVBlank(drm_fd, &vbl); > >>> > >>> has worked a charm for maybe give or take close to a decade (as i said - > >>> before present existed). > >> > >> That selects the first CRTC. It'll work most of the time, except when > >> the first CRTC isn't enabled for some reason. > > > > I've seen it select multiple crtc's as I get multiple vblank events with the > > same frame number... (thus filter out the dups to only get one). > > Sounds like something's wrong. Well... maybe, but I've seen it and I've had to put in filters to skip duplicate frame events because of this. I am not seeing it here now so maybe it was fixed, or maybe it was on another driver stack or both. :) > Try setting vbl.request.signal to a unique (e.g. monotonically > increasing) value for each drmWaitVBlank call. The value is replicated > in the user_data field of the corresponding event. If you get multiple > events with the same user_data value, that indicates a kernel bug. I'd have to find a place where it happens first - I don't see it right now. It may have been a bug like 8-10 years ago or so when I implemented this vsync animation support and so I had to work with what I saw. Just keep in mind that this code is rather long lived by now and still works well/reliably today which is great for me. It was a bit of whack-a-bug at the time. :) > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
