Sean Paul writes:
> Sphinx won't pick these up, and will issue warnings. Please update to @
> instead of \param
>
> If you want to try it out:
> make htmldocs
Yeah, I was attempting to emulate the existing style. I suggest that a
general cleanup to fix the docstrings should be in a separate patc
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 v
On Tue, Oct 10, 2017 at 05:45:14PM -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 vb
On 11/10/17 02:45 AM, 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
>
>
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 v
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&tested userspace before we can land any kernel st
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&tested userspace before we can land any kernel stuff. Doing
> the quick modesetting conversion would unblock.
I've provid
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 reviewed&ready for merging, just as
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
>> not, drop it.
>
>
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" around vblank (ri
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 would be compatible wi
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&ready for merging, just as
> demonstration?
Well, given that we'll have to keep the ol
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
>
>
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 vb
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 v
On Thu, Jul 6, 2017 at 6:27 PM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> I very much like this since the old ioctl really is a rather bad horror
>> show. And since it's tied in with ums drivers everything is
>> complicated.
>
> Thanks for your kind words.
>
>> I started a discussion a wh
Ville Syrjälä writes:
> With the disable_immediate thing we only wait until the next vblank
> before disabling the irq again.
Ok, still sounds like we'll be doing fine if the application does a
get immediately followed by a queue event. At least most of the time.
--
-keith
signature.asc
Desc
On Thu, Jul 06, 2017 at 11:22:43AM -0700, Keith Packard wrote:
> Ville Syrjälä writes:
>
> > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern
> > where we can avoid doing the full update more than once if we enable
> > the interrupt already during the query.
>
> Don't we stil
Ville Syrjälä writes:
> I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern
> where we can avoid doing the full update more than once if we enable
> the interrupt already during the query.
Don't we still wait 5 seconds before disabling vblank? In that case, the
chances of hittin
On Thu, Jul 06, 2017 at 09:28:40AM -0700, Keith Packard wrote:
> Ville Syrjälä writes:
>
> > Maybe, or maybe we want to turn the interrupt on in that case? That's
> > what the old ioctl does.
>
> That's what I suggested in my reply to Daniel's review. Even if we add
> the accurate function, we'l
Ville Syrjälä writes:
> Maybe, or maybe we want to turn the interrupt on in that case? That's
> what the old ioctl does.
That's what I suggested in my reply to Daniel's review. Even if we add
the accurate function, we'll still need the interrupt-enable case as a
fallback for drivers which don't
Daniel Vetter writes:
> I very much like this since the old ioctl really is a rather bad horror
> show. And since it's tied in with ums drivers everything is
> complicated.
Thanks for your kind words.
> I started a discussion a while back whether these should be restricted to
> DRM_MASTER (i.e.
On Thu, Jul 06, 2017 at 01:04:18PM +0200, Daniel Vetter wrote:
> On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä
> wrote:
> >> > + if (!dev->irq_enabled)
> >> > + return -EINVAL;
> >> > +
> >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id);
> >> > + if (!crtc)
> >> > + re
On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä
wrote:
>> > + if (!dev->irq_enabled)
>> > + return -EINVAL;
>> > +
>> > + crtc = drm_crtc_find(dev, get_seq->crtc_id);
>> > + if (!crtc)
>> > + return -ENOENT;
>> > +
>> > + pipe = drm_crtc_index(crtc);
>> > +
>> > + get_
On Thu, Jul 06, 2017 at 09:53:13AM +0200, Daniel Vetter wrote:
> On Wed, Jul 05, 2017 at 03:10:13PM -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 Vul
On Wed, Jul 05, 2017 at 03:10:13PM -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.
>
> Signed-off-by: Keith Packard
I very much like this sinc
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.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_internal.h | 6 ++
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/dr
27 matches
Mail list logo