Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-10-10 Thread Daniel Vetter
On Mon, Oct 09, 2017 at 10:18:30AM -0700, Keith Packard wrote: > Daniel Vetter writes: > > > I just figured that -modesetting would be the simplest domenstration > > vehicle, since the vulkan patches don't look ready yet. I need fully > > reviewed userspace before we can land

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-10-09 Thread Keith Packard
Daniel Vetter writes: > I just figured that -modesetting would be the simplest domenstration > vehicle, since the vulkan patches don't look ready yet. I need fully > reviewed userspace before we can land any kernel stuff. Doing > the quick modesetting conversion would unblock.

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-07 Thread Daniel Vetter
On Sun, Aug 6, 2017 at 5:32 AM, Keith Packard wrote: > Daniel Vetter writes: > >> Since I missed all the details Michel spotted, so I'll defer to his r-b. >> Also, before merging we need the userspace user. Do we have e.g. >> -modesetting patch for this, fully

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-06 Thread Michel Dänzer
On 06/08/17 12:42 PM, Keith Packard wrote: > Michel Dänzer writes: > >> [...] >> >>> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >>> next sequence if we've missed */ >> >> Do you have userspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-06 Thread Michel Dänzer
On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter writes: > >>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT 0x0004 /* Signal when >>> first pixel is displayed */ >> >> Note that right now vblank events are defined as: >> - The even will be delivered "somewhen"

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-05 Thread Keith Packard
Michel Dänzer writes: > [...] > >> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >> next sequence if we've missed */ > > Do you have userspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If > not, drop it. I added this so that the new ioctl

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-05 Thread Keith Packard
Daniel Vetter writes: > Since I missed all the details Michel spotted, so I'll defer to his r-b. > Also, before merging we need the userspace user. Do we have e.g. > -modesetting patch for this, fully reviewed for merging, just as > demonstration? Well, given that we'll have to

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-02 Thread Michel Dänzer
On 01/08/17 02:03 PM, Keith Packard wrote: > These provide crtc-id based functions instead of pipe-number, while > also offering higher resolution time (ns) and wider frame count (64) > as required by the Vulkan API. > > v2: > > * Check for DRIVER_MODESET in new crtc-based vblank ioctls > >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-08-02 Thread Daniel Vetter
On Mon, Jul 31, 2017 at 10:03:06PM -0700, Keith Packard wrote: > These provide crtc-id based functions instead of pipe-number, while > also offering higher resolution time (ns) and wider frame count (64) > as required by the Vulkan API. > > v2: > > * Check for DRIVER_MODESET in new crtc-based

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-07-31 Thread Keith Packard
These provide crtc-id based functions instead of pipe-number, while also offering higher resolution time (ns) and wider frame count (64) as required by the Vulkan API. v2: * Check for DRIVER_MODESET in new crtc-based vblank ioctls Failing to check this will oops the driver. * Ensure